Edit report at https://bugs.php.net/bug.php?id=64118&edit=1
ID: 64118 Comment by: chris dot czub at gmail dot com Reported by: chris dot czub at gmail dot com Summary: $_COOKIE not always populating with all cookies Status: Open Type: Bug Package: HTTP related Operating System: Linux 64 bit PHP Version: 5.3.21 Block user comment: N Private report: N New Comment: I agree that PHP having an issue with parsing cookies seems like a stretch, given its wide-spread usage. I was really wary of filing this bug report but couldn't find anything obviously "wrong" with what I was doing or anyone else experiencing this problem. I can give you whatever would be helpful in diagnosing this issue. Here is the results of a tcpdump for the successful request coming from A1 to B(tcpdump run on B, invoked with "tcpdump -i eth1 port 80 -s0 -A -xX -w - | strings"): POST /auth/account/ HTTP/1.0 X-Real-IP: 10.26.137.190 Host: login.cudaops.com Content-Length: 18 Cache-Control: no-cache Pragma: no-cache Origin: https://bcc.cudaops.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.58 Safari/537.22 Content-Type: application/x-www-form-urlencoded Accept: application/json, text/javascript, */*; q=0.01 X-Requested-With: XMLHttpRequest Referer: https://bcc.cudaops.com/cgi-mod/index.cgi Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: CLOUD_AT=AT-89ce37851305368c6dff65a744177767d9e6d025-a794e0df53af550379c942d31298d6fa; current_account=1692258; CLOUD_LOCALE=en_US; cloud_session=rk4tngcp3b5606kui0j7ulvi17; __utma=3413794.2061795848.1359575906.1359651115.1359654827.5; __utmb=3413794.6.10.1359654827% ; __utmc=3413794; __utmz=3413794.1359575906.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) X-Forwarded-For: 208.44.138.156 Connection: Keep-Alive account_id=3081551% HTTP/1.1 200 OK Date: Thu, 31 Jan 2013 17:55:49 GMT Server: Apache Access-Control-Allow-Origin: https://bcc.cudaops.com Access-Control-Allow-Credentials: true Set-Cookie: CLOUD_LOCALE=en_US; expires=Tue, 30-Jul-2013 17:55:49 GMT; path=/; domain=.cudaops.com Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: cloud_session=rk4tngcp3b5606kui0j7ulvi17; path=/; domain=.cudaops.com X-Cloud-Auth: 1 P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM" Set-Cookie: current_account=3081551; path=/; domain=.cudaops.com Vary: Accept-Encoding,User-Agent Content-Encoding: gzip Content-Length: 47 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 V*.MNN-.V *)*M QJ-* P4MP Here is the tcpdump for an unsuccessful request coming from A2 to B(same tcpdump invocation): POST /auth/account/ HTTP/1.0 X-Real-IP: 10.26.137.148 Host: login.cudaops.com Content-Length: 18 Cache-Control: no-cache Pragma: no-cache Origin: https://bcc.cudaops.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17 Content-Type: application/x-www-form-urlencoded Accept: application/json, text/javascript, */*; q=0.01 X-Requested-With: XMLHttpRequest Referer: https://bcc.cudaops.com/cgi-mod/index.cgi Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: CLOUD_AT=AT-79f19531aedb58852ff7aca32229d106e4e33ff9-3461df01e156feb0f383dd05b9254990; CLOUD_LOCALE=en_US; cloud_session=pmtmpg50oc8spuakvb4bf04ro4; __utma=3413794.2000155977.1359655359.1359655359.1359655359.1; __utmb=3413794.3.10.1359655359; __utmc=3413794 ; __utmz=3413794.1359655359.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) X-Forwarded-For: 64.235.150.32 Connection: Keep-Alive account_id=1692258 (RV@ yW\a yW\a HTTP/1.1 200 OK Date: Thu, 31 Jan 2013 18:03:08 GMT Server: Apache Access-Control-Allow-Origin: https://bcc.cudaops.com Access-Control-Allow-Credentials: true Set-Cookie: CLOUD_LOCALE=en_US; expires=Tue, 30-Jul-2013 18:03:08 GMT; path=/; domain=.cudaops.com Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: cloud_session=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.cudaops.com Set-Cookie: cloud_session=0hle6j303fklbhav12r0559ka1; path=/; domain=.cudaops.com Set-Cookie: cloud_session=0hle6j303fklbhav12r0559ka1; path=/; domain=.cudaops.com X-Cloud-Auth: 0 P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM" Vary: Accept-Encoding,User-Agent Content-Encoding: gzip Content-Length: 47 Keep-Alive: timeout=15, max=53 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 V*.MNN-.V *)*M QJ-* 4.M@ (.N@ 4]P@ PGuW P'_Q Previous Comments: ------------------------------------------------------------------------ [2013-01-31 17:38:14] ras...@php.net There is nothing in this bug report for us to go on. And as a data point, the cookie header parsing code hasn't changed in many years and this is the first bug report I can recall suggesting it might somehow not parse cookies correctly. The chances of this being a PHP bug are near nill considering how many millions of servers this works fine on out there. ------------------------------------------------------------------------ [2013-01-31 17:33:59] chris dot czub at gmail dot com Description: ------------ Seems similar to https://bugs.php.net/bug.php?id=52018 however this application is not using phpBB. Three servers are involved in this issue. We can call them A1, A2, and B. A1 and A2 are running the same application code. They are two staging instances of the same web application. B is another web application. We need to perform a cross-domain AJAX request from the A web application to the B application. We experimented with enabling CORS but had difficulties getting it working satisfactorily in IE <= 8(XDomainRequest doesn't support cookies), so now we are using an nginx proxying rule on the A1/A2 web servers. The flow is therefore: browser ajax request -> A1 or A2 -> nginx proxied -> B B is stateful and requires the user's session cookie to function. What we're seeing is that this works properly when using server A1, but when using server A2, B can't pull out the cookies. I have looked at the headers for the requests coming from A1 and A2 and they are the same. Both have the cookies line in the header, both have the same origin, etc. On B what we see is that $_COOKIE['cloud_session'] is empty when the request comes from A2 but properly filled out when the request comes from A1. The weird thing is that it's only missing pulling one particular cookie key out of the cookies in the header, and only when the request comes from A2. It parses every other cookie in the headers from A2 fine, it just can't parse the user's session cookie for some reason but it can just fine if the request comes from A1. I have used tcpdump and taken pcaps of each of these and diffed them and nothing in the headers looks particularly different. I can include any data that would help diagnose this. The length of the cookie header is only 259 characters in both the failing and successful cases, so it will be underneath the 4KB limitation. Expected result: ---------------- All cookies passed in the Cookie: header should be parsed into $_COOKIE when the request is proxied from server A1 or A2. Actual result: -------------- All cookies passed in the Cookie: header are parsed into $_COOKIE when the request comes from A1, however when the request comes from A2, the session cookie is not set in $_COOKIE but all others are. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=64118&edit=1
