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

Adam Barth <> Thu, 11 March 2010 02:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99CC23A6AE7 for <>; Wed, 10 Mar 2010 18:23:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8tLJA-YaORwg for <>; Wed, 10 Mar 2010 18:23:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 27ACE3A6AD2 for <>; Wed, 10 Mar 2010 18:23:24 -0800 (PST)
Received: by iwn10 with SMTP id 10so2763713iwn.31 for <>; Wed, 10 Mar 2010 18:23:24 -0800 (PST)
Received: by with SMTP id dm19mr200332ibb.86.1268274204437; Wed, 10 Mar 2010 18:23:24 -0800 (PST)
Received: from ( []) by with ESMTPS id 21sm7181288iwn.11.2010. (version=SSLv3 cipher=RC4-MD5); Wed, 10 Mar 2010 18:23:23 -0800 (PST)
Received: by iwn10 with SMTP id 10so2763674iwn.31 for <>; Wed, 10 Mar 2010 18:23:23 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id j18mr417434ibv.82.1268274203178; Wed, 10 Mar 2010 18:23:23 -0800 (PST)
In-Reply-To: <op.u9dpzpdoqrq7tp@acorna>
References: <> <op.u9dpzpdoqrq7tp@acorna>
From: Adam Barth <>
Date: Wed, 10 Mar 2010 18:23:03 -0800
Message-ID: <>
To: "Yngve N. Pettersen (Developer Opera Software ASA)" <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 02:23:25 -0000

Thanks for your detailed comments.  Responses inline.

On Wed, Mar 10, 2010 at 5:20 PM, Yngve N. Pettersen (Developer Opera
Software ASA) <> wrote:
> * "infelicities". While the general meaning is relatively obvious  from
> context, IMO a more generally known phrasing should be chosen, e.g.
> "unfortunate choices"

I'm going resist this editorial change for a bit longer.  I'll
probably eventually concede on this point though.  :)

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

> * 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>

> * 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

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.

> * 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?


          <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

> * 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

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

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

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

The spec has a few layers of abstraction.  In 5.2.2, we don't know
about other attributes.  The requirement is there in 5.3, which has a
slightly more global view.

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

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

> * 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.  :)

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

Well, the confidentiality problems there don't actually arise because
of the cookie protocol.  It's only when we use the cookie protocol
with an HTML user agent that we have a problem.  This issue is
discussed in the third paragraph of that section.  I guess we could
add a more pointed recommendation, but I don't think that's a mistake
that folks are likely to make given the text we have already.