In HTTP specification, what is the string that separates cookies?

Question

Semicolon ;, the Cookie: string or some other string?

Solution 1

Inspecting cookies in an HTTP request

The Cookie: header has the following syntax:

Cookie: <Name> = <Value> { ; <Name> = <Value> }

Hence individual cookies are separated with the semicolon and a space.

Setting cookies in an HTTP response

On the other hand, when setting a cookie in the response, there one cookie per the Set-Cookie: header:

Set-Cookie: <Name> = <Value> [ ; expires = <Date>] [ ; path = <Path> ] [ ; domain = <Domain> ] // etc…

To set multiple cookies the Set-Cookie header is repeated in an HTTP response.

---

Notes:

• Have a look here for a tutorial with examples, and to RFC 6265 HTTP State Management Mechanism for a normative reference showing the full details of the syntax.
• The now-obsolete RFC 2965 defined an alternate pair of headers Cookie2 and Set-Cookie2 which were abandoned.
• The obsoleted versions of the HTTP State Management Mechanism (RFC 2109 and RFC 2965) provided a way to fold multiple Set-Cookie (or Set-Cookie2) headers into one. However, this folding is not recommended by the latest RFC 6265 spec.

Solution 2

The answer is a comma , sign.

In section 4.2.2 of RFC 2109 there's this specification of Set-Cookie header

   set-cookie      =       "Set-Cookie:" cookies
   cookies         =       1#cookie

with the following statement Informally, the Set-Cookie response header comprises the token Set-Cookie:, followed by a comma separated list of one or more cookies. (Formally meaning of # in the above notation is defined in RFC 733 in section A. NOTATIONAL CONVENTIONS, point 5

A construct "#" is defined, similar to "*", as follows:

              <l>#<m>element

indicating at least <l> and at most <m> elements, each separated by one or more commas (",").

Yes, RFC 2109 was obsoleted by RFC 2965, which in turn was obsoleted by RFC 6265.
No, it doesn't change anything in this context as

• most existing HTTP servers and clients support RFC 2109
• RFC 6265 does not forbid Set-Cookie folding

Comments

[Piotr Dobrogost]

On the other hand, when setting a cookie in the response, there one cookie per the Set-Cookie: header: Not true. In section 4.2.1 of RFC 2109 one reads An origin server may include multiple Set-Cookie headers in a response. Note that an intervening gateway could fold multiple such headers into a single header. In section 4.2.2 of the same RFC one reads Informally, the Set-Cookie response header comprises the token Set-Cookie:, followed by a comma separated list of one or more cookies.

[Ondrej Tucny]

@PiotrDobrogost RFC 2109 was obsoleted by RFC 2965, which in turn was obsoleted by RFC 6265. The latest spec recommends avoiding Set-Cookie folding. Both 2109 and 2965 do not support folding in the presented ABNF syntax. Thanks for pointing out this ambiguity. I will fix the RFC reference in my response.

[Julian Reschke]

It matters a lot. RFC 6265 is supposed to describe what UAs actually do.

[Piotr Dobrogost]

@JulianReschke Well in this case could you please tell us which of popular UAs do not handle folded Set-Cookie header?

[Piotr Dobrogost]

Both 2109 and 2965 do not support folding in the presented ABNF syntax. Not true Presented ABNF syntax clearly supports multiple cookies in one Set-Cookie header (folding) - see my answer.

[Ondrej Tucny]

@PiotrDobrogost Fixed in my answer. Thanks for pointing that out, I didn't notice the semantics of 1#cookie syntax rule clearly.

[Julian Reschke]

Piotr, I have no idea, and I don't have said so. I was just pointing out that RFC 6265 is supposed to accurately define how cookies work, as opposed to the older RFCs.

[Piotr Dobrogost]

Hence individual cookies are separated with the semicolon. Not true. The semicolon in the syntax of Cookie: header you present separates each <Name>=<Value> pair not each cookie as each cookie can have any number of such pairs.

[Ondrej Tucny]

@PiotrDobrogost Section 4.2.2 of RFC 6265 reads: “Each cookie-pair represents a cookie stored by the user agent.”, where cookie-pair = cookie-name "=" cookie-value. So, can you please provide supportive evidence for you claim and downvote?

[Ondrej Tucny]

@PiotrDobrogost fair enough.

[theyetiman]

-1 because this answer directly contradicts the accepted answer, and the author of this answer even admits that it's not a comma in the comments thread of the accepted answer. Shouldn't this be answer be removed altogether??

[Lawrence Dol]

RFC 6265 doesn't forbid Set-Cookie folding (probably for backward compatibility), but it discourages it in the strongest terms using "SHOULD NOT": "Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field."

[Piotr Dobrogost]

To clarify; in my comment above starting with Hence (…) when I was talking about <Name>=<Value> pairs I actually had in mind attribute-value pairs comprising cookie-av part of cookie as described in section 4.2.2 of RFC 2109. However cookie-av (and thus attribute-value pairs) is valid only when setting cookie by means of Set-Cookie: header not when sending back (in Cookie: header) a cookie which had been already set.

[Piotr Dobrogost]

One curious thing is that Set-Cookie: header's parsing algorithm described in section 5.2. The Set-Cookie Header of RFC 6265 does not seem to allow more than one cookie (so called folded cookies) in this header although it is allowed in section 4.2.2 Set-Cookie Syntax of RFC 2109. Till now I was convinced that RFC 6265 is backward compatible with RFC 2109 and RFC 2965 in regard to consuming header values which are valid according to these two earlier specifications… Am I missing something?

[Jason]

I encountered a server that DID fold Set-Cookie headers recently, so this is definitely a thing that is out in the wild.

[MrWhite]

"separated with the semicolon" - Although, they are actually separated by semicolon + space (2 chars). developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie