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.

@requinix are you sure? This seems to be a valid bug

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?

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 https://github.com/golang/go/blob/master/src/net/http/cookie.go#L56

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