Subject: [http-state] draft-ietf-httpstate-cookie-09 algorithm descriptions

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Jul 2010 15:13:44 +0200

Hi,

I realize that this may sound like nitpicking, but I really think that 
some parts of the spec are both too vague in some aspects, and overly 
precise in others.

See, for example, Section 5.4.:

> 5.4. The Cookie Header
>
>
>    When the user agent generates an HTTP request, the user agent SHOULD
>    attach exactly one HTTP header named Cookie if the cookie-string
>    (defined below) for the request-uri is non-empty.

It says "SHOULD attach exactly one", but doesn't really state the header 
field value. Oversight?

>    A user agent MAY omit the Cookie header in its entirety.  For
>    example, the user agent might wish to block sending cookies during
>    "third-party" requests.

So we have "SHOULD send" and "MAY omit". The "MAY" makes attaching the 
header truly optional (correctly), thus the "SHOULD" requirement is 
incorrect.

It would probably better to start the section by stating that sending 
the header is truly optional, and then describe the remainder of the 
algorithm.

>    The user agent MUST use an algorithm equivalent to the following
>    algorithm to compute the cookie-string from a cookie store and a
>    request-uri:
>
>    1.  Let cookie-list be the set of cookies from the cookie store that
>        meet all of the following requirements:
>
>        *  Either:
>
>              The cookie's host-only-flag is true and the canonicalized
>              request-host is identical to the cookie's domain.
>
>           Or:
>
>              The cookie's host-only-flag is false and the canonicalized
>              request-host domain-matches cookie's domain.
>
>        *  The request-uri's path path-matches cookie's path.
>
>        *  If the cookie's secure-only-flag is true, then the request-
>           uri's scheme must denote a "secure" protocol (as defined by
>           the user agent).
>
>              NOTE: The notion of a "secure" protocol is not defined by
>              this document.  Typically, user agents consider a protocol
>              secure if the protocol makes use of transport-layer
>              security, such as SSL or TLS.  For example, most user
>              agents consider "https" to be a scheme that denotes a
>              secure protocol.

Are we comfortable with not stating what is secure? At least for those 
protocols in use today we may have to.

>        *  If the cookie's http-only-flag is true, then exclude the
>           cookie unless the cookie-string is being generated for an
>           "HTTP" API (as defined by the user agent).

This is in the section "The Set-Cookie header". That's always an "HTTP" 
API, right?

Maybe the algorithm ("computing the cookie string") and the header 
definition need to be separated some more?

>    2.  The user agent SHOULD sort the cookie-list in the following
>        order:
>
>        *  Cookies with longer paths are listed before cookies with
>           shorter paths.
>
>        *  Among cookies that have equal length path fields, cookies with
>           earlier creation-times are listed before cookies with later
>           creation-times.
>
>        NOTE: Not all user agents sort the cookie-list in this order, but
>        this order reflects common practice when this document was
>        written, and, historically, there have been servers that
>        (erroneously) depended on this order.
>
>    3.  Update the last-access-time of each cookie in the cookie-list to
>        the current date and time.
>
>    4.  Serialize the cookie-list into a cookie-string by processing each
>        cookie in the cookie-list in order:
>
>        1.  Output the cookie's name, the U+003D ("=") character, and the
>            cookie's value.
>
>        2.  If there is an unprocessed cookie in the cookie-list, output
>            the characters U+003B and U+0020 ("; ").
>
>    NOTE: Despite its name, the cookie-string is actually a sequence of
>    octets, not a sequence of characters.  To convert the cookie-string
>    (or components thereof) into a sequence of characters (e.g., for
>    presentation to the user), the user agent SHOULD use the UTF-8
>    character encoding [RFC3629].

Here the spec is pedantic, which is a bit strange as just in the 
paragraph above it talks about characters :-).

Also, we may want to say "SHOULD use the UTF-8 ... to *decode* the octet 
sequence". Which in turn begs the question: what if the octet sequence 
isn't valid UTF-8? - Also, do we have any evidence that servers actually 
use UTF-8 here?

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Wed, 14 Jul 2010 10:12:03 -0700

