Re: Set-Cookie vs list header parsing (i129), was: NEW ISSUE: repeating non-list-type-headers

Dave Kristol wrote:
> Regarding this comment:
> 
> (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.)
> 
> I wrote a paper that describes the standardization process for cookies
> in excruciating detail.  You can get it at
> <http://arxiv.org/abs/cs.SE/0105018>.  I'll refer to some of its
> sections below
> 
> Appendix section A.2, particularly A.2.3, discusses the problem of
> "folding" multiple Cookie headers, that is the problem of "," and ";"
> separators.  I suspect (but have no proof) that, in self-defense,
> current clients and servers treat Cookie as a special case and are
> careful to send each cookie in its own header, rather than merge them.
> 
> Appendix B describes where Set-Cookie2 came from.  It had nothing to do
> with "," vs. ";", at least originally.  Work on what became RFC 2965
> began shortly after RFC 2109 came out, to fix an incompatibility we
> found.  That work began well before RFC 2109 would have had any time to
> be adopted.  The long time gap between RFC 2109 and RFC 2965 arose from
> other factors.  See section 4.3.3.
> 
> It was certainly our goal (see section 4.3) to introduce upward- (or is
> it downward- ?) compatible changes, though we had to deal with the hand
> that Netscape's specification dealt us.  We obviously didn't succeed.
> 
> Dave Kristol

Dave,

thanks for the pointer. I wish we had more documentation like this to 
help those who joined the WG much later.

With respect to the original issue -- I think it would be a service to 
readers to point out that this:

    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. 
-- <http://tools.ietf.org/html/rfc2616#section-4.2>

...is wishful thinking in practice, because of Cookie and Set-Cookie (as 
used in practice, not defined in RFC2109).

How about:

--- snip ---

Note: the "Cookie" and "Set-Cookie" headers as implemented in practice 
(as opposed to how they are specified in [RFC2109]) can occur multiple 
lines, but do not use the list syntax, and thus can not be combined into 
a single line (see [Kri2001] for details). Also note that the 
Cookie2/Set-Cookie2 headers specified in [RFC2965] do not share this 
problem).

--- snip ---

BR, Julian

Received on Friday, 15 August 2008 18:22:42 UTC