Re: [http-state] Ticket 5: Cookie ordering

David Morris <dwm@xpasc.com> Wed, 20 January 2010 05:21 UTC

Return-Path: <dwm@xpasc.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 EC0AF3A697C for <http-state@core3.amsl.com>; Tue, 19 Jan 2010 21:21:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.003
X-Spam-Level:
X-Spam-Status: No, score=-5.003 tagged_above=-999 required=5 tests=[AWL=-2.404, BAYES_00=-2.599]
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 NSbMeGYrRPwC for <http-state@core3.amsl.com>; Tue, 19 Jan 2010 21:21:13 -0800 (PST)
Received: from mail.xpasc.com (mail.xpasc.com [68.164.244.189]) by core3.amsl.com (Postfix) with ESMTP id 37D4C3A692C for <http-state@ietf.org>; Tue, 19 Jan 2010 21:21:12 -0800 (PST)
Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id C675A100585; Tue, 19 Jan 2010 21:21:07 -0800 (PST)
X-Propel-Return-Path: <dwm@xpasc.com>
Received: from mail.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 3.1.1.9347 $Rev: 9262 $) id iz6Ura1k5l70; Tue, 19 Jan 2010 21:21:07 -0800
Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id A6AF2100091; Tue, 19 Jan 2010 21:21:07 -0800 (PST)
Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id o0K5L7IA012492; Tue, 19 Jan 2010 21:21:07 -0800
Date: Tue, 19 Jan 2010 21:21:07 -0800 (PST)
From: David Morris <dwm@xpasc.com>
To: Adam Barth <ietf@adambarth.com>
In-Reply-To: <7789133a1001192113u4c185d9dv9a81afbbae826198@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1001192118410.10824@egate.xpasc.com>
References: <7789133a1001191410l48530adar28098a03e6de0fb1@mail.gmail.com> <Pine.LNX.4.64.1001192044220.10824@egate.xpasc.com> <7789133a1001192113u4c185d9dv9a81afbbae826198@mail.gmail.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="17445122-1494098718-1263964867=:10824"
X-Propel-ID: iz6Ura1k5l70
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] Ticket 5: Cookie ordering
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: Wed, 20 Jan 2010 05:21:15 -0000


On Tue, 19 Jan 2010, Adam Barth wrote:

> On Tue, Jan 19, 2010 at 8:51 PM, David Morris <dwm@xpasc.com> wrote:
>> On Tue, 19 Jan 2010, Adam Barth wrote:
>>> Ticket 3 is still open for discussion, but I'd like to get started
>>> talking the next ticket:
>>> http://trac.tools.ietf.org/wg/httpstate/trac/ticket/5
>>>
>>> == Overview ==
>>>
>>> Currently the draft defines the order in which cookies should appear
>>> in the Cookie header.  In particular, cookies are ordered first by the
>>> length of the Path attribute (longest first) and then by creation date
>>> (earliest first).  The majority of the most widely used user agents
>>> use this ordering. (I can look up exactly which browsers follow the
>>> ordering if that's important.)
>>>
>>> Sending cookies with longer (i.e., more specific) paths first is
>>> important for compatibly because some servers host multiple (mutually
>>> trusting) web applications at different (possibly overlapping) paths.
>>
>> I think 'longer' is not a precise term ... likewise, 'more specific' isn't
>> precise enough to avoid confusion. I think what would be expected is that
>> the path sith the most 'levels' (as noted by '/' characters) is longer in a
>> deeper into the hierarachy sense. Same depth, the age rule could apply.
>>
>> If 'more specific' is already defined similar to what I've outlined,
>> you can igore this comment.
>
> In this case, all the cookie paths are prefixes of the Request-URI
> path, so these all amount to the same thing.  FWIW, longer is a
> precise term: literally the one whose path attribute contains more
> characters.

More characters doesn't seem like the right definition, even if it works 
most of the time. If the argument is, as you've made, that the requirement
is for a server to handle cookies in the most precise order ... it will
be related to logical depth of the hierarchy and not character length.