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 (CET)
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