Re: [http-state] Ticket 11: Character encoding for non-ASCII cookies values

Mark Pauley <mpauley@apple.com> Wed, 03 March 2010 17:28 UTC

Return-Path: <mpauley@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 C3EC928C0D8 for <http-state@core3.amsl.com>; Wed, 3 Mar 2010 09:28:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 Jo7gs0lmOxqw for <http-state@core3.amsl.com>; Wed, 3 Mar 2010 09:28:04 -0800 (PST)
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 82E7F28C118 for <http-state@ietf.org>; Wed, 3 Mar 2010 09:28:04 -0800 (PST)
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 2942C878DE66; Wed, 3 Mar 2010 09:28:06 -0800 (PST)
X-AuditID: 11807137-b7bd4ae000000f0d-d7-4b8e9c18b7fc
Received: from [17.151.81.115] (Unknown_Domain [17.151.81.115]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 46.7D.03853.12C9E8B4; Wed, 3 Mar 2010 09:28:06 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Mark Pauley <mpauley@apple.com>
In-Reply-To: <5c4444771003021624qc0b00cet27e348cb6d023b08@mail.gmail.com>
Date: Wed, 3 Mar 2010 09:27:49 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <CB794A2E-2F2F-4CE4-8B15-BBE1A1E1B50F@apple.com>
References: <5c4444771003021624qc0b00cet27e348cb6d023b08@mail.gmail.com>
To: Adam Barth <ietf@adambarth.com>
X-Mailer: Apple Mail (2.1078)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] Ticket 11: Character encoding for non-ASCII cookies values
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 Mar 2010 17:28:05 -0000

Yes, CFNetwork (the component responsible for cookie handling in Safari) currently drops any cookies created with non-ascii values.

In the future, we ought to treat these as opaque octets.  However, the current cookie spec would lead me to believe that we should reject any cookies that contain control characters, which would be most non-ascii UTF-8 sequences, right?


On Mar 2, 2010, at 4:24 PM, Adam Barth wrote:

> We had some earlier discussion about what to do with non-ASCII
> characters in cookie values.
> 
> == On the wire ==
> 
> * IE, Firefox, Chrome, and Opera seem to treat non-ASCII characters as
> opaque octets on the wire
> * Safari seems to drop cookies with non-ASCII characters (although
> Maciej said code inspection leads him to believe Safari's behavior is
> a bit more complicated).
> 
> == In document.cookie ==
> 
> In <http://github.com/abarth/http-state/blob/master/notes/2010-02-03-Julian-Reschke.txt>,
> Julian Reschke wrote:
> [[
> 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)
> ]]
> 
> == Proposal ==
> 
> The draft treats the cookie values as opaque octets throughout for use
> on the wire.  I've added a SHOULD-level requirement to use a UTF8 when
> converting the octets to characters (e.g., for use in the user agent's
> user interface).
> 
> Given that the encoding issue doesn't appear to affect
> interoperability on the wire, I think a SHOULD-level recommendation is
> appropriate here.  If specific APIs (e.g., document.cookie) have more
> specific needs, they can add additional requirements.
> 
> Thoughts?
> 
> Adam
> _______________________________________________
> http-state mailing list
> http-state@ietf.org
> https://www.ietf.org/mailman/listinfo/http-state