Procedure: Use an HTTP proxy (testing done with WebWasher 3.0). Download a file. Expected: Download size is displayed when available. Actual: Download size is never displayed, even though I know the proxy isn't filtering this information out (it worked in IE and previous Mozilla builds). Build: 2001070204 Win98

Skewer: could you provide a testcase?

Umm, disregard my previous comment. I'm adding a testcase to the that has always worked from (bug 87327). In the build 2001070108 win32, I can only reproduce this when keep-alive is off in the debug pref.

To test this: Install the WebWasher proxy. <http://www.webwasher.com/> Make sure your proxy settings are configured so HTTP goes through the local proxy. Restart everything, and make sure WebWasher is running. Try to download a Mozilla daily build. In IE and NS4 the download size is displayed correctly. Please only post comments related to this specific testing procedure.

This is a http only problem (setting component) might be related to bug 84264 and bug 87047

I get this DLing the latest Mozilla nightly. at w@rk, via proxy, it shows the size as unknown, and, of course, no % at home via dailup, it works aok one variation: w@rk: Windows NT Version 4.0 ( Build 1381: Service pack 4) home: win 98 ( not SE ) p.s. thanks _basic for this bug number

HTTP's "Connection" is the key here. The problem will happen without any proxy help if you set: user_pref("network.http.keep-alive", false); In this case, the HTTP server from the example URL will return: HTTP/1.0 200 OK Server: Netscape-Enterprise/3.6 SP3 Content-Type: application/octet-stream Last-Modified: Fri, 13 Apr 2001 21:45:02 GMT Content-Length: 6378215 Accept-Ranges: bytes Date: Wed, 11 Jul 2001 12:01:50 GMT Connection: close [data] The "Connection: close" seems to make mozilla forget the Content-Length. That's the problem. Testing done with 0.9.2 on Linux. OS -> all?

robbe: are you saying that you are seeing it without proxy when the keep-alive option is off? Could you test it with keep-alive on and with proxy?

err scratch my previous comment. Robbe, you might be using transparent proxy.

Broken on 2001071004/Windows NT 4 (SP6a + Hotfixes) Using transparent proxy. Marking OS -> All.

when keep-alive is on Mozilla sends: GET /7/1392/939/0001/www.eudora.com/download/eudora/windows/5.1/full_elec/Eudora51.exe HTTP/1.1 Host: a1392.g.akamaitech.net User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2+) Gecko/20010709 Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1 Accept-Language: en-us Accept-Encoding: gzip,deflate,compress,identity Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Keep-Alive: 300 Connection: keep-alive Referer: http://bugzilla.mozilla.org/show_bug.cgi?id=89113 the server sends back: HTTP/1.0 200 OK Server: Netscape-Enterprise/3.6 SP3 Content-Type: application/octet-stream Last-Modified: Fri, 13 Apr 2001 21:45:02 GMT Accept-Ranges: bytes Content-Length: 6378215 Date: Wed, 11 Jul 2001 15:17:46 GMT Connection: keep-alive when keep-alive is off Mozilla sends: GET /7/1392/939/0001/www.eudora.com/download/eudora/windows/5.1/full_elec/Eudora51.exe HTTP/1.1 Host: a1392.g.akamaitech.net User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2+) Gecko/20010709 Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1 Accept-Language: en-us Accept-Encoding: gzip,deflate,compress,identity Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Connection: close Referer: http://bugzilla.mozilla.org/show_bug.cgi?id=89113 the server sends back: HTTP/1.0 200 OK Server: Netscape-Enterprise/3.6 SP3 Content-Type: application/octet-stream Last-Modified: Fri, 13 Apr 2001 21:45:02 GMT Accept-Ranges: bytes Content-Length: 6378215 Date: Wed, 11 Jul 2001 15:15:26 GMT Connection: close It seems that on Connection: close we throw away the Content-Length?

_basic: keep_alive on, with proxy, I see the same behaviour (file size unknown). Mozilla sends "Connection: keep-alive", and my proxy, being a poor HTTP/1.0 thing, does not pass through the "Connection: keep-alive", so the response is without any "Connection" header. Summary: Content-Length is only heeded when a genuine "Connection: keep-alive" is found. [..dig..dig..] TA-DA! http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpTransaction.cpp#428

heh, by the looks of the comments in the source, I guess this is going to be a wontfix, unless someone wants to turn this into a hidden pref of some sort ;-) From nsHttpTransaction.cpp // HTTP/1.0 servers have been known to send erroneous Content-Length // headers. So, unless the connection is keep-alive, we'll ignore // the Content-Length header altogether. At the very least, this should also be written in the release notes.

