Re: [http-state] Conformance classes

[Dan Winship <[e-mail]>]

On 12/16/2009 02:51 PM, Daniel Stenberg wrote:
> I don't necessarily think that incoming must match outgoing, but if a
> client is supposed to accept incoming Set-Cookie: headers given a
> certain format, then that format is the legal one.

The asymmetry in incoming vs outgoing is to deal with the fact that we
know there are lots of bad servers out there, and there will almost
certainly continue to be lots of bad servers out there after we publish
the new spec, and so we want to explain to good clients how to deal with
bad servers, but we don't want to encourage servers to be bad.

That is, (as I see it) we're trying to define (a) a nice, clean grammar
and semantics, and (b) a gross, nasty client-side processing model, such
that:

    1. If a server sends out Set-Cookie headers that conform to the
       nice grammar, and makes only the assumptions that are supported
       by the nice semantics, then we believe that that server will be
       compatible with essentially all cookie-handling HTTP clients,
       *even if those clients don't use the gross, nasty processing
       model*.

    2. If a client uses the gross, nasty processing model, then we
       believe that that client will be compatible with essentially all
       cookie-sending HTTP servers, *even if those servers don't use
       the nice, clean grammar and semantics*.

Another reason to want a clean grammar is that people might want to cite
our new cookie RFC in the future (eg, if draft-broyer-http-cookie-auth
or something like it gets started up again), and we want them to be
citing something sane, not "cookies have names except when they don't,
and here are the 17,000 date formats you should know how to parse". (We
can even say explicitly that protocols that build on top of our spec
MUST conform to the nice grammar and MUST NOT assume that clients will
follow the nasty processing model.)

As far as the rest of the spec goes, I think I'm fine now with having
the nasty processing model be free of MUSTs and SHOULDs. It's not
necessarily *the* cookie-processing model, it's just *a*
cookie-processing model--one that we recommend because it's very good at
dealing with lots of different broken servers, but if you don't care
about all of those broken servers then you don't need to use all of the
rules.

-- Dan