Subject: [http-state] consensus call: cookie server conformance

From: =JeffH <[email-masked]>
Date: Thu, 27 Jan 2011 15:06:43 -0800

<chair>

Please see PeterSA's recent message..

   http://www.ietf.org/mail-archive/web/http-state/current/msg01151.html

Absent explicitly expressed opposing views here on the http-state@ mailing 
list, I'm going to interpret the WG's consensus to be in favor of the 
modification as proposed by PeterSA...

 > First, I proposed that we could modify Section 1 as follows:
 >
 >    Compliant servers MUST limit themselves to the well-behaved profile
 >    defined in Section 4 when generating cookies.
 >
 > Second, I proposed that we could then simplify Section 4 as follows:
 >
 >    This section describes the syntax and semantics of a well-behaved
 >    profile of the Cookie and Set-Cookie headers.

Y'all have 1 week, till 2400h PST 3-Feb-2011 (next Thu night) for expressing 
viewpoints on this.

thanks,

=JeffH

</chair>

---

From: Dan Winship <[email-masked]>
Date: Fri, 28 Jan 2011 17:00:58 -0500

>>    profile of the Cookie and Set-Cookie headers.

-1, because Section 4 says "cookie-value=token", which is annoying
(since it prohibits both base64 and URI encoding, both of which are
commonly used) and unnecessary for interoperability (both existing and
future clients will DTRT with non-token values) and widely violated by
real-world servers that would otherwise be considered well-behaved.

I suppose I could probably be happy with

    cookie-value  = token | base64-string
    base64-string = <a base64 string, defined in [RFC4648], Section 4>

and then change the later Base 16 reference back to Base 64. This still
declares lots of perfectly-interoperable servers "non-compliant", but it
at least provides them with a sane way out.

-- Dan

---

From: "Anne van Kesteren" <[email-masked]>
Date: Sat, 29 Jan 2011 11:24:57 +0100

> at least provides them with a sane way out.

Why would we not want to their usage conforming too?

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Dan Winship <[email-masked]>
Date: Sat, 29 Jan 2011 11:15:08 -0500

> Why would we not want to their usage conforming too?

Well, really, very few servers are going to be fully conforming right
away, since the majority don't use rfc1123-date for Expires, etc.
(There's no way we can have a sane server grammar and NOT declare at
least 50% of existing servers non-compliant.) The question is how hard
it is for them to become compliant (if they care) and how hard it is for
new servers to start out compliant. (And how ugly we want to let the
"sane" grammar get.)

But then again, why should servers care about becoming compliant?
Compliant clients MUST be able to deal with servers that violate every
single line of the Section 4 grammar, and non-compliant clients are not
guaranteed to deal with Max-Age, so for a server, compliance with the
section 4 grammar is neither necessary nor sufficient to guarantee
interoperability. So what exactly is "compliant server" supposed to
mean, besides "You get a gold star"?

I think "well-behaved" was a good description of Section 4, and we
should just leave it at that, and not even say that servers SHOULD obey it.

(So that's a change to my previous vote. I still think we should open up
the definition of cookie-value a bit, to closer reflect reality, and to
get rid of the silly Base 16 suggestion. But I'm -1 to "MUST" even after
that.)

-- Dan

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 29 Jan 2011 17:52:04 +0100 (CET)

On Fri, 28 Jan 2011, Dan Winship wrote:

> commonly used)

I hadn't really considered these details about 'token' there and I agree that 
it seems a bit too strict.

Why did we limit it like that?

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Sat, 29 Jan 2011 11:37:23 -0800

On Sat, Jan 29, 2011 at 8:52 AM, Daniel Stenberg <[email-masked]> wrote:
> I hadn't really considered these details about 'token' there and I agree
> that it seems a bit too strict.
>

That rule comes from RFC 2109 (with the bogus parts of the RFC 2109
cookie-value syntax removed).  It's certainly stricter than we need.
Something like allowing base64 sounds reasonable to me.

Adam

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 29 Jan 2011 21:19:03 +0100

>modification as proposed by PeterSA...

I think the Working Group should recharter, or, alternatively, do what
the charter says. Apart from producing a proper test suite and a proper
description of deviations from the main specification, that would mean
replacing, say, the date parsing algorithm that's been made up on the
spot, and not doing what is proposed here, namely describing the proto-
col in a manner that is inconsistent with the vast majority of servers.

At the very least I would expect the main specification to say that the
protocol it describes is how some people wish it would work, instead of
incorrectly claiming it is an actual description of how it's "actually
used on the Internet". I don't mind requirements that are unlikely to
ever propagate into practise, but I do mind being dishonest about them.
-- 
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: Daniel Stenberg <[email-masked]>
Date: Sat, 29 Jan 2011 22:51:36 +0100 (CET)

On Sat, 29 Jan 2011, Bjoern Hoehrmann wrote:

> replacing, say, the date parsing algorithm that's been made up on the spot, 
> and not doing what is proposed here, namely describing the proto- col in a 
> manner that is inconsistent with the vast majority of servers.

I read the date parser algorithm as describing a parser with a set of 
capabilities that a date parser for cookies should have. It doesn't say that 
the parser has to work exactly like that.

I consider "my" date parser compliant, but it parses the string in a different 
way than described in the spec.

-- 

  / daniel.haxx.se

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 29 Jan 2011 23:13:22 +0100 (CET)

> Something like allowing base64 sounds reasonable to me.

As a little comparison, my parser (that seems to work with a vast majority of 
all sites) simply allows anything except ; and = in a cookie name, and 
everything except ; and \r and \n in cookie contents.

Of course that doesn't really say that servers will use all those letters, 
only that a receiving end really has little reason to make it more strict than 
this.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Sat, 29 Jan 2011 14:44:47 -0800

On Sat, Jan 29, 2011 at 2:13 PM, Daniel Stenberg <[email-masked]> wrote:
> As a little comparison, my parser (that seems to work with a vast majority
> of all sites) simply allows anything except ; and = in a cookie name, and
> only that a receiving end really has little reason to make it more strict
> than this.

I'd have to check the details, but I suspect that agrees with the user
agent requirements for the current draft, although there might be some
subtitles w.r.t. whitespace handling.

That said, I wouldn't recommend that servers make use of that full
flexibility.  For example, sending unpaired UTF-16 surrogates,
malformed UTF-8 sequences, or null characters is probably not a good
idea.

The question boils down what's sensible for servers to send.  IMHO,
token + base64 is reasonable, but I don't feel that strongly about it.

Adam