Re: [http-state] non-ASCII cookie values (was Re: Closing Ticket 3: Public Suffixes)

"Anne van Kesteren" <annevk@opera.com> Wed, 03 February 2010 12:48 UTC

Return-Path: <annevk@opera.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 BE3763A683A for <http-state@core3.amsl.com>; Wed, 3 Feb 2010 04:48:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.932
X-Spam-Level:
X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 AafjKji-5Uzo for <http-state@core3.amsl.com>; Wed, 3 Feb 2010 04:48:36 -0800 (PST)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 66BBE3A6820 for <http-state@ietf.org>; Wed, 3 Feb 2010 04:48:36 -0800 (PST)
Received: from annevk-t60 (5355737B.cable.casema.nl [83.85.115.123]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id o13CjVnq024103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 12:45:31 GMT
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Julian Reschke" <julian.reschke@gmx.de>, "Adam Barth" <ietf@adambarth.com>
References: <7789133a1002011014x5d587436j663a73bc92270a65@mail.gmail.com> <143E98B7-BFA6-4F77-9685-E57FFD2449A6@apple.com> <7789133a1002021737v2a50be07u3eea61a2fe870c79@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> <4B696EEB.1050803@gmx.de>
Date: Wed, 03 Feb 2010 13:49:12 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Anne van Kesteren" <annevk@opera.com>
Organization: Opera Software ASA
Message-ID: <op.u7jxwalk64w2qv@annevk-t60>
In-Reply-To: <4B696EEB.1050803@gmx.de>
User-Agent: Opera Mail/10.10 (Linux)
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: Wed, 03 Feb 2010 12:48:37 -0000

On Wed, 03 Feb 2010 13:41:15 +0100, Julian Reschke <julian.reschke@gmx.de>  
wrote:
> Julian Reschke wrote:
>> ...
>> On the other hand, why require something that's known not be in use (if  
>> that is the case)?
>>  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?).
>> ...
>
> I just did a quick test with an ISO-8859-1 encoded cookie value,  
> client-side javascript and "alert(document.cookie)":
>
> - IE and Firefox appear to treat the cookie as ISO-8859-1
> - Safari appears to ignore the cookie
> - Chrome and Opera appear to try to decode as UTF-8 (and returns a  
> REPLACEMENT CHAR in place of the umlaut I tried)

Hmm, at least Chrome is consistent with how it does things for  
XMLHttpRequest...

Since not everyone on this list may know this, for XMLHttpRequest it is  
currently specified that trying to set headers/values with characters  
higher than U+00FF fails. Otherwise setting succeeds with the higher-order  
byte of each character removed. On reading a code point is created for  
each byte with the higher-order byte set to zero. It would make sense if  
these APIs behaved identical I think.


-- 
Anne van Kesteren
http://annevankesteren.nl/