Closed
Bug 123334
Opened 23 years ago
Closed 15 years ago
File downloading is extremely slow when the Content-Length header is missing
Categories
(Core Graveyard :: File Handling, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: spiros_ioannou, Unassigned)
References
()
Details
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•23 years ago
|
||
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?
Summary: File downloading is extremely slow when the Content-Length header is missing → File downloading is extremely slow when the Content-Length header is missing
Reporter | ||
Comment 2•23 years ago
|
||
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•23 years ago
|
||
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.
Assignee: darin → trudelle
Component: Networking: HTTP → XP Apps
QA Contact: tever → sairuh
Reporter | ||
Comment 5•23 years ago
|
||
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.
Reporter | ||
Comment 7•23 years ago
|
||
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.
Reporter | ||
Comment 8•22 years ago
|
||
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.
Updated•22 years ago
|
QA Contact: sairuh → petersen
Comment 9•22 years ago
|
||
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•22 years ago
|
||
I'm going to confirm this bug, so that somebody can mark it resolved. -M
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 11•22 years ago
|
||
'Twas a good bug, aye. 'Twas fix'd before 'twas confirmed. :-D -M
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•22 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reporter | ||
Comment 13•22 years ago
|
||
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=)
Reporter | ||
Comment 14•22 years ago
|
||
From 180714: "downloading the file with Shift+Click shows the status: but with just Click the status is empty."
Updated•22 years ago
|
Comment 17•18 years ago
|
||
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+%.
Updated•15 years ago
|
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
Comment 18•15 years ago
|
||
WFM in Seamonkey 2.0.2
Status: REOPENED → RESOLVED
Closed: 22 years ago → 15 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•