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

Adam Barth <ietf@adambarth.com> Wed, 16 February 2011 01:46 UTC

Return-Path: <ietf@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 1D4F83A6B6F for <http-state@core3.amsl.com>; Tue, 15 Feb 2011 17:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 bwwzn9od7k8m for <http-state@core3.amsl.com>; Tue, 15 Feb 2011 17:46:08 -0800 (PST)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 09C973A684E for <http-state@ietf.org>; Tue, 15 Feb 2011 17:46:07 -0800 (PST)
Received: by qyk34 with SMTP id 34so2758854qyk.10 for <http-state@ietf.org>; Tue, 15 Feb 2011 17:46:34 -0800 (PST)
Received: by 10.224.19.138 with SMTP id a10mr63381qab.399.1297820794337; Tue, 15 Feb 2011 17:46:34 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id t7sm3143707qcs.16.2011.02.15.17.46.32 (version=SSLv3 cipher=OTHER); Tue, 15 Feb 2011 17:46:33 -0800 (PST)
Received: by iym1 with SMTP id 1so736084iym.31 for <http-state@ietf.org>; Tue, 15 Feb 2011 17:46:32 -0800 (PST)
Received: by 10.231.37.200 with SMTP id y8mr74904ibd.105.1297820792260; Tue, 15 Feb 2011 17:46:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.215.67 with HTTP; Tue, 15 Feb 2011 17:46:02 -0800 (PST)
In-Reply-To: <DA7A626A-9613-4A49-8A46-8096F7F465B4@gbiv.com>
References: <20110204184735.26023.qmail@mm01.prod.mesa1.secureserver.net> <AANLkTi=qBVkGwMHqAidtwP5_A8pPrF-Y9MV4jgYS5_QM@mail.gmail.com> <7384878F-C44A-42A4-9694-1BB1C18AA5E6@gbiv.com> <AANLkTinFq7bE_e3SSgdjuFvZ8hGn1xy4Hc1VKwc=vp1D@mail.gmail.com> <49225418-A1AF-4299-8C4F-2E608D34265D@gbiv.com> <AANLkTimrJF3LFR4t4j=U2L33kFh+wf-R=sjjwexcmyPi@mail.gmail.com> <26240DE2-4DD3-4863-81B1-635D34BA4AE4@gbiv.com> <AANLkTikzB=VORtn7xiG2JY8ymTjk4epC9huZTC-s0nzq@mail.gmail.com> <4D5AEE94.6010303@gmx.de> <AANLkTimkmZ99qDcXB6=-PGtXq6WQ7+RSreRwsBAHryEj@mail.gmail.com> <DA7A626A-9613-4A49-8A46-8096F7F465B4@gbiv.com>
From: Adam Barth <ietf@adambarth.com>
Date: Tue, 15 Feb 2011 17:46:02 -0800
Message-ID: <AANLkTi=aX26NgDx3J0zk6a6H-Fg-9hyuBhfwvVW5nBiH@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] Is this an omission in the parser rules of draft-ietf-httpstate-cookie-21?
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, 16 Feb 2011 01:46:09 -0000

On Tue, Feb 15, 2011 at 3:55 PM, Roy T. Fielding <fielding@gbiv.com>; wrote:
> On Feb 15, 2011, at 2:05 PM, Adam Barth wrote:
>> On Tue, Feb 15, 2011 at 1:22 PM, Julian Reschke <julian.reschke@gmx.de>; 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
> practice.

I feel like I'm just repeating myself.  The text you're complaining
about does not define how to parse a Set-Cookie header.

>>> 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.

That's essentially what the current document says.  The only
difference is that it also recommends that servers not generate
characters such as %x24, whose role in cookies has been muddied by RFC
2965.

Adam