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

"Yngve Nysaeter Pettersen" <> Thu, 11 March 2010 17:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 655983A6BBC for <>; Thu, 11 Mar 2010 09:31:48 -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 Vat+kV2kY-jb for <>; Thu, 11 Mar 2010 09:31:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B56663A6DC8 for <>; Thu, 11 Mar 2010 09:06:25 -0800 (PST)
Received: from killashandra.oslo.osa ( []) by (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o2BH6NwC023405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Mar 2010 17:06:28 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Adam Barth" <>
References: <> <op.u9dpzpdoqrq7tp@acorna> <>
Date: Thu, 11 Mar 2010 18:06:27 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve Nysaeter Pettersen" <>
Organization: Opera Software
Message-ID: <op.u9exs1lkvqd7e2@killashandra.oslo.osa>
In-Reply-To: <>
User-Agent: Opera Mail/10.50 (Win32)
Cc: http-state <>
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 17:31:48 -0000

On Thu, 11 Mar 2010 03:23:03 +0100, Adam Barth <> wrote:

> Thanks for your detailed comments.  Responses inline.

>> * Section 2. "General nonsense"? Maybe a more "appropriate" title should
>> be used?
> I'm open to suggestions.  The term "general nonsense" comes from the
> mathematics literature, where it refers to somewhat boilerplate
> information that needs to be included for correctness.

In some documents I've seen these are included in the introduction  
section, such as in RFC 2616

I have tended to reference syntax conventions at the beginning of the  
syntax section

>> * 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.
> That's a good point to bring up.  I wasn't sure where to put that
> warning, so I put it right before the examples.
> [[
>       <t>If a server sends multiple responses containing Set-Cookie  
> headers
>       concurrently to the user agent (e.g., when communicating with the  
> user
>       agent over multiple sockets), these responses create a "race  
> condition"
>       that can lead to unpredictable behavior.</t>
> ]]

Looks OK

>> * 4.1 definition of Max-age is missing. It is used in 5.2.1
> This is intentional.  The folks in the working group didn't think we
> should recommend Max-Age to server operators because it's not
> implemented in Internet Explorer.  I'm optimistic that IE will
> implement it, but that's why it's not there.

I still think it should be there, perhaps with a note that not all clients  
support it (Opera didn't until a couple of years ago), and that servers  
should complement it with an Expires attribute.

>> * 4.1 Multiple Set-cookies in the same response with the same name and
>> scope
>> 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
> I made this slightly stronger:
> [[
>           <t>Servers SHOULD NOT include two Set-Cookie header fields in  
> the
>           same response with the same cookie-name.</t>
> ]]


> Using the same cookie name in overlapping scopes is bad new bears.


>> * 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?
> Done:
> [[
>           <t>To maximize compatibility with user agents, servers SHOULD  
> use
>           sane-cookie-dates before 2036 due to 32-bit "time_t" rollover.
>           Hopefully the industry will resolve this issue in some way as  
> 2036
>           approaches.</t>
> ]]


>> * 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 quoted-string production is not widely implemented and explicitly
> forbidden by this document.  See
> <> for more
> information.


>> * 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.
> I've added as an example here.  This section doesn't contain
> any requirements on user agents, so anything more than advisory for
> servers belongs in Section 5.  In Section 5, we describe the
> requirements on user agents about this issue.  The requirements are on
> the SHOULD-level, not the MUST-level, as discussed by the working
> group in connection with Ticket 3 (search the archives for emails with
> "Ticket 3" in the subject).


>> * 5.1.1  delimiter  should include which ASCII character each hex value
>> represent in a comment
> There are too many of them.  I'd rather folks just wrote the hex
> values in their code.  The ASCII representations are just nonsense.

But perhaps the more commonly used should be mentioned?

>> * 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.
> This is <>.

Forgot about that correspondence.

>> * 5.3 Have the name of "Mozilla Public Suffix list" been checked? just  
>> to
>> make sure the name is correct
> What do you mean by has the name been checked?  The first hit on
> Google for that term is the web site we intend to refer to.

OK. I managed to dig up an email on the topic which also specifically uses  
that name.

>> * 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)
> I'm not too worried about that.  It's virtually impossible to hit the
> current time on the dot.

It is possible for "max-age=0"

>> * 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)
> Elide is a perfectly good word that's been in the language for over
> 200 years.  :)

It may be, but my point is mostly that it is AFAIK not frequently used.

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