[http-state] Summary of discussion of Ticket 5 (Cookie ordering)
Adam Barth <ietf@adambarth.com> Mon, 15 February 2010 23:46 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 F101028C140 for <http-state@core3.amsl.com>;
Mon, 15 Feb 2010 15:46:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.865
X-Spam-Level:
X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.112,
BAYES_00=-2.599, 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 wZw8Oc0pcyXk for
<http-state@core3.amsl.com>; Mon, 15 Feb 2010 15:46:11 -0800 (PST)
Received: from mail-iw0-f199.google.com (mail-iw0-f199.google.com
[209.85.223.199]) by core3.amsl.com (Postfix) with ESMTP id DFB6F28C145 for
<http-state@ietf.org>; Mon, 15 Feb 2010 15:46:10 -0800 (PST)
Received: by iwn37 with SMTP id 37so4138364iwn.22 for <http-state@ietf.org>;
Mon, 15 Feb 2010 15:47:40 -0800 (PST)
Received: by 10.231.154.197 with SMTP id p5mr4267937ibw.28.1266277658687;
Mon, 15 Feb 2010 15:47:38 -0800 (PST)
Received: from mail-iw0-f199.google.com (mail-iw0-f199.google.com
[209.85.223.199]) by mx.google.com with ESMTPS id
22sm747385iwn.8.2010.02.15.15.47.37 (version=SSLv3 cipher=RC4-MD5);
Mon, 15 Feb 2010 15:47:37 -0800 (PST)
Received: by iwn37 with SMTP id 37so4138346iwn.22 for <http-state@ietf.org>;
Mon, 15 Feb 2010 15:47:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.144.201 with SMTP id a9mr2510332ibv.69.1266277657064;
Mon, 15 Feb 2010 15:47:37 -0800 (PST)
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 15 Feb 2010 15:47:17 -0800
Message-ID: <5c4444771002151547k75bbd0e7rfd2ccf735bdb2e37@mail.gmail.com>
To: http-state <http-state@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [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: Mon, 15 Feb 2010 23:46:12 -0000
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] Summary of discussion of Ticket 5 (C… Adam Barth
- Re: [http-state] Summary of discussion of Ticket … Adam Barth
- Re: [http-state] Summary of discussion of Ticket … Daniel Stenberg
- Re: [http-state] Summary of discussion of Ticket … Work
- Re: [http-state] Summary of discussion of Ticket … Work
- Re: [http-state] Summary of discussion of Ticket … Adam Barth
- Re: [http-state] Summary of discussion of Ticket … Adam Barth
- Re: [http-state] Summary of discussion of Ticket … Achim Hoffmann
- Re: [http-state] Summary of discussion of Ticket … Daniel Stenberg
- Re: [http-state] Summary of discussion of Ticket … Dan Winship
- Re: [http-state] Summary of discussion of Ticket … Achim Hoffmann
- Re: [http-state] Summary of discussion of Ticket … Achim Hoffmann
- Re: [http-state] Summary of discussion of Ticket … Adam Barth
- Re: [http-state] Summary of discussion of Ticket … Daniel Stenberg
- Re: [http-state] Summary of discussion of Ticket … Dan Winship
- Re: [http-state] Summary of discussion of Ticket … Daniel Stenberg