Re: [Chicken-users] http cookie order

[Drake Wilson]

Quoth Graham Fawcett <address@hidden>, on 2008-03-28 09:59:16 -0400:
> RFC2109 allows for multiple Set-Cookies, but it also
> warns that "an intervening gateway could fold multiple such headers
> into a single header". Since "folding" is undefined, there's no way
> the origin server can guarantee the sequence of the cookies in the
> received header.

FWIW, from RFC 2616 (HTTP/1.1), 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)].
| [...]  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.

>From RFC 2109 (HTTP State Management Mechanism), section 4.3.3:
| If a user agent receives a Set-Cookie response header whose NAME is
| the same as a pre-existing cookie, and whose Domain and Path
| attribute values exactly (string) match those of a pre-existing
| cookie, the new cookie supersedes the old.  

It's not entirely clear whether "pre-existing" means "from a previous
request" or not.  A Web search does not turn up much discussion on the
matter.  A previous preliminary specification,
http://wp.netscape.com/newsref/std/cookie_spec.html, writes "with the
latest instance taking precedence" which is also somewhat ambiguous in
that "latest" may or may not mean "latest within the same response".

My interpretation of this is:

  - Forwarders are not permitted to rearrange multiple Set-Cookie
    headers.  HTTP client and server libraries have the same
    constraint.

  - Origin servers should not generate multiple Set-Cookie headers in
    the same response for the same (name, domain, path) tuple, since
    it is not clear what one should do with them.

  - Clients should interpret Set-Cookie headers in the order they are
    received, partly because it's a more constrained interpretation of
    the term "pre-existing" in the spec, and partly due to rude-ish
    websites that will return ambiguous responses and expect that
    interpretation.  (I do not know of any site that expects a
    different interpretation of multiple cookies overwriting each
    other in the same response.)

(RFC 2109 is also supposedly "obsoleted" by RFC 2965, but that
describes the behavior of Set-Cookie2 headers, not Set-Cookie headers,
and it doesn't seem any clearer.)

   ---> Drake Wilson