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