How to handle multiple cookies with the same name?

Question

Say for example I had an application sending the following HTTP headers to set to cookie named "a":

Set-Cookie: a=1;Path=/;Version=1
Set-Cookie: a=2;Path=/example;Version=1

If I access /example on the server both paths are valid, so I have two cookies named "a"! Since the browser doesn't send any path information, the two cookies cannot be distinguished.

Cookie: a=2; a=1

How should this case be handled? Pick the first one? Create a list with all cookie values? Or should such a case be considered as a developer's mistake?

Answer 1

The answer referring to an article on SitePoint is not entirely complete. Please see RFC 6265 (to be fair, this RFC was released in 2011 after this question was posted, which supersedes previous RFC 2965 from 2000 and RFC 2109 from 1997).

Section 5.4, subsection 2 has this to say:

The user agent SHOULD sort the cookie-list in the following order:

• Cookies with longer paths are listed before cookies with shorter paths.

NOTE: Not all user agents sort the cookie-list in this order, but this order reflects common practice when this document was written, and, historically, there have been servers that (erroneously) depended on this order.

There is also this little gem in section 4.2.2:

... servers SHOULD NOT rely upon the serialization order. In particular, if the Cookie header contains two cookies with the same name (e.g., that were set with different Path or Domain attributes), servers SHOULD NOT rely upon the order in which these cookies appear in the header.

In your example request cookie (Cookie: a=2; a=1) note that the cookie set with the path /example (a=2) has a longer path than the one with the path / (a=1) and so it is sent back to you first in line, which matches the recommendation of the spec. Thus you are more or less correct in your assumption that you could select the first value.

Unfortunately the language used in RFCs is extremely specific - the use of the words SHOULD and SHOULD NOT introduce ambiguity in RFCs. These indicate conventions that should be followed, but are not required to be conformant to the spec. While I understand the RFC for this quite well, I haven't done the research to see what real-world clients do; it's possible one or more browsers or other softwares acting as HTTP clients may not send the longest-path cookie (eg: /example) first in the Cookie: header.

If you are in a position to control the value of the cookie and you want to make your solution foolproof, you are best off either:

1. using a different cookie name to override in certain paths, such as:

   • Set-cookie: a-global=1;Path=/;Version=1
   • Set-cookie: a-example=2;Path=/example;Version=1

2. storing the path you need in the cookie value itself:

   • Set-cookie: a=1&path=/;Path=/;Version=1
   • Set-cookie: a=2&path=/example;Path=/example;Version=1

Both of these workarounds require additional logic on the server to pick the desired cookie value, by comparing the requested URL against the list of available cookies. It's not too pretty. It's unfortunate the RFC did not have the foresight to require that a longer path completely overrides a cookie with a shorter path (eg: in your example, you would receive Cookie: a=2 only).