Bug #79478 [Nab]: PHP parses cookies invalid cookies (RFC6265)

Edit report at https://bugs.php.net/bug.php?id=79478&edit=1 ID: 79478 Updated by: requinix@php.net Reported by: marius dot grigaitis dot ext at home24 dot de Summary: PHP parses cookies invalid cookies (RFC6265) Status: Not a bug Type: Bug Package: HTTP related Operating System: MacOS PHP Version: 7.4.4 Block user comment: N Private report: N New Comment: 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. https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie (unfortunately the setter does not allow multiple cookies at once) Unanswered question: how do other systems parse the Cookie header? Previous Comments: ------------------------------------------------------------------------ [2020-04-15 12:09:09] sjon@php.net @requinix are you sure? This seems to be a valid bug ------------------------------------------------------------------------ [2020-04-15 12:02:19] requinix@php.net 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 http://www.php.net/support.php 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 11:50:31] marius dot grigaitis dot ext at home24 dot de Description: ------------ RFC6265 states that key=value pairs of cookies inside Cookie header are separated by "; " (semicolon space) https://tools.ietf.org/html/rfc6265#section-5.4 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: --------------- test.php: <?php var_dump($_COOKIE); ------ $ php -S 127.0.0.1:8080 test.php $ curl -H "Cookie: foo=bar;;bar=baz" http://127.0.0.1:8080/test.php Expected result: ---------------- array(1) { ["foo"]=> string(3) "bar" } Actual result: -------------- array(2) { ["foo"]=> string(3) "bar" ["bar"]=> string(3) "baz" } ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=79478&edit=1