[http-state] Cookie storage limits (was Re: Updated draft)

Adam Barth <ietf@adambarth.com> Mon, 17 August 2009 16:48 UTC

Return-Path: <adam@adambarth.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C5528C21C for <http-state@core3.amsl.com>; Mon, 17 Aug 2009 09:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.54
X-Spam-Level:
X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_50=0.001, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aysy-a7PfN9 for <http-state@core3.amsl.com>; Mon, 17 Aug 2009 09:48:47 -0700 (PDT)
Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id 206AE28C1D2 for <http-state@ietf.org>; Mon, 17 Aug 2009 09:48:46 -0700 (PDT)
Received: by vws34 with SMTP id 34so2701292vws.31 for <http-state@ietf.org>; Mon, 17 Aug 2009 09:48:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.17.129 with SMTP id s1mr4944076vca.115.1250527725197; Mon, 17 Aug 2009 09:48:45 -0700 (PDT)
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 17 Aug 2009 09:48:25 -0700
Message-ID: <7789133a0908170948j47d4ec08rc53c8c764c42446@mail.gmail.com>
To: Bil Corry <bil@corry.biz>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: Daniel Stenberg <daniel@haxx.se>, http-state <http-state@ietf.org>
Subject: [http-state] Cookie storage limits (was Re: Updated draft)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2009 16:48:48 -0000

On Mon, Aug 17, 2009 at 9:34 AM, Bil Corry<bil@corry.biz> wrote:
> A bit dated, Nicholas Zakas of Yahoo! talks about the maximum number of cookies[1]:
>
> ---8<---
>    * Microsoft indicated that Internet Explorer 8 increased the cookie limit per domain to 50 cookies but I’ve found that IE7 also allows 50 cookies per domain. Granted, this may have been increased with a system patch rather than having the browser’s first version ship like this, but it’s still more than the 20 that was commonly understood to be the limit.

I discussed this issue with Eric Lawrence.  Apparently, IE raised the
cookie limit from 20 to 50 in a patch to improve compatibility with a
major site that required 24 cookies to function properly.  This patch
rendered a major Japanese bank's web site completely inoperable
because it was relying on the browser to evict the 21rst cookie and
fell over and died when it got too many cookies.  There was strong
pressure to reverse the patch, but they did not.

>    * Firefox has a per-domain cookie limit of 50 cookies.
>    * Opera has a per-domain cookie limit of 30 cookies.
>    * Safari/WebKit is the most interesting of all as it appears to have no perceivable limit through Safari 3.1. I tested setting up to 10,000 cookies and all of them were set and sent along in the Cookie header. The problem is that the header size exceeded the limit that the server could process, so an error occurred.
> --->8---

Yeah, so if I were writing a cookie implementation today, I would
definitely use 50 cookies per domain.  However, putting that as a hard
limit into the spec doesn't seem very future proof.  I think
suggesting a limit of 50 is appropriate because that's the limit used
by >90% of the market.

> He also mentions differences in cookie eviction:
>
> ---8<---
>   1. The least recently used (LRU) approach automatically kicks out the oldest cookie when the cookie limit has been reached in order to allow the newest cookie some space. Internet Explorer and Opera use this approach.
>   2. Firefox does something strange: it seems to randomly decide which cookies to keep although the last cookie set is always kept. There doesn’t seem to be any scheme it’s following at all. The takeaway? Don’t go above the cookie limit in Firefox.
> --->8---

The draft current specs LRU for cookie eviction, but I haven't figured
out a good way to test this yet.  It might be worth reading Firefox's
code to understand what algorithm they're using.

> And differences in cookie size support (although this conflicts with results Daniel Stenberg posted earlier[2]):
>
> ---8<---
>    * Firefox and Safari allow cookies with up to 4097 characters, that’s 4096 for the name and value and one for the equals sign.
>    * Opera allows cookies with up to 4096 characters, which is for the name, value, and equals sign.
>    * Internet Explorer allows cookies with up to 4095 characters, which is for the name, value and, equals sign.
> --->8---

Interesting.  I have two size limit tests, but I haven't figured out
anything conclusive here.  Looks like the limit is something on the
order of 4096.  We should definitely try to figure out some broadly
interoperable, least common denominator limits to recommend in the
server conformance section.

Adam