Re: [http-state] non-ASCII cookie values (was Re: Closing Ticket 3: Public Suffixes)
Adam Barth <ietf@adambarth.com> Tue, 09 February 2010 16:47 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 BAD8328C237 for <http-state@core3.amsl.com>; Tue, 9 Feb 2010 08:47:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.842
X-Spam-Level:
X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, 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 XirvgoKe2BOe for <http-state@core3.amsl.com>; Tue, 9 Feb 2010 08:47:13 -0800 (PST)
Received: from mail-px0-f197.google.com (mail-px0-f197.google.com [209.85.216.197]) by core3.amsl.com (Postfix) with ESMTP id D83B228C21B for <http-state@ietf.org>; Tue, 9 Feb 2010 08:47:13 -0800 (PST)
Received: by pxi35 with SMTP id 35so78585pxi.18 for <http-state@ietf.org>; Tue, 09 Feb 2010 08:48:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.3.33 with SMTP id 33mr2041521wfc.275.1265734098235; Tue, 09 Feb 2010 08:48:18 -0800 (PST)
In-Reply-To: <4B6938F1.100@gmx.de>
References: <7789133a1002011014x5d587436j663a73bc92270a65@mail.gmail.com> <4B6926FC.5030107@gmx.de> <67660F71-01A3-4B66-B546-B740A1314E49@apple.com> <7789133a1002022348h57a61611me73b95e110c72ea3@mail.gmail.com> <4B692D7C.900@gmx.de> <7789133a1002030006r1d9b1bech491fa7826587eaff@mail.gmail.com> <7789133a1002030008n4f4e294fn548c359133d7734b@mail.gmail.com> <4B692F9F.7040602@gmx.de> <7789133a1002030034w5400ddb8k61bf9d7be880c2c0@mail.gmail.com> <4B6938F1.100@gmx.de>
From: Adam Barth <ietf@adambarth.com>
Date: Tue, 09 Feb 2010 08:47:58 -0800
Message-ID: <7789133a1002090847v529db1b2qa7cd99bae2f8bb01@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: http-state@ietf.org
Subject: Re: [http-state] non-ASCII cookie values (was Re: Closing Ticket 3: Public Suffixes)
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: Tue, 09 Feb 2010 16:47:14 -0000
On Wed, Feb 3, 2010 at 12:50 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > Adam Barth wrote: >> In general, I'm very reluctant to specify a behavior that conflicts >> with IE, Firefox, Chrome, and Opera. In specific, IE has something >> like 99% market share in some Asian markets. The fact that this issue >> affects Asian markets disproportionately means the pressure to be >> IE-like is even greater than usual. >> ... > > On the other hand, why require something that's known not be in use (if that > is the case)? As Maciej points out, this is not the standard of evidence that user agent implementors usually use when making compatibility decisions. I understand that this is a bit of a cultural divide in this group, but I'll try to give you a flavor of why UA folks think this way. A number of months ago, I helped change the way JavaScript prototypes were configured in WebKit. Instead of using the lexical or dynamic scope (which is what WebKit was using a mix of at the time), we changed them to some other esoteric rule that matched Firefox and IE. At the time, we had zero evidence that this change had any compatibility because the cases where these things are different are extremely obscure. So, why did we change it? Well, because there's no value in being different from other browsers and some (potential) value in being the same. That means the benefit (potentially non-zero) outweighs the cost (essentially zero). Now, as far as I know, the project still has zero evidence that this change actually improved compatibility in the real world. However, I happen to know by some random coincidence that this change was hugely beneficial. It just so happens that when folks use both Selenium (a popular web application testing harness) and Prototype.js (a popular JavaScript library), they arrive in precisely the situation where these computations give different answers. Without the change, developers have a lot of trouble testing a Prototype.js-using web site with Selenium, but, with the change, it works fine. So what are the consequences of the change? Well, it means developers are much more likely to test their web sites in Safari because they can just re-use their existing Selenium tests instead of having to build or find another testing harness. That means they're more likely to fix bugs that affect Safari, which means their web sites will work better in Safari. That, in turns, means users of Safari will have better experiences at web sites and the marketshare of Safari will grow. If the WebKit project had required actual examples of the change being beneficial, they probably would not have made that change and would not have enjoyed the benefits. Now, not every change pays off as well as the one I describe, and, in many cases, we never find out how well they pay off. The point is more that user agent implementing are being rational when they make these sorts of decisions. > If you allow non-ASCII characters (or actually require support), you'll also > have to figure out how existing server and client based APIs are to deal > with them (so what encoding is it?). For our purposes, it doesn't really matter how existing servers handle the encodings. In the end, they do what they do. As long as we send the "right" bytes on the wire, they'll do the "right" thing, whatever that is. As for client APIs, yes, we'll need to get that right, either in this specification or in the specification of those APIs (as we've discussed elsewhere in this thread). Adam
- [http-state] non-ASCII cookie values (was Re: Clo… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Julian Reschke
- Re: [http-state] non-ASCII cookie values (was Re:… Maciej Stachowiak
- Re: [http-state] non-ASCII cookie values (was Re:… David Morris
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Maciej Stachowiak
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Maciej Stachowiak
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Maciej Stachowiak
- Re: [http-state] non-ASCII cookie values (was Re:… Dan Winship
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Ian Hickson
- Re: [http-state] non-ASCII cookie values (was Re:… Julian Reschke
- Re: [http-state] non-ASCII cookie values (was Re:… Maciej Stachowiak
- Re: [http-state] non-ASCII cookie values (was Re:… Daniel Stenberg
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Julian Reschke
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Julian Reschke
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Maciej Stachowiak
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Julian Reschke
- Re: [http-state] non-ASCII cookie values (was Re:… Maciej Stachowiak
- Re: [http-state] non-ASCII cookie values (was Re:… Maciej Stachowiak
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth
- Re: [http-state] non-ASCII cookie values (was Re:… Julian Reschke
- Re: [http-state] non-ASCII cookie values (was Re:… Anne van Kesteren
- Re: [http-state] non-ASCII cookie values (was Re:… Adam Barth