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

Maciej Stachowiak <mjs@apple.com> Wed, 03 February 2010 00:26 UTC

Return-Path: <mjs@apple.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 C94723A680F for <http-state@core3.amsl.com>; Tue, 2 Feb 2010 16:26:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.588
X-Spam-Level:
X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 1zCqW0P9msKr for <http-state@core3.amsl.com>; Tue, 2 Feb 2010 16:26:34 -0800 (PST)
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id EAB4B3A6A44 for <http-state@ietf.org>; Tue, 2 Feb 2010 16:26:34 -0800 (PST)
Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 24B7383369A9 for <http-state@ietf.org>; Tue, 2 Feb 2010 16:27:15 -0800 (PST)
X-AuditID: 11807130-b7b0aae00000102c-07-4b68c2e2e1b4
Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay11.apple.com (Apple SCV relay) with SMTP id FA.E5.04140.3E2C86B4; Tue, 2 Feb 2010 16:27:15 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=us-ascii
Received: from [10.0.1.5] (c-69-181-42-237.hsd1.ca.comcast.net [69.181.42.237]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KX8004WBP9ESV40@gertie.apple.com> for http-state@ietf.org; Tue, 02 Feb 2010 16:27:14 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <7789133a1002012254oafc43aehe32f16e2640cbcdc@mail.gmail.com>
Date: Tue, 02 Feb 2010 16:27:14 -0800
Message-id: <92003C09-05E0-4D51-B17B-05C26A41C209@apple.com>
References: <7789133a1002011014x5d587436j663a73bc92270a65@mail.gmail.com> <E1E6C8DE-EFB6-4226-93EE-AF20053FF315@apple.com> <Pine.LNX.4.64.1002012105180.6765@egate.xpasc.com> <7789133a1002012254oafc43aehe32f16e2640cbcdc@mail.gmail.com>
To: Adam Barth <ietf@adambarth.com>
X-Mailer: Apple Mail (2.1077)
X-Brightmail-Tracker: AAAAAQAAAZE=
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 00:26:35 -0000

On Feb 1, 2010, at 10:54 PM, Adam Barth wrote:

> 
> On Mon, Feb 1, 2010 at 9:07 PM, David Morris <dwm@xpasc.com> wrote:
>> On Mon, 1 Feb 2010, Maciej Stachowiak wrote:
>>> But there are two ways in which it matters:
>>> 
>>> 1) A header with non-ASCII bytes get set via Set-Cookie, then read through a JS API such as document.cookie. document.cookie gives a UTF-16 encoded string, so at this point the server has to decide how to interpret non-ASCII bytes in the cookie value.
>>> 
>>> 2) If you set a cookie via document.cookie and include non-ASCII characters in the value, what bytes get sent?
>> 
>> Seems to me that the platform providing the document.cookie object is
>> responsible for making any value placed in the cookie: header correct.
> 
> That seems like a wise course of action.  This document understands
> octet sequences.  HTML5 should define how to translate those octet
> sequences into JavaScript characters (when reading document.cookie)
> and how to perform the reverse translation (when writing
> document.cookie).

HTML5 does not spec this detail and apparently expects the cookie spec to expose a string interface, not an octet-sequence interface:
http://dev.w3.org/html5/spec/Overview.html#dom-document-cookie

I think defining conversion between octet sequence and string could plausibly go in either spec. I think the cookie spec would be a better place, because other string-oriented interfaces from web platform specs to cookies (if any) should probably use the same conversion, and browser UI for managing cookies should probably use the same conversion too. So it would be a useful thing to define even if it's not used by the network protocol. However, if you don't think it should be in the cookie spec, I can file a bug against HTML5.

Regards,
Maciej