[http-state] Ticket 5: Cookie ordering

Adam Barth <ietf@adambarth.com> Tue, 19 January 2010 22:11 UTC

Return-Path: <adam@adambarth.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 68F7A3A683A for <http-state@core3.amsl.com>; Tue, 19 Jan 2010 14:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 kUY75zqN4MxK for <http-state@core3.amsl.com>; Tue, 19 Jan 2010 14:11:18 -0800 (PST)
Received: from mail-iw0-f174.google.com (mail-iw0-f174.google.com [209.85.223.174]) by core3.amsl.com (Postfix) with ESMTP id 7B7DA3A67F7 for <http-state@ietf.org>; Tue, 19 Jan 2010 14:11:15 -0800 (PST)
Received: by iwn4 with SMTP id 4so3364967iwn.31 for <http-state@ietf.org>; Tue, 19 Jan 2010 14:11:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.144.81 with SMTP id y17mr1022485ibu.99.1263939068346; Tue, 19 Jan 2010 14:11:08 -0800 (PST)
From: Adam Barth <ietf@adambarth.com>
Date: Tue, 19 Jan 2010 14:10:48 -0800
Message-ID: <7789133a1001191410l48530adar28098a03e6de0fb1@mail.gmail.com>
To: http-state <http-state@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [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: Tue, 19 Jan 2010 22:11:19 -0000

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.

== Proposal ==

(1) Continue to specify the ordering.

== Alternatives ==

(2) Do not specify an ordering for cookies in the Cookie header.  This
alternative reduces interoperability between user agents because user
agents that serialize cookies in different orders will operate
different than each other.  As the most popular user agents already
order cookies, user agents with less market share can gain
interoperability by matching the consensus ordering.

(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.  This approach maximizes user agent flexibility while
meeting the most important compatibility needs, but it's unclear to me
that there is value in maximizing user agent flexibility in this
regard.  It seems like if we're going to specify an ordering for
cookies, we might as well specify the total ordering used by the most
popular user agents.