Re: cookies: 2/4 headers?

Dave Kristol:
>

[Note: Oops!  I see there is a new daft already, but here are my
comments on your plans anyway.  I have not read the new
cookie-2.36-2.42 draft yet.  I will do so, and coment, at the end of
the week]

>
>I've spent some time this afternoon trying to work through the cookie
>spec to change over to a new header (Set-Cookie2).  I'd like to remove
>two warts in the syntax for the Cookie header:

I'd prefer it if you do not make any cosmetic changes to the syntax of
the Cookie header at this point.

Also, I prefer not to have a Cookie2 header.  You can be compatible
with old servers even if you do not have it.

I think the following compatibility scheme is optimal.

     Server sends:        Client returns:
     ----------------     --------------------
[ NS is header contents with NS cookie syntax, SMG with state-mgmt syntax.]

1. old server, old client

     Set-Cookie: NS       Cookie: NS

2. old server, new client

     Set-Cookie: NS       Cookie: NS

3. new server, old client

     Set-Cookie: NS       Cookie: NS
     Set-Cookie2: SMG

4. new server, new client

     Set-Cookie: NS       Cookie: SMG
     Set-Cookie2: SMG

5. new server which expects new client, old client

     Set-Cookie: SMG       Cookie: <some garbage>

[server reverts to old syntax when getting garbage cookie]

6. new server which expects new client, new client

     Set-Cookie: SMG       Cookie: SMG

Case 6 is for use after N months, when the fraction of old browsers is
low enough.

The same table as a list of rules:

For a new client:
 1) if a Set-Cookie2 header is present, any Set-Cookie header must be
    ignored
 2) When getting SMG syntax, send back SMG syntax
 3) For best results with current software:
      3a) you should be able to recognise and decode NS syntax
      3b) when getting NS syntax, send back NS syntax

For a new server:
 1) Always use SMG syntax in a Set-Cookie2
 2) Be careful when using SMG syntax in Set-Cookie
 3) Send both Cookie: NS and Set-Cookie: SMG for best results with
    current software

>Dave

Koen.

Received on Saturday, 1 March 1997 12:06:07 UTC