I'll be writing the relnotes, unless someone wants to submit a contribution... :)

The cause of this bug is the fix for bug 83960 (adding darin to CCs), which was obviously a more serious issue (pages getting shortened). But now we have loss of functionality with good (but old) servers/proxies for the sake of a workaround for old and broken servers. Hmm, if we could have a content-length value that is *only* used for display (not to cut-short on the connection layer), this one could be fixed too. Reporting a "0" size in the download dialogue is hardly less erroneous than any potentially bogus value reported by the server (and most older servers/proxies do behave ok in this regard). (Note that contrary to darin's log message, a bogus Content-Length is not legal HTTP/1.0. The RFC just recognizes that there are broken (pre-HTTP/1.0) servers out there and that HTTP/1.0 *clients* should be lenient to them.)

I notice that in this testcase at least "Accept-Ranges: bytes" is sent, maybe we should add this as a test to use the Content-Length? Robbe: are you suggesting that one of these lines be commented out? 436 mContentLength = -1; 437 mResponseHead->SetHeader(nsHttp::Content_Length, nsnull); 438 mResponseHead->SetContentLength(-1);

The transport layer is using one or more of these settings (if present) to terminate the body of the HTTP response - a thing we want to prevent for old, broken servers. Obviously, if one setting were used for this purpose, and the other just for the progress display, that would save our butt. I know far too little to decide whether that's the case, though. As this bug demonstrates, playing with the Content-Length information can have interesting side-effects.

In the classic implementation of this (I've yet to really decifer it completely), I see content_length, original_content_length and real_content_length. I'm still not sure how they are used though, as the comments in http://lxr.mozilla.org/classic/source/network/protocol/http/mkhttp.c are not really clear.

My proxy is HTTP/1.0, which might explain why nothing works when I'm using it. There should be a change so that incorrect content-length headers don't break the document, but they still display in the progress bar for long downloads (not just in the download window but also in the viewer for things like large JPEG files). Also, is there any way to filter this based on the Server: header? Is there one particular server that does this?

If we go with displaying un-trusted "Content-Length:", lets at least display "approxmately" when we show the size... Lots of people actually compare file sizes.

Hmm... Approximate_Content_Length or mApproximateContentLength anyone?

darin added an explict check to ignore content len from 1.0 servers. Reassign to darin. Is this an WONTFIX bug darin?

RELNOTE for NS 6.1: "If you use a proxy server, HTTP downloads will not show the incoming file size."

bbaetz and i studied the behavior of IE w.r.t. the Content-Length header on non-keep-alive HTTP/1.0 connections. it turns out that IE doesn't "trust" the Content-Length either, but instead of throwing it away, it simply reads up to an additional 1024 bytes after the specified Content-Length has been reached. i'd like to make mozilla do the same thing, as it would take care of not only this bug but also bug 83960.

-> bumping priority, severity, and setting milestone to moz0.9.4 patch coming...

This is just a suggestion, but perhaps a checkbox could be added to the mime type properties screen when editing a mime type to bypass the proxy. For those of us with webwasher and similar proxies there's no need to pull zip, exe, tar, etc files through the proxy. This would give us download sizes again plus eliminate needless traffic through the proxy.

that's an interesting feature... which should probably be filed as a feature enhancement bug. i've got a patch in mind (that i should hopefully get to in the next couple of days) which will solve this problem for real.

No, this is more important than a feature. We're completely blocking out an important HTTP/1.0 header. We need to offer some sort of solution to this, which works around the broken server issue without causing HTTP headers to be lost.

You need to update the Content-Length header as well, so the cache doesn't get confused. r=bbaetz with that change.

your keeping me busy today =). sr=mscott

fixed-on-trunk

This has causes crasher bug 94889, which will probably be a topcrash really soon.

back on the 0.9.4 radar, since the fix for 94889 removes part of the "solution" to this bug.

FWIW, I just DLed the latest nightly using 2001081403 and the display was PERFECT file size, elapsed time, time remaining, horizontal progress bar, per cent complete I'm behind a firwall, going through a proxy Windows NT Version 4.0 ( Build 1381: Service pack 4)

yeah.. actually THIS bug is FIXED by the patch. the problem is that part of it had to be backed out and that resulted in a bit of a regression in the case that a server sends an invalid Content-Length header. i've filed bug 95466 to track this "minor" regression. -> targeting 0.9.2 branch for embedding.

As reported, this is fixed.

VERIFIED: Netscape 6.1 RTM linux had this problem. (0K for file size) mozilla 2000-08-15-14-trunk does not have this problem, you can see the size display.

*** Bug 96210 has been marked as a duplicate of this bug. ***

Verified all platforms...