Re: [http-state] parser rules of draft-ietf-httpstate-cookie-22
"Roy T. Fielding" <fielding@gbiv.com> Thu, 24 February 2011 21:30 UTC
Return-Path: <fielding@gbiv.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 075503A6848 for <http-state@core3.amsl.com>; Thu, 24 Feb 2011 13:30:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.932
X-Spam-Level:
X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 1mRW7BBrk8cU for <http-state@core3.amsl.com>; Thu, 24 Feb 2011 13:30:10 -0800 (PST)
Received: from homiemail-a71.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id C1E123A6807 for <http-state@ietf.org>; Thu, 24 Feb 2011 13:30:10 -0800 (PST)
Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 64B1B428079; Thu, 24 Feb 2011 13:31:01 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=dHXgEQcq4FZiUiZi sbqfe5aXN3niAZLvNyIDNAkaGz5Hfp+LZsSSaxXHo50UHINweqImadOfDK5mPiGN utRQQk1AZeig0QkBcZBPqDg9fUlAEJmKQfFHNMKfwd6K//3jsmTjhKVSESB+ztVm MiitOV1n+O1cPjFCHeEudxdd41I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=xYXSrWvsFSkJtpUIsoHaclvGFSM=; b=PtHf1EsfpYBmDOXqcmQ2lWys7Uly GPYLS6EboAUK+PHSUMVE0nYsfs3mLkYntbgr9leN6m1uI6EcSEZKH4eLzLe9AdYj WWnlLidJHSeuaZOPdASgSY2d7LzHQHDgwEpEDeTcB9SjcmcvoQXhSEAdR5D+PPh3 O3udVpJjG5lfSNs=
Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 1AD00428078; Thu, 24 Feb 2011 13:31:01 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <4D66C718.3000300@stpeter.im>
Date: Thu, 24 Feb 2011 13:31:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <1CE31B7F-5D95-4CFE-B9A1-FBCC9461E472@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> <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>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1082)
Cc: http-state <http-state@ietf.org>, iesg@iesg.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
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:30:12 -0000
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
- Re: [http-state] Is this an omission in the parse… Remy Lebeau
- [http-state] Is this an omission in the parser ru… Remy Lebeau
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Remy Lebeau
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Julian Reschke
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Remy Lebeau
- Re: [http-state] Is this an omission in the parse… Remy Lebeau
- Re: [http-state] Is this an omission in the parse… Remy Lebeau
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Roy T. Fielding
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Remy Lebeau
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Remy Lebeau
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Remy Lebeau
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Peter Saint-Andre
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Peter Saint-Andre
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Roy T. Fielding
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Roy T. Fielding
- Re: [http-state] Is this an omission in the parse… Julian Reschke
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Julian Reschke
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Roy T. Fielding
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Adam Barth
- Re: [http-state] Is this an omission in the parse… Remy Lebeau
- Re: [http-state] Is this an omission in the parse… Dan Winship
- Re: [http-state] Is this an omission in the parse… Remy Lebeau
- [http-state] parser rules of draft-ietf-httpstate… Roy T. Fielding
- Re: [http-state] parser rules of draft-ietf-https… Peter Saint-Andre
- Re: [http-state] parser rules of draft-ietf-https… Roy T. Fielding
- Re: [http-state] parser rules of draft-ietf-https… Adam Barth
- Re: [http-state] parser rules of draft-ietf-https… Peter Saint-Andre
- Re: [http-state] parser rules of draft-ietf-https… Roy T. Fielding
- Re: [http-state] parser rules of draft-ietf-https… Remy Lebeau
- Re: [http-state] parser rules of draft-ietf-https… Adam Barth
- Re: [http-state] parser rules of draft-ietf-https… Roy T. Fielding
- Re: [http-state] parser rules of draft-ietf-https… Adam Barth
- Re: [http-state] parser rules of draft-ietf-https… Dan Winship
- Re: [http-state] parser rules of draft-ietf-https… Adam Barth
- Re: [http-state] parser rules of draft-ietf-https… Peter Saint-Andre