Re: [http-state] Updated draft

Daniel Stenberg <daniel@haxx.se> Sun, 16 August 2009 18:10 UTC

Return-Path: <daniel@haxx.se>
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 C95513A6BD3 for <http-state@core3.amsl.com>; Sun, 16 Aug 2009 11:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.856
X-Spam-Level:
X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 GFVcldBtPaHz for <http-state@core3.amsl.com>; Sun, 16 Aug 2009 11:10:34 -0700 (PDT)
Received: from kluster1.contactor.se (kluster1.contactor.se [91.191.140.11]) by core3.amsl.com (Postfix) with ESMTP id 06D043A6915 for <http-state@ietf.org>; Sun, 16 Aug 2009 11:10:33 -0700 (PDT)
Received: from linux2.contactor.se (linux2.contactor.se [91.191.140.14]) by kluster1.contactor.se (8.13.8/8.13.8/Debian-3) with ESMTP id n7GIAY3r011934; Sun, 16 Aug 2009 20:10:34 +0200
Date: Sun, 16 Aug 2009 20:10:34 +0200
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@linux2.contactor.se
To: Adam Barth <ietf@adambarth.com>
In-Reply-To: <7789133a0908161032l2265ce5fg966c434f1b05aa64@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.0908161952060.13789@yvahk2.pbagnpgbe.fr>
References: <7789133a0908151008p35ff30e6w2761368fe70d41a6@mail.gmail.com> <alpine.DEB.2.00.0908152250410.18461@yvahk2.pbagnpgbe.fr> <7789133a0908151642w47c1dbf1x48268e657b0d71cc@mail.gmail.com> <alpine.DEB.2.00.0908161440520.25988@yvahk2.pbagnpgbe.fr> <7789133a0908161032l2265ce5fg966c434f1b05aa64@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Cc: 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: Sun, 16 Aug 2009 18:10:35 -0000

On Sun, 16 Aug 2009, Adam Barth wrote:

> I've added tests for both these behaviors to the test suite.  Here's how the 
> five most popular browser behave:

...

> Based on this data, it seems reasonable to spec "sort first on path length 
> and sort second on creation time."  I don't think we'd want to spec any 
> other ordering, and I don't see the benefit of not specing the ordering in 
> the user agent conformance section.

I beg to differ.

First, this sorting was not in the Netscape cookie spec but is only found in 
RFC2109 and RFC2965.

Then, since clearly user agents that don't do any sorting of the cookies can 
play fine against the vast majority of all sites this seems like a client-side 
invention that have no particular meaning to existing servers. So by 
specifying the sort order you not only make a lot of client code 
"non-compliant" all of a sudden, I think you're also over-specifying something 
that doesn't need to be specified.

As far as I can understand, it could only really have a meaning if more than 
50 (or so) cookies are stored for a domain as then the sort order would decide 
which cookies to discard (or rather not include in the Cookie: header). But 
that won't have to imply that the 50 cookies that ARE sent have to be sent in 
this sorted order.

-- 

  / daniel.haxx.se