On Wed, Jul 14, 2010 at 6:13 AM, Julian Reschke <[email-masked]> wrote:
> I realize that this may sound like nitpicking, but I really think that some
> parts of the spec are both too vague in some aspects, and overly precise in
> others.
>

I've add the following requirement:
[[
        <t>If the user agent does attach a Cookie header field, the user agent
        MUST send the cookie-string (defined below) as the value of the header
        field.</t>
]]

> header truly optional (correctly), thus the "SHOULD" requirement is

Why is the SHOULD requirement incorrect?  Here are the possibilities
in order of desirability:

* Exactly one Cookie header.  (Most desired.)
* Zero Cookie headers.  (Acceptable; might impair functionality but
there are reasonable motivations for to UAs might do this.)
* Exactly two Cookie headers.  (Permitted, but undesirable.)
* Exactly three Cookie headers.  (Permitted, but undesirable.)
* etc

> It would probably better to start the section by stating that sending the
> header is truly optional, and then describe the remainder of the algorithm.

I'm not sure what "truly" means.  UAs SHOULD send exactly one Cookie
header, but they MAY omit the Cookie header in its entirety.

> protocols in use today we may have to.

I think that's beyond the scope of this document.  For example, is TLS
secure if we don't verify the server's certificate?  What if we use
the null cipher?

> This is in the section "The Set-Cookie header". That's always an "HTTP" API,
> right?

Nope.  The algorithm is designed to be re-used independently, e.g., by
HTML5's document.cookie API.

> definition need to be separated some more?

They're conceptually separate.  They just appear sequentially in the
same section for readability.

> Here the spec is pedantic, which is a bit strange as just in the paragraph
> above it talks about characters :-).

I added this paragraph at the request of the working group.  I agree
that it's overly pedantic and said as much at the time.

> sequence".

Done.

> Which in turn begs the question: what if the octet sequence isn't
> valid UTF-8?

Good question.  Thankfully, the answer to that question doesn't impact
interoperability and is not observable in the protocol so we don't
need to answer it.  :)

> Also, do we have any evidence that servers actually use UTF-8 here?

Nope.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Jul 2010 14:21:32 +0200

On 14.07.2010 19:12, Adam Barth wrote:
> On Wed, Jul 14, 2010 at 6:13 AM, Julian Reschke<[email-masked]>  wrote:

If this is a MUST, you can't make sending a single header a SHOULD. 
Unless the MUST only applies to UAs that do send a single header.

> in order of desirability:

Because we say "MAY omit".

> * Exactly three Cookie headers.  (Permitted, but undesirable.)

2 or 3 headers would be a violation of the SHOULD.

> header, but they MAY omit the Cookie header in its entirety.

"SHOULD do X" and "MAY do not(X)" doesn't work. It's a conflict of 
requirements.

I'd phrase this as:

"Sending cookies is optional. UAs MAY omit cookie headers for various 
reasons (...).

When cookies are sent, UAs SHOULD send them in a single header instance, 
using the cookie value as defined ...."

> ...
> ...

I have no idea. You are the expert. What do UAs do here?

> same section for readability.

What I'm saying is that both appearing in the same section, even when no 
HTTP message is involved, is *confusing*.

> interoperability and is not observable in the protocol so we don't

If it doesn't impact interop, then it shouldn't have a SHOULD attached 
to it.

>> Also, do we have any evidence that servers actually use UTF-8 here?

So maybe this statement should be dropped.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Thu, 15 Jul 2010 09:23:31 -0700

On Thu, Jul 15, 2010 at 5:21 AM, Julian Reschke <[email-masked]> wrote:
>>> some
> If this is a MUST, you can't make sending a single header a SHOULD. Unless
> the MUST only applies to UAs that do send a single header.

Why?  The MUST applies to each Cookie header field individually.  If
you send 34 Cookie header fields, each one of them MUST contain a
cookie-string as defined below.

