- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 21 Nov 2007 15:23:58 +0100
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- CC: Jamie Lokier <jamie@shareable.org>, HTTP Working Group <ietf-http-wg@w3.org>
Bjoern Hoehrmann wrote: > ... >> 2. Messages MUST NOT have duplicate headers, except as permitted: >> >> + Headers whose field-value syntax is a comma-separated list. >> >> + More generally, when explicitly permitted by other >> specifications and applications, whose syntax is such that >> concatenating syntactically valid values with "," (with and >> without surrounding LWS) does not change the interpretation. >> >> + Headers received and forwarded unmodified by a proxy (except >> leading and trailing LWS and multi-line formatting changes, >> and field-name case changes). > > I am not sure why you have the latter two items, they seem to extend > when duplicates are allowed, which they should not. Correct. >> + Set-Cookie in a response message, due to historical accident. > > It's not clear to me that this needs to be allowed, and if so, it's > unclear to me that this is the only case that needs to be allowed. It's unfortunate, but I think it would be a service to readers of the spec to make them aware of that exception. > ... >> 4. At the point where specific headers are interpreted during message >> processing, if duplicates are present and not permitted as >> described above, the message SHOULD be rejected as malformed. > > I disagree with this, for example, Apache will reject requests with > multiple Content-Length headers with Request Entity Too Large, not I would consider that a bug; why would you say that the request entity is too large if you don't know how large it is? > Bad Request; further, there is no reason that I can see why servers > should handle "X: a\nX: b" differently from "X: a,b" if neither is > allowed. Correct. > ... Best regards, Julian
Received on Wednesday, 21 November 2007 14:24:15 UTC