Re: [http-state] Ticket 5: Cookie ordering
Daniel Stenberg <daniel@haxx.se> Wed, 20 January 2010 12:02 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 169D73A680D for <http-state@core3.amsl.com>; Wed, 20 Jan 2010 04:02:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ELnrXPU8dE8d for <http-state@core3.amsl.com>; Wed, 20 Jan 2010 04:02:37 -0800 (PST)
Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by core3.amsl.com (Postfix) with ESMTP id 751303A683C for <http-state@ietf.org>; Wed, 20 Jan 2010 04:02:37 -0800 (PST)
Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with ESMTP id o0KC2S74021780; Wed, 20 Jan 2010 13:02:28 +0100
Date: Wed, 20 Jan 2010 13:02:28 +0100
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: Adam Barth <ietf@adambarth.com>
In-Reply-To: <7789133a1001200148k1aa148e6qe7d1b900e5b434c7@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1001201053030.26105@tvnag.unkk.fr>
References: <7789133a1001191410l48530adar28098a03e6de0fb1@mail.gmail.com> <alpine.DEB.2.00.1001192327190.27499@tvnag.unkk.fr> <7789133a1001191729g4e0a4827w43a12879d23e289c@mail.gmail.com> <alpine.DEB.2.00.1001200832220.11282@tvnag.unkk.fr> <7789133a1001200148k1aa148e6qe7d1b900e5b434c7@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] 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 12:02:39 -0000
On Wed, 20 Jan 2010, Adam Barth wrote: > It sounds like you're now advocating: > > (3) Require that cookies with longer paths appear before cookies with > shorter paths, but do not require an ordering among cookies with equal path > lengths. I think that cookies using the same name should be presented in an order so that the version with the longest specified path gets presented first. >> The (3) "sort-them-all" approach is indeed the easier way to implement this, >> as figuring out exactly which cookies that have the same name and only >> special-case the order of those will probably be a bigger effort than to >> simply unconditionally sort all cookies based on path length. I mentioned that in an attempt to provide context: I can see why implementors sort all cookies based on the path lengths, and there's nothing wrong in doing that, but I don't think our spec needs to specify that as the sort order is only necessary between cookies using the exact same name (unless a server implementation relies on that order somehow). > You didn't answer my question, which I'll repeat here re-phrased for your > current position: > > Can you explain why (3) provides a better cost / benefit trade-off than (1)? > In particular, what is the advantage of us adopting (3) over (1)? I did answer it but I'll happily do it again slightly clarified: I want us to specify only what needs to be specified and leave the rest to the implementors. I don't think the creation-time of a cookie is relevant so I don't think a client needs to consider it when sending cookies. The advantage for us is that we get one less thing to include in the spec and we get a larger amount of current implementations to qualify as already compliant with the spec. > A) There is a risk that some sites will fail to function properly if the > cookies are presented in another order. Yes, but this risk already exist for all the implementations of today that don't sort cookies (like that) and given the widespread use of non-sorting implementations I guess that server-side reliance on such strict sorting is fairly rare. > B) It is essentially cost-free for user agents to sort cookies in a > particular order, especially in light of the fact that we agree that user > agents must at least sort cookies using a partial order based on path > length. No, it's not cost-free - nothing really is. I already described one scenario in which the cookie's creation time gets discarded (the netscape cookie file format), and I can also easily find several cookie implementations that currently completely ignore the creation-time. They would be deemed incompatible and they would need to be fixed. The current implementations that already sort wouldn't break the spec so thus we would cover more existing implementions by not specifying the sort order like that. Not to mention how every added complexity in the spec makes it harder for all future implementations. It would deem servers that rely on the date-sorting non-compliant. > I'd rather made decisions based on data and technical arguments instead of > assumptions. Me too, but we don't have such data in this discussion - even though I think we all would appreciate and enjoy it. And even if we had data and numbers (that we all thought was the objective truth), there would still be a discussion around what percentage of servers or clients that would matter and count as "existing practise". Is 10% enough? 1% 0.1%? 0.01%? etc. > This is a good technical argument. Maybe we should state that the creation > time ordering is required only if the creation time information is available > to the user agent. Isn't that rather half-baked and pointless? It is required, but if you don't have the info it isn't required anymore. How could a server side implementation then assume anything about the sort order since they cannot possibly know when the client had the required info or not? In reality that takes away the requirement. And without the requirement, why specify it at all? I wish we knew if there are any actual servers that rely on the time sort. It would help this discussion a lot I think. -- / daniel.haxx.se
- [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Daniel Stenberg
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering David Morris
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering David Morris
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Daniel Stenberg
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Daniel Stenberg
- Re: [http-state] Ticket 5: Cookie ordering Dan Winship
- Re: [http-state] Ticket 5: Cookie ordering Dan Winship
- Re: [http-state] Ticket 5: Cookie ordering Maciej Stachowiak
- Re: [http-state] Ticket 5: Cookie ordering Anne van Kesteren
- Re: [http-state] Ticket 5: Cookie ordering Yngve Nysaeter Pettersen
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Yngve Nysaeter Pettersen
- Re: [http-state] Ticket 5: Cookie ordering Daniel Stenberg
- Re: [http-state] Ticket 5: Cookie ordering Yngve Nysaeter Pettersen
- Re: [http-state] Ticket 5: Cookie ordering Dan Witte
- Re: [http-state] Ticket 5: Cookie ordering Paul E. Jones
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Achim Hoffmann
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Dan Witte
- Re: [http-state] Ticket 5: Cookie ordering Achim Hoffmann
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Daniel Stenberg
- Re: [http-state] Ticket 5: Cookie ordering Achim Hoffmann