W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: p1-message-07 S 7.1.4

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Sat, 25 Jul 2009 01:52:28 +0200
To: Jamie Lokier <jamie@shareable.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1248479548.3155.19.camel@localhost.localdomain>
lör 2009-07-25 klockan 00:24 +0100 skrev Jamie Lokier:

> I guess you are saying:
> 
>    1. There are real proxies which use Content-Length when they shouldn't.

Yes. And with that being a very grey area considering that there still
is HTTP/1.0 proxies around not knowing a bit about chunked encoding.

Related to this there also is very many web servers responding with
chunked encoding in responses to HTTP/1.0 requests (MUST NOT for very
very good reasons).

>    2. There are real servers which send Content-Length and chunking
>       in the same response.

Yes.

>    3. There are real servers which produce the wrong chunk formatting?

Yes, or which can be fooled into doing so.

>       Do you have specific examples of wrong chunk formatting?
>       Are there some well known (in implementer circles) things
>       that a robust client must be prepared to accept?

As implemented in our software it's actually more in the area of things
we don't accept and which causes us to reject the connection and
consider the message invalid

- Certain forms of malformed message headers
- Malformed chunk headers
- Overly large chunk sizes (bigger than we can parse 32/64 bit depending
platform & version)
- Extra data coming after the message, as this may indicate an
response-splitting attempt.

Unfortunately many implementations completely foreget to verify the data
they parse, and for example reads 4294967808 as 256 or -1, or 4294967296
as 0, or even A as 0 for that matter.

Regards
Henrik
Received on Friday, 24 July 2009 23:53:07 GMT

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