Re: [http-state] Summary of discussion of Ticket 5 (Cookie ordering)

Adam Barth <ietf@adambarth.com> Thu, 15 April 2010 23:16 UTC

Return-Path: <ietf@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 4B23F3A6940 for <http-state@core3.amsl.com>; Thu, 15 Apr 2010 16:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.344
X-Spam-Level:
X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[AWL=-0.279, 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 hISawdTIreBj for <http-state@core3.amsl.com>; Thu, 15 Apr 2010 16:16:34 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C8E083A6869 for <http-state@ietf.org>; Thu, 15 Apr 2010 16:16:18 -0700 (PDT)
Received: by wyb40 with SMTP id 40so93242wyb.31 for <http-state@ietf.org>; Thu, 15 Apr 2010 16:16:08 -0700 (PDT)
Received: by 10.216.162.198 with SMTP id y48mr824858wek.49.1271373367952; Thu, 15 Apr 2010 16:16:07 -0700 (PDT)
Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by mx.google.com with ESMTPS id x14sm15536669wbs.12.2010.04.15.16.16.05 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 16:16:07 -0700 (PDT)
Received: by iwn27 with SMTP id 27so948388iwn.5 for <http-state@ietf.org>; Thu, 15 Apr 2010 16:16:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.177.225 with HTTP; Thu, 15 Apr 2010 16:15:44 -0700 (PDT)
In-Reply-To: <C779AE1F-EE2B-4D87-A3F1-C91A425E339D@apple.com>
References: <5c4444771002151547k75bbd0e7rfd2ccf735bdb2e37@mail.gmail.com> <u2o5c4444771004110954tfbb069ddj6f80356bc4bd47d3@mail.gmail.com> <C779AE1F-EE2B-4D87-A3F1-C91A425E339D@apple.com>
From: Adam Barth <ietf@adambarth.com>
Date: Thu, 15 Apr 2010 16:15:44 -0700
Received: by 10.231.79.136 with SMTP id p8mr306334ibk.4.1271373364092; Thu, 15 Apr 2010 16:16:04 -0700 (PDT)
Message-ID: <z2m5c4444771004151615r10f95fen683406b64abff6fa@mail.gmail.com>
To: Work <mpauley@apple.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] Summary of discussion of 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: Thu, 15 Apr 2010 23:16:38 -0000

On Sun, Apr 11, 2010 at 11:53 AM, Work <mpauley@apple.com> wrote:
> Sorry, I should have spoken up on this. I think that ideally the length of
> the domain attribute and the length of the path are the only functionally
> relevant ordering criteria.
>
> In all cases, the most specific cookies ought to come first or web
> applications won't be able to explicitly set a cookie on a given domain and
> expect that siblings can't overturn said cookie.
>
> However, it doesn't seem that specifying new behavior is really in the scope
> of this document, so I'm okay with a SHOULD classification of the current
> most common ad-hoc ordering and a MUST not for server dependance on any
> given ordering.

We've generally shied away from MUST-level requirements for server
operators.  For example, we don't even have a MUST-level requirement
for not sending duplicate, conflicting attribute values.  We already
have a SHOULD-level requirement on servers, which hopefully explains
to folks who read the spec why order dependence is a bad idea.

As for the level of conformance requirement for the de facto / ad-hoc
ordering, a SHOULD-level requirement on the ordering might be a good
way to resolve this issue given the variety of opinion we've seen on
the list.  I'll write this up and add some more explanatory text to
help using agent implementors understand this requirement.

Thanks,
Adam


