Re: [http-state] Updated draft
Adam Barth <ietf@adambarth.com> Sun, 16 August 2009 18:32 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 57F8C3A6CDD for <http-state@core3.amsl.com>; Sun, 16 Aug 2009 11:32:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.924
X-Spam-Level:
X-Spam-Status: No, score=-0.924 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_20=-0.74, 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 MC8olfnvZmcV for <http-state@core3.amsl.com>; Sun, 16 Aug 2009 11:32:07 -0700 (PDT)
Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id 7114F3A6C9A for <http-state@ietf.org>; Sun, 16 Aug 2009 11:32:07 -0700 (PDT)
Received: by vws34 with SMTP id 34so2267382vws.31 for <http-state@ietf.org>; Sun, 16 Aug 2009 11:32:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.120.20 with SMTP id b20mr3669917vcr.40.1250447530086; Sun, 16 Aug 2009 11:32:10 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.00.0908161952060.13789@yvahk2.pbagnpgbe.fr>
References: <7789133a0908151008p35ff30e6w2761368fe70d41a6@mail.gmail.com> <alpine.DEB.2.00.0908152250410.18461@yvahk2.pbagnpgbe.fr> <7789133a0908151642w47c1dbf1x48268e657b0d71cc@mail.gmail.com> <alpine.DEB.2.00.0908161440520.25988@yvahk2.pbagnpgbe.fr> <7789133a0908161032l2265ce5fg966c434f1b05aa64@mail.gmail.com> <alpine.DEB.2.00.0908161952060.13789@yvahk2.pbagnpgbe.fr>
From: Adam Barth <ietf@adambarth.com>
Date: Sun, 16 Aug 2009 11:31:50 -0700
Message-ID: <7789133a0908161131s5741d457q812b5e4213452054@mail.gmail.com>
To: Daniel Stenberg <daniel@haxx.se>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] Updated draft
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, 16 Aug 2009 18:32:08 -0000
On Sun, Aug 16, 2009 at 11:10 AM, Daniel Stenberg<daniel@haxx.se> wrote: > I beg to differ. Which sorting requirement do you find problematic? Let's consider the path-length sorting first. > First, this sorting was not in the Netscape cookie spec but is only found in > RFC2109 and RFC2965. I don't think that should be a factor in our decisions. Our first consideration should be the behavior of existing implementations (both client and server). > Then, since clearly user agents that don't do any sorting of the cookies can > play fine against the vast majority of all sites User agents comprising >99% of the market share implement path-length sorting. The only implementation I'm aware of that does not perform path-length sorting is CURL. Are there other implementations we should factor into our decisions? I suspect that Internet Explorer, Firefox, Safari, Chrome, and Opera have collectively been tested on more web sites than CURL. When 5 out of 5 major browsers agree, there's likely a reason. > this seems like a > client-side invention that have no particular meaning to existing servers. > So by specifying the sort order you not only make a lot of client code > "non-compliant" all of a sudden, I don't think it matters how much code we make non-compliant. We should weigh the importance of implementations by market share. In this case, we have >99% of the market share in favor of path-length sorting. > I think you're also over-specifying > something that doesn't need to be specified. Here's the test I think we should use when deciding whether to add a user agent conformance requirement: "If I were going to implement a new user agent today and I wanted to maximize compatibility, would I implement this requirement?" In this case, it's clear that I would want to implement a behavior that matches all of the major browsers. > As far as I can understand, it could only really have a meaning if more than > 50 (or so) cookies are stored for a domain as then the sort order would > decide which cookies to discard (or rather not include in the Cookie: > header). But that won't have to imply that the 50 cookies that ARE sent have > to be sent in this sorted order. This is not the case. The priority order for evicting cookies is different from the order in which cookies appear in the Cookie header (which is what we're discussing). You can see that the tests cases we're using to probe this behavior involve only two cookies each: 0015 0016 path0001 path0002 path0003 path0004 Adam
- [http-state] Updated draft Adam Barth
- Re: [http-state] Updated draft Daniel Stenberg
- Re: [http-state] Updated draft Adam Barth
- Re: [http-state] Updated draft Daniel Stenberg
- Re: [http-state] Updated draft Adam Barth
- Re: [http-state] Updated draft Daniel Stenberg
- Re: [http-state] Updated draft Adam Barth
- Re: [http-state] Updated draft Daniel Stenberg
- Re: [http-state] Updated draft Dan Winship
- Re: [http-state] Updated draft Daniel Stenberg
- Re: [http-state] Updated draft Adam Barth
- Re: [http-state] Updated draft Adam Barth
- Re: [http-state] Updated draft Bil Corry
- Re: [http-state] Updated draft Daniel Stenberg
- Re: [http-state] Updated draft Julian Reschke
- Re: [http-state] Updated draft Daniel Stenberg
- Re: [http-state] Updated draft Bil Corry
- Re: [http-state] Updated draft Daniel Stenberg
- Re: [http-state] Updated draft Adam Barth
- Re: [http-state] Updated draft Adam Barth
- Re: [http-state] Updated draft Daniel Stenberg
- Re: [http-state] Updated draft Julian Reschke
- Re: [http-state] Updated draft Anne van Kesteren
- Re: [http-state] Updated draft Julian Reschke
- Re: [http-state] Updated draft Adam Barth
- Re: [http-state] Updated draft Daniel Stenberg
- Re: [http-state] Updated draft Dan Winship
- Re: [http-state] Updated draft Anne van Kesteren
- Re: [http-state] Updated draft Daniel Stenberg