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

Adam Barth <ietf@adambarth.com> Sat, 05 February 2011 00:25 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 7A88A3A69DC for <http-state@core3.amsl.com>; Fri, 4 Feb 2011 16:25:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.202
X-Spam-Level:
X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 vfWxCIxfXq6K for <http-state@core3.amsl.com>; Fri, 4 Feb 2011 16:25:10 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id CD98C3A67D1 for <http-state@ietf.org>; Fri, 4 Feb 2011 16:25:09 -0800 (PST)
Received: by vxi40 with SMTP id 40so980093vxi.31 for <http-state@ietf.org>; Fri, 04 Feb 2011 16:28:35 -0800 (PST)
Received: by 10.220.190.201 with SMTP id dj9mr3183838vcb.278.1296865715312; Fri, 04 Feb 2011 16:28:35 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by mx.google.com with ESMTPS id r7sm986086vbx.19.2011.02.04.16.28.22 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 16:28:22 -0800 (PST)
Received: by vws7 with SMTP id 7so1981036vws.31 for <http-state@ietf.org>; Fri, 04 Feb 2011 16:28:21 -0800 (PST)
Received: by 10.220.200.70 with SMTP id ev6mr3357800vcb.248.1296865701287; Fri, 04 Feb 2011 16:28:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.165.212 with HTTP; Fri, 4 Feb 2011 16:27:51 -0800 (PST)
In-Reply-To: <20110205002400.1838.qmail@mm02.prod.mesa1.secureserver.net>
References: <20110205002400.1838.qmail@mm02.prod.mesa1.secureserver.net>
From: Adam Barth <ietf@adambarth.com>
Date: Fri, 04 Feb 2011 16:27:51 -0800
Message-ID: <AANLkTik+pvoC5+ZmPyfLFbxxy71n6d4-haf4AjqmAY6G@mail.gmail.com>
To: Remy Lebeau <remy@lebeausoftware.org>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: 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: Sat, 05 Feb 2011 00:25:11 -0000

On Fri, Feb 4, 2011 at 4:24 PM, Remy Lebeau <remy@lebeausoftware.org> wrote:
> -------- Original Message --------
> Subject: Re: [http-state] Is this an omission in the parser rules of
> draft-ietf-httpstate-cookie-21?
> From: Adam Barth
> Date: Fri, February 04, 2011 11:29 am
> To: "Roy T. Fielding"
> Cc: Remy Lebeau , http-state@ietf.org
>
>> The grammar is not used for parsing. Parsing
>> is defined in Section 5, not Section 4.
>
> Section 5 describes how to parse Set-Cookie headers. RFC 2109 grammer
> (and real-world use, which you seem to deny exists) for Set-Cookie
> headers specifically defines both cookie values and attribute values as
> being a "value" type, which is defined as follows:
>
> value = word
> word = token | quoted-string
>
> Why can't Section 5 be updated to allow parsing of quoted-string values?
> They ARE in use in the real world! They ARE NOT opaque in attribute
> values. They are grammar elements that some servers really do use, and
> should be parsed as such. I think Section 5 needs to adopt RFC 2109's
> definition of the "value" and/or "word" type, instead of using "token"
> exclusively.

Remy, please calm down.  Section 5 does not use token at all, much
less exclusively.  Can you provide an example of a Set-Cookie header
that you believe is processed incorrectly by Section 5?

Adam