php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #64118 $_COOKIE not always populating with all cookies
Submitted: 2013-01-31 17:33 UTC Modified: 2013-01-31 19:34 UTC
From: chris dot czub at gmail dot com Assigned:
Status: Not a bug Package: HTTP related
PHP Version: 5.3.21 OS: Linux 64 bit
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: chris dot czub at gmail dot com
New email:
PHP Version: OS:

 

 [2013-01-31 17:33 UTC] 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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-01-31 17:38 UTC] rasmus@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 18:04 UTC] chris dot czub at gmail dot com 
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
 [2013-01-31 18:27 UTC] rasmus@php.net 
If you know your way around gdb, set a breakpoint around here:
http://lxr.php.net/xref/PHP_5_4/main/php_variables.c#280
and follow along. But I really can't see how it could possibly be anything in 
that code.

How exactly are you determining the cookie isn't set? Are you doing a 
print_r($_COOKIE) before doing anything else on the page? The fact that it is 
the session cookie that you aren't seeing leads me to believe it is something 
further down in the stack that might be overwriting it.
 [2013-01-31 19:16 UTC] chris dot czub at gmail dot com
-Status: Open +Status: Closed
 [2013-01-31 19:16 UTC] chris dot czub at gmail dot com 
Apologies for the bug report; this seems to be due to some validation the Kohana 
framework is doing on the IP address the session was started on.
 [2013-01-31 19:34 UTC] rasmus@php.net
-Status: Closed +Status: Not a bug
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 26 06:01:32 2024 UTC