Re: [http-state] Is this an omission in the parser rules of draft-ietf-httpstate-cookie-21?

"Roy T. Fielding" <> Tue, 15 February 2011 23:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B40B3A6C9E for <>; Tue, 15 Feb 2011 15:55:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ifoQL4YoSW2K for <>; Tue, 15 Feb 2011 15:55:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1C2D83A6C37 for <>; Tue, 15 Feb 2011 15:55:27 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id AF2472C806E; Tue, 15 Feb 2011 15:55:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns;; b=G9IXzjH9gB9tnVkn nZ+JZ0rV8vAeuTX8oiKDe7/CEKlsLKlL5cFJ/Pa4Z/tQRM16ETln8dVHeMsHZrsj PyxubQqlgwN3F03/WUs+6246xm3zcSjVXtSbsGvCx2pA1rV0Yz77BP4pbt7rxA73 6B2bNdLhGfjQmz26xJ5WAa4G39g=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=BNzJwRkYnQSXuL5p6fr0B+xXERs=; b=R6Hg6/p+l8xhLcrEimHg9ddf3m4f DV5h1qIijueMezFUbERbYHOno6ItJBsJlqGj6wBItsuEKpuPxUhA5MbkGxWoyFC0 qxkg9WRdjPRv7ECPRg+1Gx4T7TAspD6ukojeODTYofoqbCl66S8ZBFs9cMOarX7U zt6qIMdRJ9Dxn0w=
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 834212C8058; Tue, 15 Feb 2011 15:55:53 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Tue, 15 Feb 2011 15:55:54 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Adam Barth <>
X-Mailer: Apple Mail (2.1082)
Cc: http-state <>
Subject: Re: [http-state] Is this an omission in the parser rules of draft-ietf-httpstate-cookie-21?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Feb 2011 23:55:28 -0000

On Feb 15, 2011, at 2:05 PM, Adam Barth wrote:
> On Tue, Feb 15, 2011 at 1:22 PM, Julian Reschke <> wrote:
>> On 15.02.2011 22:11, Adam Barth wrote:
>>> ...
>>> You really think we should recommend that servers use invalid UTF-8
>>> sequences as cookie-values?  That sounds like bad advice...
>>> ...

I am not recommending that they use invalid UTF-8 sequences.
The ABNF only tells the implementer what octets can be used
and what needs to be anticipated while parsing.  If I were
designing a new Cookie protocol, I would exclude the high bits,
but this is how the current Cookie protocol actually works in

>> Could you elaborate? Is there client code out there that assumes cookie
>> values to *be* UTF-8?
> Regardless of what client code exist, surely servers are better off
> avoiding non-ASCII characters in their cookie values.  Using non-ASCII
> characters in HTTP headers is just asking for trouble.

It is irrelevant.  HTTP/1.x defined them as ISO-8859-1 and nothing
breaks by treating them as such.  This spec (and the Netscape spec)
defines them as an opaque array of data bytes and nothing breaks
by treating them as such.

I don't know of any implementation that would expect them to be
UTF-8.  I do know that attempting to use a UTF-8 string parser to
parse an HTTP data stream is a known security hole, so there is
no point in worrying about breaking those parsers any further
than they would already be broken (if any still exist -- J2SE
fixed their holes last year).

I don't have any objection to a sentence that says servers
SHOULD NOT send %x80-FF even though the grammar allows it.
But I don't see any need for it either given the apparent
interoperability shown by user agents.