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

"Yngve Nysaeter Pettersen" <yngve@opera.com> Thu, 04 February 2010 22:57 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 0ECFD28C1E8 for <http-state@core3.amsl.com>; Thu, 4 Feb 2010 14:57:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 zVW2hZdWwNhj for <http-state@core3.amsl.com>; Thu, 4 Feb 2010 14:57:50 -0800 (PST)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id DCC7F3A6E70 for <http-state@ietf.org>; Thu, 4 Feb 2010 14:57:49 -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 o14MsoC5013389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Feb 2010 22:54:51 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Adam Barth" <ietf@adambarth.com>, http-state <http-state@ietf.org>
References: <7789133a1001191410l48530adar28098a03e6de0fb1@mail.gmail.com>
Date: Thu, 04 Feb 2010 23:58:32 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve Nysaeter Pettersen" <yngve@opera.com>
Organization: Opera Software
Message-ID: <op.u7mkruzjvqd7e2@killashandra.oslo.osa>
In-Reply-To: <7789133a1001191410l48530adar28098a03e6de0fb1@mail.gmail.com>
User-Agent: Opera Mail/10.10 (Win32)
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: Thu, 04 Feb 2010 22:57:51 -0000

On Tue, 19 Jan 2010 23:10:48 +0100, Adam Barth <ietf@adambarth.com> wrote:

> Ticket 3 is still open for discussion, but I'd like to get started
> talking the next ticket:
> http://trac.tools.ietf.org/wg/httpstate/trac/ticket/5
>
> == Overview ==
>
> Currently the draft defines the order in which cookies should appear
> in the Cookie header.  In particular, cookies are ordered first by the
> length of the Path attribute (longest first) and then by creation date
> (earliest first).  The majority of the most widely used user agents
> use this ordering. (I can look up exactly which browsers follow the
> ordering if that's important.)
>
> Sending cookies with longer (i.e., more specific) paths first is
> important for compatibly because some servers host multiple (mutually
> trusting) web applications at different (possibly overlapping) paths.
> For example, mail.google.com hosts a public instance of Gmail at
> https://mail.google.com/ and corporate instances of Gmail at
> https://mail.google.com/a/example.com/.  These web applications expect
> their own cookies (with the more specific path) to be presented before
> cookies for other web applications (even if the cookies have the same
> names).  In fact, this behavior is required by the original Netscape
> cookie spec.


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.

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.

Our way of selecting and sending cookies follows naturally from how the  
cookie database is organized: As a Tree.

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

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

Short of using RFC2965 cookies it is not possible to discover the domains  
or paths for two cookies with the same name (unless it is coded in the  
value)

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