19

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

Firefox request

Opera request 1 Screen

Opera request 1

Opera Request 2 Screen

Opera Request 2

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.

JohnP
  • 47,501
  • 10
  • 101
  • 134
  • 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. – eggyal Aug 08 '12 at 17:53
  • 2
    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. – JohnP Aug 08 '12 at 18:24
  • 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.. – Amir Nathoo Aug 13 '12 at 03:03
  • @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. – JohnP Aug 13 '12 at 04:47

3 Answers3

8

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

hallvors
  • 5,603
  • 1
  • 20
  • 37
  • 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? – JohnP Aug 16 '12 at 19:41
  • 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! – JohnP Aug 17 '12 at 10:42
5

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.

Community
  • 1
  • 1
Cosmin Atanasiu
  • 2,092
  • 3
  • 16
  • 25
  • 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. – JohnP Aug 15 '12 at 18:52
  • 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 ? – Cosmin Atanasiu Aug 15 '12 at 19:26
  • 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. – Cosmin Atanasiu Aug 15 '12 at 19:27
  • 1
    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... – Cosmin Atanasiu Aug 15 '12 at 19:29
  • 1
    See my answer about the double quotes. I have tested this across several browsers, I know that's cause of the problem. – hallvors Aug 15 '12 at 20:29
  • CosminAtanasiu @hallvors Thanks for the help guys, will check these point out tonight. And no, no notices are being thrown, – JohnP Aug 16 '12 at 11:10
  • @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. – JohnP Aug 16 '12 at 19:39
  • 1
    @JohnP 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 ? – Cosmin Atanasiu Aug 16 '12 at 21:18
  • 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. – JohnP Aug 17 '12 at 04:37
  • @CosminAtanasiu Thank you for your help in this, user hallvors reply about removing double quotes fixed the problem for me :) – JohnP Aug 17 '12 at 10:42
  • Alright, glad to be of help, and glad to hear you had your problem fixed! – Cosmin Atanasiu Aug 17 '12 at 17:31
-1

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.

IMSoP
  • 65,743
  • 7
  • 83
  • 127
  • 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. – JohnP Aug 12 '12 at 18:55
  • 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. – IMSoP Aug 12 '12 at 22:54
  • 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. – JohnP Aug 13 '12 at 04:46
  • 1
    Fair enough. It was a reasonable theory based on the evidence presented, so I'm glad you've ruled it out experimentally. – IMSoP Aug 13 '12 at 14:13