- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 20 Nov 2007 11:09:08 +0100
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Bjoern Hoehrmann wrote: > E* Julian Reschke wrote: >> We currently say in Section 4.2: >> >> Multiple message-header fields with the same field-name MAY be >> present in a message if and only if the entire field-value for that >> header field is defined as a comma-separated list [i.e., #(values)]. >> >> -- <http://tools.ietf.org/html/rfc2616#section-4.2> >> >> Now this seems to be kind of backwards, wouldn't it be *much* clearer if >> it said: >> >> Multiple message-header fields with the same field-name MUST NOT be >> present in a message unless the entire field-value for that >> header field is defined as a comma-separated list [i.e., #(values)]. > > No, unlike the old text, that does not say when you may use them. Ahem? "...unless the entire field-value..."? >> That being said, do we have a recommendation for recipients when that >> requirement is violated? I would assume that servers SHOULD return a 400 >> (Bad Request), but what about clients? > > You fold them into a single value as the specification suggests unless > there is some reason not to do that. Servers should not be required to Well, for Content-Type the specification says you can't do that. > respond with Bad Request, they might not know the header, and they > should not treat > > X: a > X: b > > differently from X:a,b, so if they don't give you a Bad Request for the > latter, they should not do it for the former. I think the current text > is fine. Of course both forms should be treated the same. The question I was asking: what is a recipient -- in particular a client -- supposed to do with a message where header values are known to be invalid? Best regards, Julian
Received on Tuesday, 20 November 2007 10:36:08 UTC