- From: Dan Winship <dan.winship@gmail.com>
- Date: Fri, 11 Jun 2010 08:51:31 -0400
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Bil Corry <bil@corry.biz>, HTTP Working Group <ietf-http-wg@w3.org>, Michal Zalewski <lcamtuf@google.com>, Jeff Hodges <Jeff.Hodges@KingsMountain.com>, Adam Barth <ietf@adambarth.com>, "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
On 06/09/2010 08:24 AM, Julian Reschke wrote: >> http://code.google.com/p/browsersec/wiki/Part1#Hypertext_Transfer_Protocol >> >> ... > > Interesting. > > That text mentions the test > > "Content-Length header value overrides actual content length?" > > I have trouble understanding what this means... Unless the connection is > closed, or chunked encoding is in place, or the message is by definition > not having a body (HEAD response), there *is* no other signal than > Content-Length to find out the actual content length. It's about the case when you know the connection will be closed at the end of the response, but the actual number of bytes sent by the server before closing the connection doesn't match the Content-Length header. Eg, if you GET http://sourceforge.net/apps/wordpress/sourceforge, you'll get back a 302 response with "Content-Length: 338" and "Connection: close", followed by 8 bytes of body data before the server closes the connection. A client should consider that to be a truncated response, but as noted by the page above, most web browsers instead just assume that the Content-Length header was wrong. (I assume this was originally another case of bug-compatibility with IE to support broken web sites.) -- Dan
Received on Friday, 11 June 2010 12:52:01 UTC