Re: [http-state] parser rules of draft-ietf-httpstate-cookie-22

"Remy Lebeau" <remy@lebeausoftware.org> Thu, 24 February 2011 21:45 UTC

Return-Path: <SRS0=JfYxFF=VV=lebeausoftware.org=remy@srs.bis.na.blackberry.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 5F14A3A683F for <http-state@core3.amsl.com>; Thu, 24 Feb 2011 13:45:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.62
X-Spam-Level:
X-Spam-Status: No, score=-4.62 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
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 5J68RGHUSBXr for <http-state@core3.amsl.com>; Thu, 24 Feb 2011 13:45:37 -0800 (PST)
Received: from smtp02.bis.na.blackberry.com (smtp02.bis.na.blackberry.com [216.9.248.49]) by core3.amsl.com (Postfix) with ESMTP id 394E73A6807 for <http-state@ietf.org>; Thu, 24 Feb 2011 13:45:36 -0800 (PST)
Received: from bda933.bisx.prod.on.blackberry (bda933.bisx.prod.on.blackberry [172.20.220.96]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p1OLkLH1003269; Thu, 24 Feb 2011 21:46:21 GMT
Received: from bda933.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda933.bisx.prod.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p1OLkIkg009433; Thu, 24 Feb 2011 21:46:18 GMT
X-rim-org-msg-ref-id: 552831854
Message-ID: <552831854-1298583977-cardhu_decombobulator_blackberry.rim.net-407773613-@bda461.bisx.prod.on.blackberry>
Content-Transfer-Encoding: base64
X-Priority: Normal
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> <AANLkTi=aX26NgDx3J0zk6a6H-Fg-9hyuBhfwvVW5nBiH@mail.gmail.com> <AANLkTinnySHEXvaQSxoUAKNaPWThDWdJwnhvCdVfa5Vr@mail.gmail.com> <1E7DE6DF-864A-48AF-B9A3-698DEF4B3B2D@gbiv.com> <4D6590F4.6010505@stpeter.im> <94DA5CF6-88AB-43BD-99AE-921BCA98C7A3@gbiv.com><AANLkTikxOBCgiAwvg3z2DwyHtJXhTK1=6ipTo16csKr9@mail.gmail.com><4D66C718.3000300@stpeter.im><1CE31B7F-5D95-4CFE-B9A1-FBCC9461E472@gbiv.com>
In-Reply-To: <1CE31B7F-5D95-4CFE-B9A1-FBCC9461E472@gbiv.com>
Sensitivity: Normal
Importance: Normal
To: "Roy T. Fielding" <fielding@gbiv.com>, Peter Saint-Andre <stpeter@stpeter.im>
From: Remy Lebeau <remy@lebeausoftware.org>
Date: Thu, 24 Feb 2011 21:46:14 +0000
Content-Type: text/plain
MIME-Version: 1.0
Cc: iesg@iesg.org, http-state <http-state@ietf.org>
Subject: Re: [http-state] parser rules of draft-ietf-httpstate-cookie-22
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: remy@lebeausoftware.org
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: Thu, 24 Feb 2011 21:46:08 -0000

My original problem with DQUOTE handling, and is still a concern for me, is that the current draft does not allow the use of DQUOTE around attribute values at all, let alone around cookie values. DQUOTE around attribute values is common to see because it is part of RFC 2109, and it cannot be treated as opaque data like it can in cookie values. The grammer rules for parsing attributes must allow for recognizing and removing DQUOTE when extracting attribute values.

-----Original Message-----
From: "Roy T. Fielding" <fielding@gbiv.com>
Sender: http-state-bounces@ietf.org
Date: Thu, 24 Feb 2011 13:31:00 
To: Peter Saint-Andre<stpeter@stpeter.im>
Cc: http-state<http-state@ietf.org>; <iesg@iesg.org>
Subject: Re: [http-state] parser rules of draft-ietf-httpstate-cookie-22

On Feb 24, 2011, at 1:01 PM, Peter Saint-Andre wrote:

> On 2/23/11 10:16 PM, Adam Barth wrote:
>> On Wed, Feb 23, 2011 at 5:01 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>>> On Feb 23, 2011, at 2:57 PM, Peter Saint-Andre wrote:
>>>> On 2/23/11 3:07 PM, Roy T. Fielding wrote:
>>>> 
>>>> <snip/>
>>>> 
>>>>> Therefore, I would like you to change the ABNF so that it
>>>>> reflects the reality of (Set-)Cookie usage on the Internet,
>>>>> for the same reason that you have insisted the algorithm
>>>>> for user agent parsing reflects reality.  Changing the ABNF
>>>>> to include base64 does not do that -- it is just another
>>>>> fantasy production that differs from all prior specs of
>>>>> the cookie algorithm.  Changing it to
>>>>> 
>>>>> cookie-value      = %x21-2B / %x2D-3A / %x3C-7E / %x80-FF
>>>>> 
>>>>> or just the minimum
>>>>> 
>>>>> cookie-value      = %x21-2B / %x2D-3A / %x3C-7E
>>>> 
>>>> Hi Roy,
>>>> 
>>>> The latter seems fine, and in conversation with Adam he indicated to me
>>>> that he would not object to such a change.
>>> 
>>> Okay by me.
>> 
>> One nit: I would exclude %x22 because there are interoperability
>> problems with cookie-values that contain %x22.
> 
> So:
> 
> cookie-value    = %x21 / %x23-2B / %x2D-3A / %x3C-7E
> 
> If there are no objections, I'll add an RFC Editor note to that effect.

There have already been objections -- that is what started this thread.

%x22 is DQUOTE.  I am not aware of any interoperability concerns
with the use of DQUOTE in opaque cookie values, though I can
understand why they might be a concern.  However, use of them as
a quoted-string value (where browsers store the DQUOTEs as more
opaque data) is extremely common because the past two RFCs defined
the value as token / quoted-string.

I just noticed a grammar bug in my suggestion. It should have been

  cookie-value      = *( %x21-2B / %x2D-3A / %x3C-7E )

If we would like to limit the use of DQUOTE to how it was limited
in prior RFCs (matching outer pair), then I suggest

  cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
  cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-7E

since that does cover all current usage that I am aware of and
doesn't allow for odd usages of DQUOTE that might be misinterpreted
by parsers that did not implement the Netscape spec but did
implement one of the RFCs.

....Roy

_______________________________________________
http-state mailing list
http-state@ietf.org
https://www.ietf.org/mailman/listinfo/http-state