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

"Yngve Nysaeter Pettersen" <yngve@opera.com> Fri, 05 February 2010 12:56 UTC

Return-Path: <yngve@opera.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 EF8033A6D78 for <http-state@core3.amsl.com>; Fri, 5 Feb 2010 04:56:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4]
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 AsbI90bkbjzB for <http-state@core3.amsl.com>; Fri, 5 Feb 2010 04:56:24 -0800 (PST)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 94D333A6D6B for <http-state@ietf.org>; Fri, 5 Feb 2010 04:56:23 -0800 (PST)
Received: from killashandra.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id o15CrFBO014709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Feb 2010 12:53:16 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Daniel Stenberg" <daniel@haxx.se>
References: <7789133a1001191410l48530adar28098a03e6de0fb1@mail.gmail.com> <op.u7mkruzjvqd7e2@killashandra.oslo.osa> <alpine.DEB.2.00.1002050932580.3094@tvnag.unkk.fr>
Date: Fri, 05 Feb 2010 13:56:58 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve Nysaeter Pettersen" <yngve@opera.com>
Organization: Opera Software
Message-ID: <op.u7nnk8uyvqd7e2@killashandra.oslo.osa>
In-Reply-To: <alpine.DEB.2.00.1002050932580.3094@tvnag.unkk.fr>
User-Agent: Opera Mail/10.10 (Win32)
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
Reply-To: yngve@opera.com
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 12:56:25 -0000

On Fri, 05 Feb 2010 10:59:09 +0100, Daniel Stenberg <daniel@haxx.se> wrote:

>> 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.

There is also the issue that if ordering, even at the domain level is not  
specified, then there will be problems if a server treats ordering as  
significant, such as only checking the first cookie with the name it is  
looking for.

If we call this server bar.example.com, and assumes it is looking for and  
sets the cookie MyCookie=bar for the host itself (no domain), and we also  
have a server foo.example.com that sets MyCookie=foo for the domain  
.example.com the following can occur if ordering is that first received  
cookie is first in line

If the client visits bar.example.com first, then foo.example.com, order by  
creation date will produce the MyCookie sequence "bar, foo", if  
foo.example.com is visited first then the sequence will be "foo, bar". In  
the latter case bar.example.com will not find its cookie, and may  
repeatedly try to set it. Any update of the cookie (unless original  
creation date is preserved) will move the newest cookie to the last  
position in the list.

If the ordering is most recently set/updated the sequences would be  
reversed (bar first gives "foo, bar", foo first gives "bar, foo"), and the  
bar server would run into problems on the first access after the client  
visited foo, but that would be fixed with sending a new cookie, but the  
session would be lost.

In Opera the sequence would always be "bar,foo" since the foo cookie is  
set for the parent domain which is listed later.

IOW, if ordering is determined by anything but the domain and path the  
sequence of cookie is going to vary depending on which servers the clients  
visits and the sequence it visits them, and this might cause significant  
problems for a server that considers ordering significant.



-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************