[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.
- [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Daniel Stenberg
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering David Morris
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering David Morris
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Daniel Stenberg
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Daniel Stenberg
- Re: [http-state] Ticket 5: Cookie ordering Dan Winship
- Re: [http-state] Ticket 5: Cookie ordering Dan Winship
- Re: [http-state] Ticket 5: Cookie ordering Maciej Stachowiak
- Re: [http-state] Ticket 5: Cookie ordering Anne van Kesteren
- Re: [http-state] Ticket 5: Cookie ordering Yngve Nysaeter Pettersen
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Yngve Nysaeter Pettersen
- Re: [http-state] Ticket 5: Cookie ordering Daniel Stenberg
- Re: [http-state] Ticket 5: Cookie ordering Yngve Nysaeter Pettersen
- Re: [http-state] Ticket 5: Cookie ordering Dan Witte
- Re: [http-state] Ticket 5: Cookie ordering Paul E. Jones
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Achim Hoffmann
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Dan Witte
- Re: [http-state] Ticket 5: Cookie ordering Achim Hoffmann
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- Re: [http-state] Ticket 5: Cookie ordering Daniel Stenberg
- Re: [http-state] Ticket 5: Cookie ordering Achim Hoffmann