W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

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

From: Brian Smith <brian@briansmith.org>
Date: Fri, 15 Aug 2008 15:31:29 -0500
To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Dave Kristol'" <dmk-http@kristol.org>
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <98597A55DBA44938AD0D7CAFDD3F2841@T60>

Julian Reschke wrote:
>   Note: the "Cookie" and "Set-Cookie" headers as implemented in
>   practice (as opposed to how they are specified in [RFC2109])
>   can occur multiple times, 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.

"Cannot" is better than "can not" here. But, what exactly does "cannot" mean
in a specification? Instead of making this a note, it is better to make it a
normative part of the specification using RFC 2119 language:

    The original definition of the "Cookie" and "Set-Cookie"
    header fields used ";" instead of "," as the list separator,
    and this legacy syntax is still in common use. To maximize
    compatibility, clients MUST send at most one "Cookie"
    header field, origin servers MUST send at most one "Set-Cookie"
    header field, and proxies MUST NOT combine multiple "Cookie"
    or "Set-Cookie" header field values. See section A.2.3 of
    [Kri2001] for details.

As Dave said, this seems to be what the majority of implementations actually

Dave Kristol's paper is excellent but it is large and it talks about
political things as much as it talks about technical concerns. That is why I
changed the citation to mention section A.2.3 specifically.

Received on Friday, 15 August 2008 20:32:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:37 UTC