- From: Jamie Lokier <jamie@shareable.org>
- Date: Wed, 21 Nov 2007 17:36:06 +0000
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Bjoern Hoehrmann wrote: > > * Julian Reschke wrote: > >> 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. > > I would not mind a note and certainly expect the State Management part > to point this issue out, but allowing this practise is a different issue > (that should be discussed in some other thread anyway). How can you not "allow" it? _Every_ HTTP implementation dealing with the web in any significant way must implement it, even those which handle Set-Cookie2 as well, so it's silly to make it a MUST NOT condition in the spec. > >> 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? > > Because that's what you get if the header is malformed in some other > way and because it requires less logic in the server's code. This may > not be ideal, but I can see no reason to outlaw this either. In my proposal it's not outlawed. It SHOULD reject the message as malformed, which makes sense; it's not a MUST. Really, Apache should have a function which means "get me the value of header X and if it's duplicated, return an error code", generically, and use that for all headers where it makes sense. -- Jamie
Received on Wednesday, 21 November 2007 16:25:26 UTC