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 09: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 8B6C53A6936 for <http-state@core3.amsl.com>; Sat, 5 Feb 2011 01:46:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.686
X-Spam-Level:
X-Spam-Status: No, score=-3.686 tagged_above=-999 required=5 tests=[AWL=-0.709, 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 GbnPL2XKqGsK for <http-state@core3.amsl.com>; Sat, 5 Feb 2011 01:46:24 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D0DFC3A6929 for <http-state@ietf.org>; Sat, 5 Feb 2011 01:46:23 -0800 (PST)
Received: by iwc10 with SMTP id 10so3260434iwc.31 for <http-state@ietf.org>; Sat, 05 Feb 2011 01:49:51 -0800 (PST)
Received: by 10.42.225.197 with SMTP id it5mr15393590icb.331.1296899390874; Sat, 05 Feb 2011 01:49:50 -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 i16sm1484348ibl.0.2011.02.05.01.49.49 (version=SSLv3 cipher=RC4-MD5); Sat, 05 Feb 2011 01:49:49 -0800 (PST)
Received: by iym1 with SMTP id 1so2662340iym.31 for <http-state@ietf.org>; Sat, 05 Feb 2011 01:49:48 -0800 (PST)
Received: by 10.42.221.194 with SMTP id id2mr1529723icb.448.1296899388633; Sat, 05 Feb 2011 01:49:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.35.13 with HTTP; Sat, 5 Feb 2011 01:49:18 -0800 (PST)
In-Reply-To: <20110205002149.f00013ceab8fb1928885c5c172fbfd4a.147756da58.wbe@email00.secureserver.net>
References: <20110205002149.f00013ceab8fb1928885c5c172fbfd4a.147756da58.wbe@email00.secureserver.net>
From: Adam Barth <ietf@adambarth.com>
Date: Sat, 5 Feb 2011 01:49:18 -0800
Message-ID: <AANLkTimp8G2JW0saishm4gvKiBtPrWUsuUgmS-AAXgo3@mail.gmail.com>
To: Remy Lebeau <remy@lebeausoftware.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 09:46:25 -0000

On Fri, Feb 4, 2011 at 11:21 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 <ietf@adambarth.com>;
> Date: Fri, February 04, 2011 4:27 pm
> To: Remy Lebeau <remy@lebeausoftware.org>;
> Cc: http-state@ietf.org
>
>> Section 5 does not use token at all, much less exclusively.
>
> It does, however, outline the rules for extracting the individual string
> values of the various components, and then how to process their contents
> once all the grammar has been stripped away.  The only parsing rule that
> explicitally allows for quoted-string values is Date handling, because a
> quotation mark is included in the list of defined leading/trailing
> delimiters.  No other rule allows for the presence of quotation marks.
>
>> Can you provide an example of a Set-Cookie header that
>> you believe is processed incorrectly by Section 5?
>
> The examples in RFCs 2109 and 2965, for starters.  Let's look at the
> first example:
>
>  Set-Cookie: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"
>
> Which is issued by a request to "http://<host>/acme/login".
>
> Here is a step-by-step breakdown of how the above cookie gets processed
> by Section 5.2 (I will use parenthesis around values so you can see
> where whitespace charcters exist).  I believe a failure occurs in the
> processing of the "Path" attribute by Section 5.2.4:

I haven't gone through your example in detail, but you're correct that
the " character at the beginning of the Path attribute causes the user
agent to never return the cookie.  You're welcome to test
implementations.  As I recall, the behavior in the spec matches how
browsers actually work.

See: https://github.com/abarth/http-state/blob/master/tests/data/parser/path0027-test

Kind regards,
Adam