views:

265

answers:

2

I set up an A/B test which required a fairly large amount of data to be stored in a cookie temporarily. While testing my code, I managed to get the cookie over 4kB. Safari set the cookie. On the subsequent page load, Apache returned an error since the cookie was too large.

I tested this on Firefox as well and it simply ignores the cookie, which seems to be the correct behavior to me.

I've seen this happen before first-hand on GMail. I used to get Bad Request errors and would have to delete my cookies. It was a known issue that's been resolved.

I can find nothing online about Safari allowing cookies over 4kB. Isn't this potentially dangerous? The idea that our users could be blocked from accessing our site and have no idea what's going on is scary. I don't know off the top of my head how it'd be possible to delete those cookies from our side if they got too large.

Why does Safari do this? Do any other browsers?

+2  A: 

http://www.nczonline.net/blog/2008/05/17/browser-cookie-restrictions/ says that firefox and safari allow cookies up to 4097 characters, IE 4095 and opera 4096

there is something here about fixing the issue when the error happens, basically the error document clears the offending cookie so subsequent request will work (hopefully) http://www.webmasterworld.com/forum92/1163.htm

John Boker
Thanks. The second page you linked to has some helpful tips, should they be necessary.
joshuaxls
A: 

The standard specifies a certain minimum size for cookies. However, it does not specify a maximum size. Any browser can store a cookie of any size, as long as it's at least 4kb. As a web developer, you try to only create cookies that work in all browsers. It's not up to safari to hold your hand on this point- It is simply dealing with the condition of a large cookie by accepting it, where others reject it. This is neither correct, nor incorrect. It is simply allowed.

I don't follow your point about it being potentially dangerous. If a user is blocked from your site, because of a cookie that you are setting doesn't work in some browsers, that is your fault, isn't it? Safari is just dealing with it where other browsers don't.

Breton
Yes, you're correct about the specification. I just find it unfortunate that the way things are set up, it's easy to get yourself caught in a trap with browsers accepting oversized cookies and web servers rejecting them. Webkit seems to be the outlier here. Other browsers I've tested won't accept the cookie.A search for "bad request cookie" shows that Google, Youtube, and other sites have had this problem. It is dangerous. But I guess you're right, in the end you can't blame anyone but yourself.
joshuaxls
There's a long history of developers getting around this limitation of course. If you really need to store a bunch of information, most serverside frameworks can store "session" data. That is, a cookie becomes merely a key into a database entry on the server that contains the real info. asp.NET makes the whole page into a giant form, and stows information into hidden fields, and captures all link clicks with javascript. All the new browsers, have a new 'webstorage" api accessible from javascript.
Breton
Yes, I'm well aware of this. We do around 10 million page views a day and try to limit the load on our DB as much as possible, hence the cookie-based test. But now we're stuck with the DB-backed test.
joshuaxls
well... you could limit the db backed test to browsers that don't support the webstorage api. At the moment that's just ie6, ie7, and. .. well that's it, really, for the popular browsers. If you're interested in a bit of hackery, the flash plugin can create big cookies. Also, there are javascript libs that abstract all these different technologies into a single interface, and search for support starting with the nicest ones first.
Breton