|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79478 PHP parses cookies invalid cookies (RFC6265)
Submitted: 2020-04-15 11:50 UTC Modified: 2020-04-15 20:52 UTC
From: marius dot grigaitis dot ext at home24 dot de Assigned:
Status: Not a bug Package: HTTP related
PHP Version: 7.4.4 OS: MacOS
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: marius dot grigaitis dot ext at home24 dot de
New email:
PHP Version: OS:


 [2020-04-15 11:50 UTC] marius dot grigaitis dot ext at home24 dot de
RFC6265 states that key=value pairs of cookies inside Cookie header are separated by "; " (semicolon space)

However, PHP accepts cookies separated by only semicolon

This leads to to a situation where multiple application (written in different languages) see different cookies in the same request

Test script:



$ php -S test.php

$ curl -H "Cookie: foo=bar;;bar=baz"

Expected result:
array(1) {
  string(3) "bar"

Actual result:
array(2) {
  string(3) "bar"
  string(3) "baz"


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2020-04-15 12:02 UTC]
-Status: Open +Status: Not a bug
 [2020-04-15 12:02 UTC]
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

 [2020-04-15 12:09 UTC]
@requinix are you sure? This seems to be a valid bug
 [2020-04-15 20:52 UTC]
Not to lay this on too thick, but I'm being thorough:

1a. Section 5.4 is about *creating* the Cookie header. That does not mean an agent on the other end must *parse* the header using the same rules. Look at nearly any algorithm for parsing human-readable string structures and you'll see that they include flexibility for "malformed" inputs.

1n. Section 4.2 is about parsing the Cookie header, and the whole thing is less than a page. It does give a grammar for a Cookie header but that's prefaced with an "if... the user agent conforms to the requirements". If. Note that there is no algorithm for parsing the header, unlike Section 5.2.

2. Set-Cookie is treated more nicely. Section 4.1 gives a space after each semicolon, so one can definitely argue that the space is required, however down in Section 5.2 where the user agent parses the header (specifically in the unparsed-attributes sequence), a missing space is supported by virtue of the fact that an empty attribute-name would be an "unrecognized attribute-name". It's reasonable to assume that an algorithm for parsing a Cookie, had it been written, would include the same "unrecognized" behavior for its attribute-value pairs.

3a. Garbage in, garbage out. Cookie is supposed to have a space after each semicolon. Without there being any statement otherwise from the RFC, if you construct an "invalid" Cookie header then the server can do whatever it want.

3b. Common sense says that the space is for readability. It has no significance in the header, and an agent accepting a missing space during parsing will still be following the standard.

4. MDN acknowledges that the space may be omitted (in document.cookie):
> In the code above allCookies is a string containing a semicolon-separated list of all
> cookies (i.e. key=value pairs). Note that each key and value may be surrounded by
> whitespace (space and tab characters): in fact, RFC 6265 mandates a single space after
> each semicolon, but some user agents may not abide by this.

(unfortunately the setter does not allow multiple cookies at once)

Unanswered question: how do other systems parse the Cookie header?
 [2020-04-16 08:32 UTC]
that's fine, I think being thorough is the only correct response for an invasive issue like this.

I looked at golang and they are also pretty loose in their implementation, see

Given that
* there currently aren't any issues with the way PHP parses cookies
* the rfc is not being violated
* PHP behaves correctly when clients follow the spec

I think you are correct and this is not something that should be changed
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Thu Jul 07 17:05:45 2022 UTC