Cookies not being sent back and forth properly in Opera

Question

First off, I'm not sure whether this is a problem in Opera 12.01 or not, but the problem only occurs in Opera. I've tested in FF14, Chrome 21, Safari 5 (Windows) and Safari Mac and Webkit browsers on Android and iPhone.

My application runs on the trigger.io forge platform and uses a proxy to route requests from the web application to the service. The proxy simply forwards the requests and cookies along and this works as expected in most of the browsers.

After inspecting the request in dragonfly, I noticed that the server sends the proper headers in the response, but Opera seems to be ignoring setting the values. I'm wondering whether this is due to some misconfigured path value for the cookie. I've attached screenshots of 2 requests in Firefox and Opera.

As you can see in the screens, FF sees the cookie headers and sets them appropriately, but Opera does not.

Firefox Request

Opera request 1 Screen

Opera Request 2 Screen

I haven't included the code from the proxy that does the request forwarding, so please let me know if you need that to gain some insight. On the service end, I'm running PHP and Codeigniter. Please let me know if I need to add any more info here on my environment, thanks.

UPDATE : This issue occurs even in my production environment which does not use a custom TLD. Other sites that use cookies work fine and cookies are enabled.

Rotberg

Daft question, but are cookies enabled in your Opera installation (Settings > Preferences > Advanced > Cookies)? If so, you might consider setting Do Not Show Cookie Domain Errors=0 under [User Prefs] in operaprefs.ini to see whether Opera's rejecting the cookie due to uncertainty over the appropriate restriction level for your private .locdev TLD. – Jackhammer

I found the setting in about:config and unticked it, didn't fix the issue. Cookies are enabled as well, other sites work fine. I should have mentioned that this happens even on my production environment so can't be due to the TLD. Will add that info to the question, thanks. – Rotberg

Couple of initial thoughts - Opera is the only browser to support Set-Cookie2. I don't know the implications of that but perhaps it's related to the problem? Another thought - how many cookies do you have set for the /_forge path: Opera has a limit of 30 whereas Firefox has a limit of 50 and it's unclear whether new cookies would cause old ones to disappear or just be rejected. And how that works could vary by browser.. – Tussore

@AmirNathoo Will check up on set-cookie2, thanks. As for the number, we only have about 4 - 5 cookies. Definitely not more than 10 so that shouldn't be the case either. Also, I checked it on a clean install and it was still failing. – Rotberg

Answer 1

Double quotes are formally illegal in a cookie value. If you escape them as %22 it will work.

Studley

I will try to dig into the proxy's code to confirm this, but if this were the case wouldn't it affect every other browser as well? – Rotberg

I went through the proxy code and switched things about a bit. Removing the double quotes and putting in replacement characters worked like a charm! Thanks! – Rotberg

Answer 2

Have you checked if this is an issue with cookie domains ? I'm assuming you're using Javascript to set/read the cookies ? In any case there are 4 cookie domain issues that you might want to check (I know I've had these issue with an old FF version):

1 - check for illegal cookie characters: allowed cookie characters you might not be allowed to use '-' or '=' in the cookie name, and you shouldn't use non-ASCII characters in cookies at all. A base64 encode might deal with this.

2 - check that the domain on which you set your cookie (via javascript code or any other way) is identical to the domain on which the code is executed.

3 - check that the cookie domain is not localhost; see if you can test setting the cookie from a remote domain

4 - if you're using JS to set your cookies, try testing if you can set the cookie with a CGI in your browser to make sure it's not a browser issue. If it works which it should, see if you can read the cookie using JS (as opposed to setting it).

Let me know how this goes in the comments, I've dealt with similar issues a number of times and depending on what you get with these checks, I'm pretty sure I can help you fix the issue.

Therein

The cookies are set by PHP codeigniter and it seems to be encoding it so that should be clean. The domains are identical. I have this problem on my live server. And my local server is not named localhost. The only cookies that seem to be going through are those ones that are set by JS. The PHP cookies don't seem to work. Btw, this only breaks on Opera. Everything else works fine. – Rotberg

There are a number of reasons that could cause this: Have you checked that headers aren't sent beforehand ? Maybe a hidden PHP notice is thrown before the cookie code is executed ? – Therein

Since the JS cookies do get set (with the same content, I'm assuming) it makes me wonder whether it's a php.ini setting you're dealing with, or headers being sent to early. – Therein

This might not be the case but can you please confirm that if you create a NEW php file with just the cookie content, that cookie still doesn't get set in Opera ? And also, can you please include the cookie settings in your php.ini file? You might want to hide the exact domain name and such sensitive info... – Therein

See my answer about the double quotes. I have tested this across several browsers, I know that's cause of the problem. – Studley

CosminAtanasiu @Studley Thanks for the help guys, will check these point out tonight. And no, no notices are being thrown, – Rotberg

@CosminAtanasiu The cookies get set. They work fine when you're trying it out in a regular PHP file. I have the problem only when I run it through the proxy. – Rotberg

@Rotberg I was afraid of that... is the proxy domain the same as the one for which the cookie is set ? Can you try to set a cookie directly from the proxy ? – Therein

No, the cookies are being set for a subdomain. For example, the application is on stackoverflow.com and the cookies are being set for chat.stackoverflow.com. The proxy looks at the header and passes the cookies on. I've set the domain for the cookie properly. – Rotberg

@CosminAtanasiu Thank you for your help in this, user hallvors reply about removing double quotes fixed the problem for me :) – Rotberg

Alright, glad to be of help, and glad to hear you had your problem fixed! – Therein

Answer 3

Have you checked the "leading dot" form of a cookie domain in setcookie. I've been using leading dots for years and only recently noticed my app wont set cookies on opera (chromium et al?) due to the leading dot which is part of a deprecated RFC. In opera, it's not that the leading dot gets ignored but the very setting of the cookie itself. I've removed the leading dot and its working now.

Venable

Answer 4

Looking at those Opera screenshots, they seem to be AJAX / XHR requests which are processed within the same second. Is it possible that Javascript is triggering both of those requests "simultaneously", so the response from the "first" is not arriving before the request for the "second" is constructed - and therefore the cookies have not yet been set?

I'm not familiar with the technologies/toolkits you're using, so don't know if these are stock code or part of your custom application.

Hutton

No, they aren't run during the same second. I've set it up sequentially. And if you look at the response, you can see the cookies being returned but not actually being used. – Rotberg

Then why do both of your Opera screenshots list the response time as "Wed, 08 Aug 2012 17:00:09 GMT"? And yes, the server is setting cookies on both responses, but if the browser created the second request before it had seen the first response, then of course it wouldn't send those cookies back. – Hutton

Good point but I checked it and that doesn't seem to make a difference. I delayed the second request by 2 seconds and still the same. This is a grab from a local setup, so that's why the timestamps are so close. I can assure you the code is running sequentially. – Rotberg

Fair enough. It was a reasonable theory based on the evidence presented, so I'm glad you've ruled it out experimentally. – Hutton