Quoth Graham Fawcett <[EMAIL PROTECTED]>, 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 _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users