- From: David W. Morris <dwm@xpasc.com>
- Date: Fri, 21 Feb 1997 20:03:02 -0800 (PST)
- To: Koen Holtman <koen@win.tue.nl>
- Cc: Dave Kristol <dmk@research.bell-labs.com>, yarong@microsoft.com, http-wg@cuckoo.hpl.hp.com
On Fri, 21 Feb 1997, Koen Holtman wrote:
> If server authors tell us that they prefer some form of Set-Cookie-V1 to the
> current compatibility scheme, then I'd prefer to have Set-Cookie-V1, if it
> can be had without horrible procedural side-effects.
I think sending two forms would be trivial (speaking with my server and
service author hats on).
>From a protocol perspective, I'd prefer something more neutral vis a vis
version. Examples Set-Cookie-New or Cookie-Set.
Then keep the version parameter on the set for future extensibility AND
require it in the cookie itself IF the request included both forms for
any set. Other wise version would default to 1.
The server would recognize the cookie version from the request as follows:
a. If it sent one, it would match what was sent in version.
b. If both versions were sent, it would look for the version parameter
and that would tell all. We would need to make sure the version
appeared in a reasonable position parsing wise.
I don't see this as any more coding than the current approach which still
requires logic to try to figure out the cookie version.
NOW given that we seem to need a new header for the new cookie format,
could we PLEASE add the ability to mark cookies as both expiring AND NEVER
stored on disk? In that case, the cookie expires the earlier of
expiration time or when the client shutsdown.
Dave Morris
Received on Friday, 21 February 1997 20:05:37 UTC