https://bz.apache.org/bugzilla/show_bug.cgi?id=63434
--- Comment #8 from Yann Ylavic <[email protected]> --- (In reply to rgagnon24 from comment #7) > > Apache is compressing them with ", " into one header. This leads to an > improper single Cookie value that some language like PHP (or others) will > then not be able to properly parse (as commas are allowed characters within > the value of a cookie), >From rfc6265 (which you refer to) it is defined as: cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E ; US-ASCII characters excluding CTLs, ; whitespace, DQUOTE, comma, semicolon, ; and backslash In older RFCs (because cookies have several RFCs and the latest is not necessarily the one used), the value was defined as a token (or quoted-string): token = 1*<any CHAR except CTLs or separators> separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT In the original Netscape's "Persistent Client State -- HTTP Cookies" (actually the one mostly used): NAME=VALUE This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. So no, commas and whitespaces are not allowed in a cookie value (unless quoted). The are allowed in the Expires attribute value, with no quoting (!), causing all sort of special case / workarounds for Set-Cookie headers (like never compressing them). > and because cookie parsers in most interpreters are > going to "split" the key-value pairs out of the single Cookie: value by > looking for a semi-colon to split on, and then creating the key-value pairs > from those. These parsers need to be fixed IMHO, they should look for the comma too, a compressed Cookie header is a single Cookie header (though semantically equivalent in HTTP to as much headers as commas). Yes they should not happen because, as you said, rfc6265 forbids multiple Cookie headers in the first place, but by the way I'm afraid there is no such thing as a cookie RFC which is honored by everyone... > The compression routine in apache is technically not at fault (sort of) > because it is combining multiple headers as other RFCs allow, but the issue > it would be nice if (for the Cookie header) that httpd could play nice with > a bad user-agent, and fix the multiple "Cookie" header mistake the UA makes, > so that the parser behind httpd can properly see the values. httpd enforces the HTTP protocol, not rfc6265 or any cookie specification which is an application thing (i.e. httpd has nothing to do with cookies besides validating that they are correct HTTP headers). If modules/applications need to make use of the cookies they should extract them from the HTTP header, and parse them according to HTTP (compressed-)headers semantics, and eventually reject them if a comma is found (meaning multiple headers were received). > When PHP now looks to find it's session data, it can't find it because the > value for "PHPSESSID" now appears as "XXXXXXXXXXXX, > BIGipServer~XXXXX~XXXX=XXXXX" > > Worse yet, if the bad user-agent sends the headers in a different order, PHP > won't even find a value at all for "PHPSESSID" because there will be no > Cookie that starts like that... for example: > > Cookie: BIGipServer~XXXXX~XXXX=XXXXX > Cookie: PHPSESSID=XXXXXXXXXXXX > > Would become: > > Cookie: BIGipServer~XXXXX~XXXX=XXXXX, PHPSESSID=XXXXXXXXXXXX > > And the only thing then present in $_COOKIE would be the key > "BIGipServer~XXXXX~XXXX" with the value "XXXXX, PHPSESSID=XXXXXXXXXXXX" How about fixing (mod_)PHP(-fpm)? Either to reject the request (enforcing rfc6265, which wouldn't help in your case) or to deal with the comma correctly. PHP cares about cookies since it provides $_COOKIE, httpd does not. Please note that addressing this in httpd would require a quite painful treatment for every request: first set aside Cookie headers, compress the other headers with comma, compress the Cookie headers with semicolon and re-insert. This all would be before knowing whether the Cookies are needed/used later or not, so at the very least it would need to be optional. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
