Safari doesn't set Cookie but IE / FF does

Question

I found a strange cookie problem on safari. If you surf to http://2much.ch you can enter with FF/IE and surf inside the site.

But if you use safari, you can enter only once; you can't surf inside the site. I found that Safari doesn't set the entered cookie, but FF/IE does.

What is wrong here?

Solution 1

It looks like you hit a Safari bug here; you are redirecting any visiting browser to /entry while setting the cookie at the same time, and Safari is ignoring the Set-Cookie header when encountering the 302 HTTP status:

$ curl -so /dev/null -D - http://4much.schnickschnack.info/
HTTP/1.1 302 Moved Temporarily
Server: nginx/0.7.61
Date: Sun, 19 Jul 2009 12:20:49 GMT
Content-Type: text/html;charset=utf-8
Connection: keep-alive
Content-Length: 14260
Content-Language: de
Expires: Sat, 1 Jan 2000 00:00:00 GMT
Location: http://4much.schnickschnack.info/entry
Set-Cookie: colorstyle="bright"; Path=/; Expires=1248092449.12
Set-Cookie: _ZopeId="73230900A39w5NG7q4g"; Path=/

Technically, this would be a bug in Apple's Foundation Classes, I've found a WebKit bug that states this is the case.

I suppose the workaround is to set the cookie not in index_html but in entry instead.

In the intervening years since I first answered this question, this issue now appears solved, at least it was for Safari 6 when someone tested all major browsers for Set-Cookie support on 302 redirects in 2012.

Solution 2

A month ago, I ran into this issue. At first I thought it was a corrupted cookie jar as I could clean out the cookies and go.

However, it popped up again. This time I spent an hour going through it, watching what was sent, reviewing what safari sent back, and I found the problem.

In this case, I had an array of cookie values being sent to the browser after login prior to the redirect. The values looked something like 'user id', 'user full name', 'some other id', etc.

( yes, the id's are encrypted so no worries there )

My user full name was actually in a <lastname>, <firstname> format.

When safari was posting the cookie back to the server, everything after the comma after the lastname was dropped. It was only posting back values up to that point.

When i removed the comma the rest of the values started working just fine.

So it appears that if you send a cookie value that contains a comma, then safari doesn't properly escape that in it's internal storage. Which leads me to think that if they aren't properly escaping commas, then there are probably some security issues with safari's cookie handling code.

Incidentally, this was tested on Win 7 x64 with safari 4.0.5. Also I put up a web page at: http://cookietest.livelyconsulting.com/ which shows this exact problem.(I removed that test site)

IE, FF, and chrome all correctly set the cookie. safari does not.

Solution 3

Looks like this is no longer an issue. See http://blog.dubbelboer.com/2012/11/25/302-cookie.html

Solution 4

We've run into a very similar issue where Safari (v. 7.0.6) would ignore a cookie. The cookie header looked perfectly fine, almost identical to another cookie which was remembered.

It turned out that the culprit was the previous cookie header having a malformed expires value. Safari's handling of broken cookie headers is evidently not as robust as that of the other browsers.

Solution 5

I ran into same issue with Chrome. Chrome doesn't ignore the set-cookie header while you are redirecting, but you never know the order (set cookie first or redirect first). Here is something I have tried:

I have a website, which supports English and French. I implemented it (with php) this way:

localhost has a link to localhost/fr (which set-cookie to French and redirect to localhost). It works. (set cookie first)

localhost/path1 has a link to localhost/fr?return=/path1 (which set-cookie to French and redirect to localhost/path1). It doesn't work. (redirect first, the language didn't change)

localhost/path1 has a link to localhost/fr?return=www.google.com (which set-cookie to French and redirect to google). When I came back to my website again, it's in French. (which means set-cookie to French is not ignored, only executed after redirect)

Hope I make myself clear, English is a foreign language to me.

View more solutions

Comments

[Matthew Groves]

I have nothing to add except: best domain name ever.

[Gomez]

hehe, thx :) Maybe i sell it :)

[Mark van Lent]

Perhaps you can explain a bit about the cookie setting part. For example: is it done by a Plone add-on or custom code?

[Gomez]

The cookie is set by my custom code. It has to be set when you enter, not on 2much/entry. In replay to the Answer i post some code.

[Gomez]

nevermind, works on /entry :) Thx!

[Gomez]

Thanks for the good explication, Martjin! I have put the code into the /entry. Now it works. THX!

[Mark Pauley]

Chris: your issue is completely parser related. It has to do with how CFNetwork coalesces the Set-Cookie headers into one Set-Cookie header during HTTP parse time. Generally, Duplicate HTTP Headers can be coalesced into one header using a ', ' delimiter. Unfortunately, Set-Cookies has been an historically broken header. This was discussed at a recent IETF meeting. There is no issue with the internal representation of the cookies.

[NotMe]

@Mark Pauley: Glad to see an apple dev actively talking about how safari handles cookies. I ran across some of your correspondence at ietf.org/mail-archive/web/http-state/current/msg00645.html I think the fact that safari is the only browser exhibiting this breaking behavior is reason enough to pull the feature.

[NotMe]

I'm not sure why anyone would down vote this nearly a year on; however, the behavior is still broke in Safari 5.0.3.

[Mark Pauley]

Chris: check out the new cookie RFC. It's "the future". rfc-editor.org/rfc/rfc6265.txt

[NotMe]

@Mark Pauley: Thanks for the link! So it looks like things like a quote, semicolon, comma, and backslash should be avoided unless encoded in some way like using base64...

[Andrew Skirrow]

This is nothing to do with the original question

[Radek]

this is obviously still an issue in Safari, see the comments below the article ...

[John Bachir]

What was malformed about the expires value?

[Dag Høidahl]

@JohnBachir Sorry, I don't remember anymore. Probably, the date format was invalid.

[CMerrill]

Nope, it still a problem with Safari 14 on Catalina :(