Are multiple Cookie headers allowed in an HTTP request?

Question

Usually, a browser groups cookies into a single Cookie header, such as:

Cookie: a=1; b=2

Does the standard allow to send these as separate headers, such as:

Cookie: a=1
Cookie: b=2

Or do they always have to be on the same line?

score 156 · Accepted Answer · edited Oct 07 '21 at 07:34

156

Chanced upon this page while looking for details on the topic. A quote from HTTP State Management Mechanism, RFC 6265 ought to make things clearer:

5.4. The Cookie Header

When the user agent generates an HTTP request, the user agent MUST NOT attach more than one Cookie header field.

It looks like the use of multiple Cookie headers is, in fact, prohibited!

edited Oct 07 '21 at 07:34

Community

1
1

answered Sep 23 '13 at 20:06

James Chong

1,915
1
16
14

9

These crazy new-fangled RFC's. :) – Kylar Oct 29 '13 at 22:25
19

Note that the _server_ can respond with multiple `Set-Cookie` headers: http://tools.ietf.org/html/rfc6265#page-7 – Michael Haren Nov 18 '14 at 17:45
Downvoted because answer still yet does not explain how to have multiple cookies in one header. – Jeff Davenport Mar 17 '17 at 17:42
2

Why the downvote, as OP specifically asked in terms of HTTP request, not HTTP response. @JeffDavenport – James Chong Mar 18 '17 at 19:10
2

For those coming here from Google like Jeff, OP shows you can have multiple vars by separating them with ";" (a space is not needed) – Albert Hendriks Jun 21 '17 at 06:57
2

@HawkeyeParker - *can* does not imply *correct*. I would argue that `Set-Cookie:a=b;c=d;` is more correct than `Set-Cookie:a=b; Set-Cookie:c=d;` if the values are set by a single server. The spec says the server should not fold multiple Set-Cookie header fields into one **field**, but it can add multiple Set-Cookie header fields into one **response**. What that means in the real world is that when a proxy server passes along a response, if that proxy sets cookies, it should use a separate Set-Cookie header. – Golphy Sep 28 '17 at 22:28
@Golphy thank you. You are absolutely correct. I misinterpreted the spec. Comment deleted. – Hawkeye Parker Sep 29 '17 at 00:03
1

See also @wusatosi's [answer](https://stackoverflow.com/questions/16305814/are-multiple-cookie-headers-allowed-in-an-http-request/49409403#49409403) from 5 years later, how HTTP 2 now apparently allows setting multiple cookie headers. – Sz. May 04 '20 at 15:07
@Sz. this appears to internal to compressed HTTP 2, no? You still would construct a cookie using a semicolon, and similarly you'd get semicolon-separated cookies out after HTTP 2 has been decompressed (as said in the HTTP/2 RFC). – Cigarette Smoking Man Oct 05 '21 at 10:20
@CigaretteSmokingMan, as I interpreted it, the cookie header is allowed to be split (to help compression), it's just to be rejoined "before being passed into a non-HTTP/2 context, such as an HTTP/1.1", i.e. only for legacy stuff, to support backward compat. – Sz. Oct 27 '21 at 22:51
@Sz. right (and the following isn't definite), but HTTP/2 is an "optimized expression" of HTTP semantics, while HTTP/1.1 is both an expression (the plain-text format) and a semantics (meaning of the text). In other words, while separate cookie headers might exist from a reverse proxy to the client, then I don't think a back-end server nor client-side JavaScript ever see the packed HTTP/2 encoding, but both work within the HTTP/1.1 textual format. – Cigarette Smoking Man Oct 29 '21 at 10:28

score 45 · Answer 2 · edited Oct 07 '21 at 07:34

it's now allowed in HTTP/2 (RFC 7540), which specifies:

    8.1.2.5.  Compressing the Cookie Header Field

   The Cookie header field [COOKIE] uses a semi-colon (";") to delimit
   cookie-pairs (or "crumbs").  This header field doesn't follow the
   list construction rules in HTTP (see [RFC7230], Section 3.2.2), which
   prevents cookie-pairs from being separated into different name-value
   pairs.  This can significantly reduce compression efficiency as
   individual cookie-pairs are updated.

   To allow for better compression efficiency, the Cookie header field
   MAY be split into separate header fields, each with one or more
   cookie-pairs.  If there are multiple Cookie header fields after
   decompression, these MUST be concatenated into a single octet string
   using the two-octet delimiter of 0x3B, 0x20 (the ASCII string "; ")
   before being passed into a non-HTTP/2 context, such as an HTTP/1.1
   connection, or a generic HTTP server application.

   Therefore, the following two lists of Cookie header fields are
   semantically equivalent.

     cookie: a=b; c=d; e=f

     cookie: a=b
     cookie: c=d
     cookie: e=f

What's the reason for `If there are multiple Cookie header fields after decompression, these MUST be concatenated into a single octet string`? Compatibility? Surely there is no practical advantage when dealing with a "generic HTTP server application". — ioquatix, Apr 26 '22 at 03:59
@ioquatix: If you look at the accepted answer, you can see it's because multiple `Cookie` headers are prohibited by the older spec (before HTTP/2). So you must concatenate them when passing to an old server or you will be violating the spec, and it may lead to unpredictable behaviour (e.g. a HTTP/1.1 proxy server might drop the extra duplicate headers). — Malvineous, Aug 04 '22 at 04:10

Are multiple Cookie headers allowed in an HTTP request?

2 Answers2

Linked