95466 - content sent with invalid Content-Length will never be reused from the cache

Status: RESOLVED WONTFIX

(Core :: Networking, defect, P4)

Description

[Darin Fisher]

my patch for bug 89113 along with the patch for bug 94889 broke caching of
content served with an invalid Content-Length header.  the solution requires
some modification to nsHttpChannel::OnDataAvailable to "track" the size of
the incoming data and update the cached Content-Length header appropriately.

Comment 1

[Darin Fisher]

since this only effects "broken" servers, this doesn't really deserve a high
priority... if it makes it for moz0.9.4 great, but if not... i don't think it's
a big deal.

Comment 2

[benc]

So, based on reading the notes for 89113, this would theoretically be only HTTP
0.9 servers, b/c someone commented that HTTP 1.0 servers do this correctly?

Comment 3

[Bradley Baetz (:bbaetz)]

benc: No - 0.9 servers never send a content length. 1.1 servers MUST send a
correct one. Some 1.0 servers got it wrong.

Comment 4

[Darin Fisher]

benc: for example, consider CGI output.  HTTP/1.1 servers typically use a
chunked transfer encoding with CGI output, hence they don't need to worry about
specifying a Content-Length.  HTTP/1.0, however, does not define chunked
encoding, and HTTP/1.0 servers often don't enforce a valid Content-Length
header.  The HTTP/1.1 spec is very specific about this unfortunate circumstance.

but, it should be noted that we also allow HTTP/1.1 servers to lie about the
Content-Length, provided the connection is not persistent.  this is consistent
with IE's behavior.

Comment 5

[Darin Fisher]

-> mozilla 0.9.5

Comment 6

[Darin Fisher]

-> 0.9.6 (unfortunately)

Comment 7

[Darin Fisher]

this is only an issue for broken servers, so moving out beyond mozilla1.0

Comment 8

[Darin Fisher]

mass futuring of untargeted bugs

Comment 9

[Ralf Hauser]

See RFE Bug 236084 for Content length optimizations for form upload

Comment 10

[Darin Fisher]

-> default owner