Re: [http-state] Updated draft

Dan Winship <dan.winship@gmail.com> Sun, 16 August 2009 23:19 UTC

Return-Path: <dan.winship@gmail.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 6F0613A6892 for <http-state@core3.amsl.com>; Sun, 16 Aug 2009 16:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.984
X-Spam-Level:
X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=-2.133, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334]
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 lEvRNE97WtjX for <http-state@core3.amsl.com>; Sun, 16 Aug 2009 16:19:49 -0700 (PDT)
Received: from mysterion.org (mysterion.org [69.25.196.35]) by core3.amsl.com (Postfix) with ESMTP id 8DD093A6842 for <http-state@ietf.org>; Sun, 16 Aug 2009 16:19:49 -0700 (PDT)
Received: from desktop.home.mysterion.org (c-76-97-71-164.hsd1.ga.comcast.net [76.97.71.164]) by mysterion.org (Postfix) with ESMTPA id 00386802AE; Sun, 16 Aug 2009 19:19:53 -0400 (EDT)
Message-ID: <4A889417.9020709@gmail.com>
Date: Sun, 16 Aug 2009 19:19:51 -0400
From: Dan Winship <dan.winship@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3
MIME-Version: 1.0
To: Daniel Stenberg <daniel@haxx.se>
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> <7789133a0908161131s5741d457q812b5e4213452054@mail.gmail.com> <alpine.DEB.2.00.0908162035140.13789@yvahk2.pbagnpgbe.fr>
In-Reply-To: <alpine.DEB.2.00.0908162035140.13789@yvahk2.pbagnpgbe.fr>
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 23:19:50 -0000

On 08/16/2009 04:42 PM, Daniel Stenberg wrote:
> As curl is not a browser at all you could test 100% of the browsers and
> curl would still not be in that lump. You cannot use browser share among
> end users as a proper measurement here. If you can reach 99% of the
> server implementations it would matter a lot more.

We cannot reach 99% of server implementations though; many of them are
behind firewalls, or only exhibit the behaviors of interest when you
have an account on them, etc, etc.

What we *can* do is leverage the fact that (a) the implementors of those
servers probably tested their site against IE, and maybe against Firefox
too, and (b) eventually the users of the browsers that they *didn't*
test against will file bugs against those browsers, complaining that
site X doesn't work correctly, and the browser vendor may eventually be
able to figure out why and do something about it, and so we should
expect that more-popular browsers will be more interoperable, since
they'll have received more bug reports about lame sites.

> Then please tell me the reason. Why do they sort the cookies like this?
> (And I don't count "because RFC2109/2965 says so" to be a good
> explanation.)

They sort the cookies like that because IE6 sorted the cookies like
that. And IE6 didn't have any reason at all; the cookies had to come out
in some order, and this happens to be the order they came out in.

> And the reversed: how come (virtually) no server-side receivers care
> about the order?

Because most web developers aren't complete morons. Unfortunately, some
of them *are* complete morons, and write code that blindly assumes that
username will always be $cookies[0] and shopping_cart_contents will
always be $cookies[1], etc. If you read through the Firefox cookie
source, there are comments in the cookie-ordering code with links to
some old bugs pointing out some specific web sites, but the bugs in
question are several years old and the specific web sites they mention
might no longer demonstrate the bugs. OTOH, since Firefox now sorts the
same way IE does, that means that even if the moron web developer tests
his site against both IE and Firefox, it works in both now, and so he
doesn't realize he's a moron.

> I think you're looking at it from the wrong perspective. If I were to
> implement a new cookie "engine" today and maximize compatibility, I
> would make sure that it plays with 99.[something] of the
> _server_-implementions. And funnily enough, I claim that curl does!

curl *does* work with 99.[something]% of web sites. But
(100 - 99.[something]) * number_of_web_sites_in_the_world is still a big
number.

-- Dan