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?

Answer 1

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.

Answer 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.

Answer 3

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.

Answer 4

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

Answer 5

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.