> "SHOULD do X" and "MAY do not(X)" doesn't work. It's a conflict of

You keep saying that, but you haven't explained why.

> using the cookie value as defined ...."

This formulation would appear to say that sending one cookie header
and zero cookie headers are equally preferable.  However, sending one
cookie header is preferable over sending zero.

> I have no idea. You are the expert. What do UAs do here?

The point is that it's beyond the scope of this document.  It would be
reasonable, for example, for some UAs to only send Secure cookies over
TLS connections that have a sufficiently strong cipher suite, but
that's an issue for some other specification or an issue that might
not need to be specified at all.

>>> API,

Maybe to you.  :)

> If it doesn't impact interop, then it shouldn't have a SHOULD attached to
> it.

I've changed this to a "might wish."

> So maybe this statement should be dropped.

That's been my opinion from the beginning.  However, you'll have to
convince the folks in the working group who advocated for this text to
be added.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Jul 2010 18:35:49 +0200

On 15.07.2010 18:23, Adam Barth wrote:
> On Thu, Jul 15, 2010 at 5:21 AM, Julian Reschke<[email-masked]>  wrote:

So sending 34 identical headers would be ok?

> You keep saying that, but you haven't explained why.

See the definitions in RFC 2119. MAY is for making something OPTIONAL. 
SHOULD makes things RECOMMENDED, allowing deviation only in exceptions. 
It's simply the wrong keyword for talking about optional things.

> cookie header is preferable over sending zero.

Actually, no, it isn't.

What's better depends on the privacy settings in the UA.

>> HTTP message is involved, is *confusing*.

Yes.

> I've changed this to a "might wish."

That's better...

> convince the folks in the working group who advocated for this text to

So please speak up...

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 17 Jul 2010 03:53:57 +0200

* Julian Reschke wrote:
>[Sending one Cookie header is better than sending no Cookie header?]

I agree with what Julian said on that.

>> convince the folks in the working group who advocated for this text to

We have octets in the Set-Cookie and Cookie headers and we have Unicode
code points in the `document.cookie` attribute. There needs to be a spe-
cification how to map between the octets and the code points or one that
makes that unnecessary or clearly point out that this is undefined.

The other day I used Wireshark to capture all traffic generated when my
http://cutycapt.sf.net/ tool loaded the Alexa top 1000 web sites, and
there was not a single instance where non-ASCII octets occured in either
the Cookie or Set-Cookie header in HTTP messages.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Adam Barth <[email-masked]>
Date: Sat, 17 Jul 2010 10:08:51 -0700

> So sending 34 identical headers would be ok?

I've banned this because it's silly and none of the major UAs do it.

> SHOULD makes things RECOMMENDED, allowing deviation only in exceptions. It's
> simply the wrong keyword for talking about optional things.

This question is moot because the text no longer exists in the document.

Adam

---

From: Adam Barth <[email-masked]>
Date: Sat, 17 Jul 2010 10:10:43 -0700

> the Cookie or Set-Cookie header in HTTP messages.

Indeed.  This is the very definition of a tempest in a teapot.

1) This doesn't occur in practice.
2) If it did occur, it would only be observable via an API that is not
contained in this document.
3) If such APIs care, they can define how to translate octets to characters.
4) We give a hint to the folks defining those APIs so they'll
hopefully do something reasonable.

I don't see that there's anything more for us to do here.

Adam

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Jul 2010 20:51:31 -0600

A point of clarification below...

> You keep saying that, but you haven't explained why.

In my own specs I've often formulated things as "SHOULD do X, but MAY do
Y instead", however it's not really consistent with RFC 2119, which
defines the terms as follows:

   SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

vs.

   MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

The way I understand the distinction is that "SHOULD" means "this would
be a MUST except there are legitimate reasons for an implementation or
deployment to act otherwise, such as..." -- whereas "MAY" means "this is
well and truly a matter of preference on the part of software developers
and service providers".

I refrain from judgment about which of these conformance levels applies
to the technical matter under discussion here.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/