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

Adam Barth <ietf@adambarth.com> Mon, 08 February 2010 17:00 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 CE7983A746E for <http-state@core3.amsl.com>; Mon, 8 Feb 2010 09:00:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.838
X-Spam-Level:
X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.139, 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 xyOZ5NpPEw1e for <http-state@core3.amsl.com>; Mon, 8 Feb 2010 09:00:07 -0800 (PST)
Received: from mail-pz0-f173.google.com (mail-pz0-f173.google.com [209.85.222.173]) by core3.amsl.com (Postfix) with ESMTP id 4868E3A7467 for <http-state@ietf.org>; Mon, 8 Feb 2010 09:00:05 -0800 (PST)
Received: by pzk3 with SMTP id 3so129438pzk.5 for <http-state@ietf.org>; Mon, 08 Feb 2010 09:01:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.3.33 with SMTP id 33mr966284wfc.275.1265648465317; Mon, 08 Feb 2010 09:01:05 -0800 (PST)
In-Reply-To: <007901caa8de$a283e780$e78bb680$@com>
References: <7789133a1001191410l48530adar28098a03e6de0fb1@mail.gmail.com> <op.u7mkruzjvqd7e2@killashandra.oslo.osa> <alpine.DEB.2.00.1002050932580.3094@tvnag.unkk.fr> <op.u7nnk8uyvqd7e2@killashandra.oslo.osa> <op.u7tgx5y4vqd7e2@killashandra.oslo.osa> <007901caa8de$a283e780$e78bb680$@com>
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 8 Feb 2010 09:00:43 -0800
Message-ID: <7789133a1002080900s32f8c9b2rfcd3a17ca5f35cde@mail.gmail.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Daniel Stenberg <daniel@haxx.se>, 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: Mon, 08 Feb 2010 17:00:09 -0000

On Mon, Feb 8, 2010 at 8:49 AM, Paul E. Jones <paulej@packetizer.com> wrote:
>> My suggestion would be that the spec should recommend ordering an
>> ordering
>> based on on both domain and path (order of preference to be decided),
>> as
>> that will be more predictable for sites using multiple cookies with the
>> same name at various domain and path levels.
>
> Should we rely on the client to do this?  Your proposal is good, but I'm
> skeptical that I can rely on this as a developer on the server side.

I would recommend against relying on this behavior.  We can explicitly
admonish servers not to rely on this behavior.

> Personally, I'd prefer that the client never send two cookies with the same
> name.  There are two or more cookies in the browser with the same name, I
> would think the browser should only send the cookie with the most precise
> path match.  So, if there is a cookie at / and a cookie at /foo, and the
> user is accessing /foo, only the cookie for that path would be provided.  Is
> there a good reason to send multiple cookies with the same name?

We have to send multiple cookies with the same name because that's
what user agents do today.  We're not permitted to alter the syntax of
the protocol in Phase 1.  In Phase 2, these sorts of changes will be
on the table.

Adam