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

"Roy T. Fielding" <fielding@gbiv.com> Tue, 15 February 2011 20:28 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 0EA6A3A6D93 for <http-state@core3.amsl.com>; Tue, 15 Feb 2011 12:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level:
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 IzGgPuQbKGYT for <http-state@core3.amsl.com>; Tue, 15 Feb 2011 12:28:57 -0800 (PST)
Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id BD83F3A6D7B for <http-state@ietf.org>; Tue, 15 Feb 2011 12:28:57 -0800 (PST)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 33550674074; Tue, 15 Feb 2011 12:29:24 -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=ygY0OKG+dNOQNY15 bsqWYqkmwrz9p9/q6zKsTJIWR4xNLdV/mfbmb9QVb4n2j72MUTpoLsnWa7Rnx2jf Y9rOm6xTYpV8dBBiBIsRIjbk5y3m8TriK7gpojm+izfK3kOGw/cwHnOshSHR64Br 3BDacT4eKjUxUG/2TBRDZrIuJKE=
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=tyEPSJBlwbO4CaZW/r2ZNiyQp8U=; b=sg+D5HoFopxDglEGNqnS3uviWRT+ KVElHQJoFWtG0cX80AZcrdHQcfn3UkHCqdwnhVzAfnKv35t+smFxniXNa61VM6QH 4jk+nL6AkksekBahoOeBI/cnnW92j9sr7KkD1/gQKld+Ft/e+ZEx3zjorlQ0iT4D aJUmKWGO/Fejq+Q=
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-a29.g.dreamhost.com (Postfix) with ESMTPSA id EDFA0674059; Tue, 15 Feb 2011 12:29:23 -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: <AANLkTimrJF3LFR4t4j=U2L33kFh+wf-R=sjjwexcmyPi@mail.gmail.com>
Date: Tue, 15 Feb 2011 12:29:23 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <26240DE2-4DD3-4863-81B1-635D34BA4AE4@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>
To: Adam Barth <ietf@adambarth.com>
X-Mailer: Apple Mail (2.1082)
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: Tue, 15 Feb 2011 20:28:59 -0000

On Feb 14, 2011, at 8:42 PM, Adam Barth wrote:
> On Mon, Feb 14, 2011 at 7:23 PM, Roy T. Fielding <fielding@gbiv.com>; wrote:
>> Parsing for user agents is defined in section 5.  Servers have to
>> parse cookies as well, and the grammar provided in section 4 is wrong
>> for both generation and parsing.
> 
> I agree that the grammar depicted in Section 4 is not appropriate for
> parsing.  That grammar is not for parsing.  It's for generation.
> Perhaps we should add instructions for how servers should parse the
> Cookie header?  That's absent from the current document.

We don't need more instructions.  We need a correct ABNF that tells
us what to generate and what to parse.

> As for generation, there's no exogenous notion of correctness.  We can
> speak about usefulness, if you like, but correctness is endogenous to
> this document.

Then you should delete the introduction, since it says

   This document specifies the syntax and semantics of these headers as
   they are actually used on the Internet.  In particular, this document
   does not create new syntax or semantics beyond those in use today.

>> Why do you want to push forward a document with a known error in the
>> grammar?  Just fix it.
> 
> I disagree that it's an "error."

Then please explain to Amazon why you want to break their site?
Look at your browser's cookies for amazon.com and you will probably
find cookies named session-token, at-main, and x-main that do not
follow your grammar.  They are quoted strings and valid under all
prior descriptions of the Cookie and Set-Cookie header fields.

And while you are at it, maybe you'd like to explain to Google
why you want to make Google Analytics cookies invalid.

http://code.google.com/apis/analytics/docs/concepts/gaConceptsCookies.html

The cookie named __utmz is not a quoted-string, not a token, and not base64.

>> This is not a trivial detail.  As written, the specification says
>> server developers SHOULD break sites like amazon.com.
>> 
>>   cookie-value      = token / ""
> 
> Can you explain how the developers of site B using a restricted
> grammar for generation will break amazon.com?  That seems entirely
> non-sensical.

Site B is Amazon.com.  You are editing a proposed standard for the
Internet and, last I checked, they use HTTP on the Internet.

>> The correct grammar is in the original Netscape cookie spec: "This
>> string is a sequence of characters excluding semi-colon, comma and
>> white space."  Which easily translates (conservatively) into
>> 
>>   cookie-value      = %x21-2B / %x2D-3A / %x3C-7E / %x80-FF
>> 
>> and it does not conflict with section 5.
> 
> I've updated the draft to recommend the grammar below for generating
> cookie-values:
> 
> cookie-value      = token / *base64-character
> base64-character  = ALPHA / DIGIT / "+" / "/" / "="
> 
> Do you have a particular use case in mind for generating Set-Cookie
> headers outside this grammar?

Yes.  Backwards compliance with existing content stored within
several hundred million deployed browsers that won't expire
until sometime in 2031 dictates that the grammar be

  cookie-value      = %x21-2B / %x2D-3A / %x3C-7E / %x80-FF

because servers have to parse Cookie in every form that they
ever sent a Set-Cookie in the past.

Why are you arguing against this?  You are adamant about
supporting the above syntax in browsers, for the same reasons,
and there is no harm in supporting the complete Netscape syntax
in the server grammar.

....Roy