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

Achim Hoffmann <ah@securenet.de> Sun, 28 February 2010 13:10 UTC

Return-Path: <ah@securenet.de>
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 6C6D93A774E for <http-state@core3.amsl.com>; Sun, 28 Feb 2010 05:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.327
X-Spam-Level:
X-Spam-Status: No, score=0.327 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_40=-0.185, HELO_EQ_DE=0.35]
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 qkjLeVfr0bor for <http-state@core3.amsl.com>; Sun, 28 Feb 2010 05:10:48 -0800 (PST)
Received: from munich.securenet.de (munich.securenet.de [82.135.17.200]) by core3.amsl.com (Postfix) with ESMTP id 4BF133A8A7E for <http-state@ietf.org>; Sun, 28 Feb 2010 05:10:08 -0800 (PST)
Received: from oxee.securenet.de (unknown [10.30.18.40]) by munich.securenet.de (Postfix) with ESMTP id C15BE27192 for <http-state@ietf.org>; Sun, 28 Feb 2010 14:10:07 +0100 (CET)
Received: by oxee.securenet.de (Postfix, from userid 65534) id A7556140202A; Sun, 28 Feb 2010 14:10:07 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by oxee.securenet.de (Postfix) with ESMTP id 31C9E140242E; Sun, 28 Feb 2010 14:10:06 +0100 (CET)
Received: from oxee.securenet.de ([127.0.0.1]) by localhost (oxee.securenet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29580-02; Sun, 28 Feb 2010 14:10:06 +0100 (CET)
Received: from [172.16.18.33] (ah.vpn.securenet.de [172.16.18.33]) by oxee.securenet.de (Postfix) with ESMTP id 543181402427; Sun, 28 Feb 2010 14:10:05 +0100 (CET)
Message-ID: <4B8A6B2C.1060904@securenet.de>
Date: Sun, 28 Feb 2010 14:10:04 +0100
From: Achim Hoffmann <ah@securenet.de>
Organization: SecureNet
User-Agent: who">cares?
MIME-Version: 1.0
To: http-state <http-state@ietf.org>
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> <7789133a1002080900s32f8c9b2rfcd3a17ca5f35cde@mail.gmail.com> <alpine.DEB.2.00.1002091010430.16401@tvnag.unkk.fr>
In-Reply-To: <alpine.DEB.2.00.1002091010430.16401@tvnag.unkk.fr>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Open-Xchange Express amavisd-new at oxee.securenet.de
Cc: Daniel Stenberg <daniel@haxx.se>
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: Sun, 28 Feb 2010 13:10:49 -0000

Daniel Stenberg wrote on 09.02.2010 10:16:
> On Mon, 8 Feb 2010, Adam Barth wrote:
> 
>> 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.
> 
> As this topic twists on, we all see that no server can rely on any
> specific order on cookies that are sent by clients, so thus we can in
> fact discourage the use of multiple cookies with the same name as
> there's basically no way for a server to know in which order it'll get
> the cookies. We can _perhaps_ find a sort order we can say clients
> should use, but as seen here that wouldn't change how a large amount of
> existing clients behave.
> 
> Also, allow me to re-iterate that the 5 major browsers are not even
> close to 100% of the cookie using HTTP clients and we can find several
> other widely used implementations that will send the cookies in a
> different sort order than the big browsers.

Just to sumarize the facts:
  1) multiple cookies (key-value pairs) are allowed currently
  2) browsers make use of 1)
  3) there is no conformity in which order cookies are send by the browser
  4) it's even allowed to have more than one Cookie request header
     (I'm not aware of a browser which does it this way)

As 1) is used in the wild, it cannot be discouraged.
Up to now no browser vendor (except Opera:) gave a clear and undoubtful
description in which order cookies are send.
Even I don't have seen it in the wild, a proxy may change the order of
multiple Cookie headers.
All this renders the attempt to make a suggestion about the sequence of
cookies uncertain.

Hence I'll change my mind about cookie ordering, and suggest a probably
heretic definition:

  The order of multiple cookies, wether in one or multiple Cookie headers,
  is random and up to the client implementation.
  Servers/applications MUST NOT rely on any sequence.

Such a definition keeps the logical order and other such details out of
the cookie protocol specification. It also forces the server/application
to make precautionary measures how to identify the proper cookie.
This is then also in sync with 7. Security Considerations which makes the
application responsible for that.

Achim