Re: [http-state] Ticket 5: Cookie ordering
Daniel Stenberg <daniel@haxx.se> Wed, 20 January 2010 08:14 UTC
Return-Path: <daniel@haxx.se>
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 18EA23A68C7 for <http-state@core3.amsl.com>;
Wed, 20 Jan 2010 00:14:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300,
BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6]
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 yOYF+b--x4po for
<http-state@core3.amsl.com>; Wed, 20 Jan 2010 00:14:04 -0800 (PST)
Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by core3.amsl.com
(Postfix) with ESMTP id 773813A68A9 for <http-state@ietf.org>;
Wed, 20 Jan 2010 00:14:04 -0800 (PST)
Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by giant.haxx.se
(8.14.3/8.14.3/Debian-9) with ESMTP id o0K8Duff019026;
Wed, 20 Jan 2010 09:13:56 +0100
Date: Wed, 20 Jan 2010 09:13:56 +0100 (CET)
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: Adam Barth <ietf@adambarth.com>
In-Reply-To: <7789133a1001191729g4e0a4827w43a12879d23e289c@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1001200832220.11282@tvnag.unkk.fr>
References: <7789133a1001191410l48530adar28098a03e6de0fb1@mail.gmail.com>
<alpine.DEB.2.00.1001192327190.27499@tvnag.unkk.fr>
<7789133a1001191729g4e0a4827w43a12879d23e289c@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed
Content-ID: <alpine.DEB.2.00.1001200832541.11282@tvnag.unkk.fr>
Cc: 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: Wed, 20 Jan 2010 08:14:06 -0000
On Tue, 19 Jan 2010, Adam Barth wrote: > Let me try rephrasing your proposal to make sure I understand it properly: > > (4) Require that among cookies with the same name, user agents ought > to present cookies with longer path attributes before cookies with > shorter path attributes. The spec should not require or recommend > other ordering constraints. > > Can you explain why (4) provides a better cost / benefit trade-off > than (1) or (3)? In particular, what is the advantage of us adopting > (4) over (1) or (3)? I like specifying only what needs to be specified and leave the rest to the implementor. In every spec I read or work with. The (3) "sort-them-all" approach is indeed the easier way to implement this, as figuring out exactly which cookies that have the same name and only special-case the order of those will probably be a bigger effort than to simply unconditionally sort all cookies based on path length. Since the only cookies that NEED an order are those that have the same name, I think we should only specify that. > Do you have data about the relative compatibility of (1), (3), and (4)? If > not, are you willing to generate this data? It seems like there is some > interoperability / compatibility risk to (4) that would be mitigated in (3) > and (1). Without a way to quantify this risk, we are flying blind. I've not seen anyone present any numbers regarding cookie sort order so I don't quite see why I would be different here. No, I don't have any numbers and I don't think I'm able to come up with any numbers either. My assumptions and views of reality here comes from the fact that I've written a cookie implementation that has been used rather widely by applications, frameworks and browsers for quite a number of years by now. Like most other people here base their views on work with other implementations and/or users. I assume we're all similar in that aspect. >> I don't think it needs to say that _all_ cookies need to be sorted on path >> length, as that's not what servers need. > > Why introduce interoperability problems where none exist? The interoperability here is against servers. Can you show me two servers in active use today that a client doesn't work with if the cookie order is as "free" as I suggest? > If the most widely used user agents are already doing something sensible Web user agents, browsers, sure. There is also a wide range of non-gui clients that use HTTP and cookies that we don't know how much they're used and as I showed before, lots of them have no sorting whatsoever and lots of them work fine against the vast majority of the cookie-using sites out there. I don't think browser usage share is the only and final measurement here. (I should add that curl will sort cookies based on path length starting soon, as I've been convinced that there will be a few rare sites that cannot work properly without it.) Some of those non-web tools that deal with cookies know how to import cookies from the traditional cookies file in the netscape file format, and that format has no "creation time" field and thus importing cookies from such a file makes it impossible to send the cookies back sorted on the original "creation time" but instead it could only do it based on the time of the read from a file. > I'm sure there's a site somewhere that depends on the consensus ordering. In my view there is no consensus ordering. > A common case is that a server will send two Set-Cookie headers in the > same HTTP response: > > Set-Cookie: foo=bar > Set-Cookie: baz=qux > > With sort order (1), the user agent will respond > > Cookie: foo=bar; baz=qux > > or omit the cookie header entirely. I can easily imagine server-side code > that would break if presented with "Cookie: baz=qux; foo=bar". Really? I mean, sure I can imagine that there is also sites that require that the Cookie: header is the 5th header in the request but that doesn't make it a correct assumption even though it might work with a browser or two. Is it really an assumption that is widely enough used so that we need to document it as something clients should do? I'm only against specifying it in the spec if it's a very rare assumption that we can declare is a server bug. If the assumption is spread and used more than rarely then I am wrong and it should be specified. > The easiest way to work with all servers is to sort the cookies as proposed > in (1). The easiest way is to just document the exact behavior of one browser and one server implementation and we're done. That's however not our job here, I think. -- / daniel.haxx.se
- [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 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 Yngve Nysaeter Pettersen
- Re: [http-state] Ticket 5: Cookie ordering Adam Barth
- 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