> On Apr 11, 2010, at 9:54 AM, Adam Barth <ietf@adambarth.com> wrote:
>
>> In the two months since I sent this email, there hasn't been a whole
>> lot more discussion on this topic.  We discussed the issue at the
>> working group meeting at IETF77.  Unfortunately, Daniel Stenberg
>> wasn't in attendance, so we missed out on his perspective.
>>
>> A number of people (apologies for not recalling who) thought it was
>> important to specify the ordering.  Various folks had various ideas
>> about which ordering to use, although most agreed that the specific
>> ordering is less important than the need to specify an ordering.
>>
>> My perspective is that we can debate endlessly which ordering to use
>> even though the particular ordering we choose doesn't matter nearly as
>> much as getting user agents to interoperate on some ordering.
>> Therefore, I'm going to leave the ordering requirement in the draft
>> and specify the ordering that Firefox (and some other browsers) use.
>> (Note that the draft admonishes server operators not to rely upon the
>> ordering.)
>>
>> Adam
>>
>>
>> On Mon, Feb 15, 2010 at 4:47 PM, Adam Barth <ietf@adambarth.com> wrote:
>>>
>>> For reasons I don't entirely understand, the order cookies are
>>> presented in the Cookie header is somewhat controversial.  The
>>> discussion seems to have quieted down to some extent, so I thought now
>>> might be a good time to summarize what's been said thus far.
>>>
>>> == General Principles ==
>>>
>>> Daniel Stenberg suggests that we should specify only what needs to be
>>> specified and leave the rest to the implementors.  In particular, we
>>> should specify and document what needs to be done in order to work
>>> with the vast majority of sites, where he takes the "vast majority of
>>> sites" to be all (except three or more) of the top 500 sites.  He
>>> appears unwilling to specify a behavior if it's a very rare assumption
>>> that we can declare a server bug.  However, if sufficiently many
>>> servers assume that clients behave in a certain way, then we ought to
>>> specify that behavior.
>>>
>>> In the absence of evidence about what servers require, Adam Barth
>>> argues that we should specify the most specific behavior that is
>>> deployed by the most commonly used implementations.
>>>
>>> == Technical Details ==
>>>
>>> Daniel Stenberg agrees that the "most specific" version of two cookies
>>> with the same name should be sent first.  He agrees that the
>>> "sort-them-all" approach is the easiest to implement.  Based on this
>>> experience implementing libcurl, he doesn't think the creation-time of
>>> a cookie is relevant.
>>>
>>> Dan Winship supports specify the ordering, but mostly on general
>>> principles rather than specific implementation experience.
>>>
>>> Maciej Stachowiak would like a breakdown of which user agents employ
>>> which sorting algorithms.  He agues that not specifying the sort order
>>> isn't viable.
>>>
>>> Anne van Kesteren supports specify the ordering.
>>>
>>> Yngve Pettersen suggests that we continue to specify the ordering, at
>>> least for path.  Later, he recommends sorting on domain and path,
>>> ignoring creation-time (because creation-time is less predictable).
>>> He notes that Opera sorts based on domain first, path second, and
>>> creation-time third.
>>>
>>> Dan Witte confirms that Firefox sorts by path length and then by
>>> creation-time.  When Firefox dropped the creation-time sorting in
>>> 2004, at least one site broke, prompting Firefox to reinstate
>>> creation-time sorting.  He would be willing to change Firefox to match
>>> IE because he dislikes creation-time sorting (but implemented it
>>> because of compatibility issues).
>>>
>>> Paul E. Jones is skeptical that servers will be able to rely on user
>>> agent sorting behavior and would prefer that user agents never send
>>> two cookies with the same name.
>>>
>>> Achim Hoffmann notes that the cookie sequence is really important.  He
>>> is aware of some serious attacks (miss)using the order of cookies.  He
>>> recommends a specific sorting based on seven factors.
>>>
>>> == Specification Changes ==
>>>
>>> I've added this requirement to the server conformance section:
>>>
>>> [[
>>>         <t>Although cookies are serialized linearly in the Cookie header,
>>>         servers SHOULD NOT rely upon the serialization order. In
>>> particular,
>>>         if the Cookie header contains two cookies with the same name,
>>>         servers SHOULD NOT rely upon the order in which these cookies
>>> appear
>>>         in the header.</t>
>>> ]]
>>>
>>> == Action Items ==
>>>
>>> 1) Adam Barth will generate the compatibility matrix requested by
>>> Maciej Stachowiak.
>>>
>>> Adam
>>>
>> _______________________________________________
>> http-state mailing list
>> http-state@ietf.org
>> https://www.ietf.org/mailman/listinfo/http-state
>