Re: [http-state] Updated draft

Bil Corry <bil@corry.biz> Mon, 17 August 2009 16:35 UTC

Return-Path: <bil@corry.biz>
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 0F6C928C26E for <http-state@core3.amsl.com>; Mon, 17 Aug 2009 09:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.993
X-Spam-Level:
X-Spam-Status: No, score=-0.993 tagged_above=-999 required=5 tests=[AWL=-1.858, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311]
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 oPLnfGXFJq39 for <http-state@core3.amsl.com>; Mon, 17 Aug 2009 09:35:08 -0700 (PDT)
Received: from mail.mindio.com (app1.bc.anu.net [193.189.141.126]) by core3.amsl.com (Postfix) with ESMTP id 60B6B28C2AD for <http-state@ietf.org>; Mon, 17 Aug 2009 09:34:57 -0700 (PDT)
Received: from [127.0.0.1] (unknown [98.212.72.151]) by mail.mindio.com (Postfix) with ESMTP id 8A04AFC451; Mon, 17 Aug 2009 11:34:50 -0500 (CDT)
Message-ID: <4A8986A3.9000403@corry.biz>
Date: Mon, 17 Aug 2009 11:34:43 -0500
From: Bil Corry <bil@corry.biz>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Adam Barth <ietf@adambarth.com>
References: <7789133a0908151008p35ff30e6w2761368fe70d41a6@mail.gmail.com> <alpine.DEB.2.00.0908152250410.18461@yvahk2.pbagnpgbe.fr> <7789133a0908151642w47c1dbf1x48268e657b0d71cc@mail.gmail.com>
In-Reply-To: <7789133a0908151642w47c1dbf1x48268e657b0d71cc@mail.gmail.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Cc: Daniel Stenberg <daniel@haxx.se>, http-state <http-state@ietf.org>
Subject: Re: [http-state] 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:35:09 -0000

Adam Barth wrote on 8/15/2009 6:42 PM: 
>> Is that really a MUST? There's no fixed 50 cookies limit in curl at least
>> and I would be surprised if all other HTTP clients would agree on this. May
>> I suggest that to be written a MAY instead?
> 
> Done.  I have it on good authority that there exist sites that break
> if you change this number.  However, I've softened the draft to make
> 50 only a suggestion.

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


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


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



- Bil

[1] http://www.nczonline.net/blog/2008/05/17/browser-cookie-restrictions/
[2] http://www.ietf.org/mail-archive/web/http-state/current/msg00115.html