Firefox cannot download files served with a negative Content-Length header. For example, if I try to download the Windows 7 Pro x64 ISO from the Mozilla intranet (~3GB in size), I get a "Corrupted Content Error" page. curl -I reveals the page is being served with a Content-Length of -1070280704 (so the server is integer-overflowing). I can still download the file with Chrome, it just treats the file as if it was of unknown duration and we should do the same.

Looks like an intentional "regression" from bug 597706.

I suggest that we come to an agreement with the other browser vendors on what to do about this. They may be happier to change their implementations than to see us copy them here. This seems to be really pushing the bounds as to brokenness that we would be willing to cope with.

For a brief window of time, Chrome enforced Content-Length matching on downloads. Unfortunately, this introduced web compatibility issues as there are a number of non-spec-compliant servers and other browsers were permissive, and the behavior was reverted. It's possible Chrome could change to error on negative content-length's and we could measure how frequently this is encountered in the wild. However, given that arbitrary non-negative values are allowed, I'm not sure if this really buys much.

Current relevant text in HTTPbis is: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-18#section-3.3 One solution would be to remove 'invalid' from #3 on page 29 and let those C-L headers fall through to #6 (close-delimited). I don't *think* there are security implications there (it was lumped in with duplicates), but it'd be good to hear from the security folks about that. Please bring this to the HTTPbis WG; we want the spec to be in sync with the implementations. Thanks,

(In reply to Chris Pearce (:cpearce) from comment #0) > Firefox cannot download files served with a negative Content-Length header. > > For example, if I try to download the Windows 7 Pro x64 ISO from the Mozilla > intranet (~3GB in size), I get a "Corrupted Content Error" page. curl -I > reveals the page is being served with a Content-Length of -1070280704 (so > the server is integer-overflowing). > > I can still download the file with Chrome, it just treats the file as if it > was of unknown duration and we should do the same. Ahem. We should reach out to the owners of that server and have it fixed :-)

(In reply to Mark Nottingham from comment #4) > Current relevant text in HTTPbis is: > http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-18#section-3.3 > > One solution would be to remove 'invalid' from #3 on page 29 and let those > C-L headers fall through to #6 (close-delimited). request pipeline a, b a comes back with a invalid CL. let's say its negative because it wrapped an internal calculation. if we silently change the delimiter to close even in the presence of the C-L the response to B will be considered part of A's message body. It might even get cached. That seems undesirable. People with broken delimiters cannot reliably have their responses parsed.

Hmm. You could have a different behaviour for pipelined and non-pipelined, but that would make things even more complex / difficult to debug (both for browsers and sites). It can also introduce some tricky states for intermediaries. So, I think I agree. Can Chrome get on board with that? Can we make this better for users?

I agree that Content-Length mismatch can't be reused reliably with Keep-Alive connections. For Connection: Close connections they are also a bad signal - however, many user agents permit the mismatch for many resource types. If we want to separate the negative integer case from the general mismatch case that seems reasonable, but doesn't strike at the heart of the problem.

(In reply to Julian Reschke from comment #5) > We should reach out to the owners of that server and have it fixed :-) Bug 719256. ;)

bug 719256 implies that >2 GB downloads are going to break on all 32-bit apache servers (at least on the 1.X branch as of apache 1.3.20, released 2001-05-15: I don't know about 2.X) That's a pretty big web compat hit. (I'm marking it 'compat': dunno if that's the right keyword). Is there a workaround we can think of that will not break pipelining but allow us to keep working with this at least until old apache servers are gone from the net (i.e. a while)? We could mitigate the problem at least with something like "hey, this URI ends with a well-know big file extenstion--.iso, .tar.gz, etc, so let's load it on its own, non-Keep-alive connection".

Serving a 2G+ file isn't typical; it's largely video streaming over HTTP, ISOs, etc. and those sites are somewhat specialised; I'd be surprised if they're not already aware of this and using something other than Apache 1.x. I'm not saying that this bug doesn't happen, just that perhaps it's not that widespread.

(In reply to Mark Nottingham from comment #11) > Serving a 2G+ file isn't typical; it's largely video streaming over HTTP, > ISOs, etc. and those sites are somewhat specialised; I'd be surprised if > ... Streaming would use Chunked-Encoding (or Connection:close), right?

I think some portions of the content-length changes were a bit of an overreach. Where we see something that looks like a smuggling attack the changes are justified, but where there are just framing problems that we've always muddled along with we should continue to do so. (or in this case, resume doing so). I'll put a proposed patch in bug 704227 and mark this a duplicate as they both deal with negative CL.