Ticket #129 (closed design: fixed)
List-type header fields vs Set-Cookie
|Reported by:||firstname.lastname@example.org||Owned by:|
|Component:||p1-messaging||Severity:||Active WG Document|
Part 1, Section 4.2 (http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-03#section-4.2) states:
"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)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded."
This is known to be incompatible with Set-Cookie as implemented in practice, as opposed as defined in RFC 2109.
In particular, Jamie Lokier points out:
RFC2109 is not implemented by anybody as far as I know.
Firstly, cookie _values_ in Set-Cookie may contain a comma which _mustn't_ be quoted because quotes are considered part of the value. When a value is unquoted, RFC2109 says it must match token syntax, but even today that's not conformed to. And RFC2109 doesn't describe an "expires=" attribute, but of course nearly all cookies have one, and they don't have the "max-age=" attribute with RFC2109 recommands. Finally, as you note, unquoted comma in expires attributes - in fact quoting is not allowed historically for that either.
See how many RFC2109 non-compliances you can find in this header I got today from Google, for example.
Set-Cookie: PREF=ID=823cb075fecf6437:TM=1195776675:LM=1195776675:S=WADqk8jBntt5y3gk; expires=Sun, 22-Nov-2009 00:11:15
(That nobody implements RFC2109 is implied in RFC2965, which obsoletes RFC2109 and in section 9 talks about using Set-Cookie2 alongside Netscape style Set-Cookies, not mentioning RFC2109 style Set-Cookiess. I think this reflects the observation at the time that the change of Set-Cookie syntax promoted in RFC2109 wasn't taken up, probably because it's not backward compatible.)
It seems to me that it would be a service to implementors to minimally add a Note pointing out this special case.
- Status changed from new to closed
- Resolution set to fixed
- Severity changed from Candidate WG Document to Active WG Document