Re: [http-state] draft-ietf-httpstate-cookie-05 posted

"Yngve N. Pettersen (Developer Opera Software ASA)" <> Thu, 11 March 2010 01:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85CF03A69DE for <>; Wed, 10 Mar 2010 17:20:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pd40CWPCxbfn for <>; Wed, 10 Mar 2010 17:20:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 096B23A6A69 for <>; Wed, 10 Mar 2010 17:20:21 -0800 (PST)
Received: from acorna ( []) (authenticated bits=0) by (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o2B1K5IQ016156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Mar 2010 01:20:15 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
References: <>
To: "Adam Barth" <>, http-state <>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <>
Organization: Opera Software AS
Date: Thu, 11 Mar 2010 02:20:03 +0100
Message-ID: <op.u9dpzpdoqrq7tp@acorna>
In-Reply-To: <>
User-Agent: Opera Mail/10.10 (Win32)
Subject: Re: [http-state] draft-ietf-httpstate-cookie-05 posted
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Mar 2010 01:20:32 -0000


On Sun, 07 Mar 2010 19:50:57 +0100, Adam Barth <> wrote:

> My understanding is that Monday is the deadline for uploading I-Ds
> before IETF77.  I've uploaded the latest version of the draft:
> If you're going to IETF77, this is the version of the draft that we'll
> be discussing.  Looking forward to seeing many of you there.

Here are some comments about this draft

* "infelicities". While the general meaning is relatively obvious  from
context, IMO a more generally known phrasing should be chosen, e.g.
"unfortunate choices"

* Section 2. "General nonsense"? Maybe a more "appropriate" title should
be used?

* Maybe discuss race conditions when a cookie set by one response is
needed in the next request, but user interaction blocks the cookie for a
while. The user agent may have to delay sending requests to prevent user
experience problems. Additionally, such race conditions can occur if one
resource depends on a cookie being set by a separate request and the
dependent request is not dependably started after receipt of the cookie
in the first request.

* 3.1 examples

           "Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure, HttpOnly"

should be

           "Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly"

Comma is not allowed as a separator in Set-Cookie; it is used in RFC 2109
and 2965 to separate multiple cookies in the same header

* 4.1 definition of Max-age is missing. It is used in 5.2.1

* 4.1 Multiple Set-cookies in the same response with the same name and
should not be used. Opera ignores cookies with the same name following an
unexpired cookie, including cookies set from other parallel requests (see
also race conditions, usually only a problem when the user is manually
accepting cookies) I have also observed that such multiple cookies in the
same requets can cause problems for sites when the client picks the
"wrong" cookie

* 4.1 sane-cookie-date should IMO discourage dates past 2036 due to 32-bit
time_t rollover, at least for the time being. Might recommend best
behavior for clients, and might suggest that using too long expiration
time should be avoided?

* 4.1 cookie-value should be token or quoted-string. Quotes are
particularly needed if the value contain restricted characters, like ";" .
RFC 2109 allows quoted string

* The domain description should emphasize that cookies with
non-dotted domain attributes MUST be refused, the example should instead
be from a ccTLD, e.g.

* 5.1.1  delimiter  should include which ASCII character each hex value
represent in a comment

* 5.1.2 The domain parser should mention IDNA encoded names, and how to
process them. IMO, all names must be converted to A-label for purposes of
comparison, and server should/(must?) only send A-labels; although clients
may understand UTF-8 encoded names.

* 5.2.2 The expires should not be processed if there is a max-age
attribute. 5.3 does specify that max-age take precedence, but it might be
an idea to specify precedence elsewhere, too.

* 5.3 Have the name of "Mozilla Public Suffix list" been checked? just to
make sure the name is correct

* 5.3 step 10: Maybe specify that client must ignore cookies with
expiration date at the current time? (similar with use of "expiration date
in the past" elsewhere)

* 5.4 "elide" is  not a word I see frequently, and may be confusing to
some readers, though it is clear from the context. (I searched through 3
CDs of Baen ebooks and found the word used in just one book)

* 7.5 should mutually distrusting server on different machines in the same
domain  be mentioned? (even though it is mentioned somewhat in 7.6)

Yngve N. Pettersen

Senior Developer                     Email:
Opera Software ASA         
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01