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

[Dan Winship <[e-mail]>]

On 01/29/2011 05:24 AM, Anne van Kesteren wrote:
> On Fri, 28 Jan 2011 23:00:58 +0100, Dan Winship <[e-mail]>
> wrote:
>> -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.
> 
> 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