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

Daniel Stenberg <daniel@haxx.se> Fri, 05 February 2010 09:58 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 DE03D3A6A93 for <http-state@core3.amsl.com>; Fri, 5 Feb 2010 01:58:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 NwFUl9SRe7oK for <http-state@core3.amsl.com>; Fri, 5 Feb 2010 01:58:26 -0800 (PST)
Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by core3.amsl.com (Postfix) with ESMTP id 698D03A67AA for <http-state@ietf.org>; Fri, 5 Feb 2010 01:58:26 -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 o159x9G9020090; Fri, 5 Feb 2010 10:59:09 +0100
Date: Fri, 5 Feb 2010 10:59:09 +0100 (CET)
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: Yngve Nysaeter Pettersen <yngve@opera.com>
In-Reply-To: <op.u7mkruzjvqd7e2@killashandra.oslo.osa>
Message-ID: <alpine.DEB.2.00.1002050932580.3094@tvnag.unkk.fr>
References: <7789133a1001191410l48530adar28098a03e6de0fb1@mail.gmail.com> <op.u7mkruzjvqd7e2@killashandra.oslo.osa>
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: Fri, 05 Feb 2010 09:58:28 -0000

On Thu, 4 Feb 2010, Yngve Nysaeter Pettersen wrote:

> For reference, Opera's sorting is this way:
>
> - Cookies with the most specific domain are sent first. that is, The host's 
> cookies are first, then the parent domain, then the grandparent, and so on
> - For a specific domain the cookies are organized in most specific (longest) 
> path being listed first, then the parent path, and so on.
> - For a specific path it is oldest cookie first.

Thank you, this tells us the current wording of how to sort cookies is not 
quite what Opera uses. I find it interesting that you use the domain before 
the path length, as that will actually make it non-compliant with how the spec 
is currently phrased.

> IMO the cookie with the more specific domain should be sent first, since it 
> will have been set by a server that is closer to the receiving server, if it 
> wasn't the one setting the cookie.

"Make sense" and what we write in the spec isn't necessarily a fit ;-) If the 
major implementations don't sort based on the domain, then we really can't say 
that it is done so very much in the wild.

Did anyone make a test if the domain length has any impact on the cookie sort 
order in other implementations?

> Regarding the specification, I would suggest that it continues to specify 
> ordering, at least for path.

... right, but then you just said that Opera isn't adhering to that spec...

> AFAIK it will not be possible to define an inter-operable domain ordering 
> specification, so instead the specfication should say that servers must not 
> rely on a specific ordering for cookies with the same name set for different 
> domains and the same path (The path specification means that it is perhaps 
> possible to rely on it for same name cookies with different name, even for 
> different domains).

Not only that. Your way even makes sure servers can't unconditionally assume 
the order of cookies with different path lengths, as they must first take into 
account if the cookies have different domains or not.

I think the spec need to say something about this, if nothing else in an 
explanatory way as to why or how different clients may send cookies.

All this cookie ordering taken into account, I think a wise recommendation in 
the spec might be to just advice that cookies using the same name with 
different paths or domains are simply not a good idea to use at all if you 
want to inter-operate.

-- 

  / daniel.haxx.se