W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

Re: NEW ISSUE: Transfer-Encoding in 1.0 messages

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Fri, 23 Nov 2007 12:34:59 +0100
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: ietf-http-wg@w3.org
Message-Id: <1195817699.2807.29.camel@henriknordstrom.net>
On fre, 2007-11-23 at 11:20 +0100, Bjoern Hoehrmann wrote:

> I do not know any current setup that would cause this, and that browsers
> do not agree how to handle this is a good hint that there are none. What
> I can easily imagine though is that in ancient times broken servers with
> broken proxies would cause this, and that exploits might try to use this
> to bypass crude security measures.

I don't think we need to do anything more about this in the specs. It's
quite clear how it should be parsed by a HTTP/1.1 client (chunked), and
also quite clear that it's not allowed to be sent so if seen on the wire
then it's fishy, i.e. either a broken implementation or someone trying
nasty things.

It's not the point of the spec to enumerate every possible protocol
violation that may be seen outside of the specifications or how
recipients is to deal with each such case. Attempts to do so would
seriously encumber the usability of the specification.

We could add a general recommendation that recipients SHOULD reject
obviously malformed messages where the sender has violated MUST
requirements or MUST NOT restrictions. But I seriously doubt many
implemeters would care to do this even if explicitly recommended by the
specifications as there is too much broken crap out there, and users do
not want to know about others broken crap, they just want things to work
at best effort. So I prefer to leave this up to each implementer to
judge how strict they want to be in their parsers.

Regards
Henrik


Received on Friday, 23 November 2007 11:35:08 GMT

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