W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

Re: "actual content length", was: Handling multiple headers when only one is allowed

From: Dan Winship <dan.winship@gmail.com>
Date: Fri, 11 Jun 2010 08:51:31 -0400
Message-ID: <4C123153.3010406@gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:20 GMT