Safari 5 does not send all cookies back to the server

Question

I see this problem with Safari 5 (in fact, it has been distributed since at least 4.0.5), where it seems that it does not set cookies properly. The site is great for Firefox, IE, and Chrome.

However, I can verify that the cookie is set correctly by viewing the cookies Safari cookies that it uses. On Windows 7, it is stored here: C: \ Users \\ AppData \ Roaming \ Apple Computer \ Safari \ Cookies \ Cookies.plist

Now the site I'm working on uses cookies quite widely and is stored in different domains.

Say, for example, the site www.foo.com. The login cookie is set to .foo.com. In addition, other cookies are stored in the domain www.foo.com, a.foo.com, b.foo.com, etc.

Safari seems to get confused when going to www.foo.com and forgets to send all the cookies it should (www.foo.com, .foo.com).

I am not sure if this is an error on my side (invalid characters in the cookie), or if it is an error with Safari. I would like to know if anyone met this and found

Thanks!

Edit: The one cookie that bothers me is quite large, slightly less than 4k in length. It contains encoded information and the characters it consists of are alphanumeric and / + _ =

Now, what is strange is that depending on the domain on which the cookie is set, the cookie works fine by itself. However, when the user logs in, another cookie is added, and Safari seems to ignore the first one. Safari sends a login cookie and consists of alphanumeric characters along with [] _ ​​\

My initial thought was that it could be a domain conflict. The first cookie was set to www.foo.com, while the login cookie was set to .foo.com. However, I tested this theory by installing both of them on .foo.com, and the problem still remains.

Answer 1

Look at the browser size limits here . Safari 5 has a 4k limit per request. Therefore, if the total size of all cookies for a domain (including associated domain names) exceeds 4k, you will begin to lose cookies. I believe that the logic is that the oldest cookie will be sacrificed first until the total size of the cookie header drops below 4k.

We currently have a problem with this problem, but also identified another scenario in which cookies are lost, although we still have to understand why this is so.

Given the large size of one of your cookies, probably the following request adds a new cookie, pushing the total size outside.