123334 - File downloading is extremely slow when the Content-Length header is missing

Status: RESOLVED WORKSFORME

Description

[Spiros Ioannou]

File downloading is extremely slow when the Content-Length header is missing.
This applies to both when saving a file with the save dialog and when
redirecting this file to a helper (e.g. winamp).
Without the Content-Length the transfer takes about 10 times more, and on top of
that, the CPU utilization is 100%. As a result the "progress" window most of the
times doesn't show correctly, just its borders are shown.
Maby the files are read from the network in very small pieces?

Comment 1

[Karl Johan Kleist]

Reporter: Please always specify which "Build ID" you're using,
as found in the title bar of the main Mozilla window.

Do you possibly have an URL we can try?

Comment 2

[Spiros Ioannou]

Ok, i tried it with Gecko/20020202 (today's build) but I have noticed this along
time, so it's not new.

I've setup a server but I don't think it's going to help you because the
internet will be your bottleneck and not the browser.
Anyway you can copy the script and files to a server near you and try them.

TESTS with wget:
---------------------------------------------
without Content-Length
~ > time wget -q "http://manolito.image.ece.ntua.gr/~sivann/mozilla/sendit.php"
0.120u 0.460s 0:02.13 27.2%     0+0k 0+0io 216pf+0w

With Content-Length
~ > time wget -q "http://manolito.image.ece.ntua.gr/~sivann/mozilla/sendit.php?cl=1"
0.100u 0.510s 0:02.16 28.2%     0+0k 0+0io 216pf+0w

Headers:
--------
~ > echo "HEAD /~sivann/mozilla/sendit.php?cl=1 HTTP/1.0\n\n" | socket manolito
80     
HTTP/1.1 200 OK
Date: Mon, 04 Feb 2002 18:46:13 GMT
Server: Apache/1.3.20 (Unix) PHP/4.0.6 mod_ssl/2.8.4 OpenSSL/0.9.6b
X-Powered-By: PHP/4.0.6
Content-Length: 19298304
Content-disposition: attachment; filename=300Kmh_on_bike.mpg
Connection: close
Content-Type: application/octet-stream


TEST mozilla:
-----------------
Mozilla takes about 4-6 seconds with Content-Length, and more than 30 seconds on
a fast (1Ghz) win2k PC to complete. On a slow PC it takes much much more.

Maby the progress bar is updated too often (every byte?) causing the whole
system to slowdown? I've seen GUI ftp clients that go slow because of this. I'm
not sure that this is the case with mozilla because the progress window contents
don't appear.

Comment 3

[Darin Fisher]

this should have nothing to do with the underlying networking layer.  if no
Content-Length header, then we simply wait for the server to terminate the
connection.  nothing else is effected, so my guess is that this is a problem
with the download progress meter.  i suspect it is not handling a contentLength
= -1 properly.

-> xpapps.

Comment 4

[Peter Trudelle]

->file handling

Comment 5

[Spiros Ioannou]

This seems fixed with build Gecko/20020225, but progress bar still don't show
up. I'll wait a few builts to see what will happen.

Comment 6

[Boris Zbarsky [:bz] (no decent commit message means r-)]

So.. is this still an issue?

Comment 7

[Spiros Ioannou]

This bug still exists, without the Content-Length, download times are bigger,
and the progress-window appears as a blank window with a title bar showing "-1%
 of xxx Saved". Sometimes the window appears correctly, and yes the progress bar
seems to get updated on *every* byte. CPU utilization is still 100% probably
because of this. This seems very easy to fix.

Comment 8

[Spiros Ioannou]

Download times have improved, for a 80MB file over a 100Mbit/s switched network
it takes 10seconds with content-length and 15 seconds without on a 866Mhz pc.

The problem is now that "Status:" information is blank in the progress window
when content-length is absent. I believe it should display downloaded bytes.

Comment 9

[Max Kanat-Alexander]

WFM Win2K 20021108.

This bug has been resolved, pretty much! If you'd like to file an enhancement
request for the "Status:" thing, then feel free to do it as another bug!
Otherwise it won't get noticed. :-)

-M

Comment 10

[Max Kanat-Alexander]

I'm going to confirm this bug, so that somebody can mark it resolved.

-M

Comment 11

[Max Kanat-Alexander]

'Twas a good bug, aye. 'Twas fix'd before 'twas confirmed. :-D

-M

Comment 12

[Spiros Ioannou]

I tested today this bug with the download manager. It is not fixed, 
it gets 6-7MB/sec with content length, and 2-3MB/sec without. 
Also, without content-length, the update is every byte, and takes 100% cpu.
I wonder if it reads the file in byte-sized buffers from the network.

Comment 13

[Spiros Ioannou]

Retested today, it's in the original state. Without Content-Length it takes
about 20times more than with the header.
Please test on a local server with a cpu <1Ghz. Just copy the php script, 
just change the 1st line ($fname=)

Comment 14

[Spiros Ioannou]

From 180714:
"downloading the file with Shift+Click shows the status: but
with just Click the status is empty."

Comment 15

[Ralf Hauser]

see also: Bug 236084 for Content-Length issues during file upload

Comment 16

[Cees T.]

Sounds like a dup of bug 279465.

Comment 17

[Ed Lee :Mardak]

Is this still an issue? I tried the php script on my own machine with trunk 2007061704. With content length, it was transferring ~3500KBps and without ~2800KBps. However, in both case, Apache was consuming much more CPU than Firefox; Firefox used ~5-10% in both cases while Apache is 50+%.

Comment 18

[:Hb]

WFM in Seamonkey 2.0.2