Re: making progress on State-Info

> Let me try to clarify something.  The value for the State-Info header
> is opaque.  But just because the specification says it's opaque does
> not mean a server can't structure the information in some way specific
> to it, such as making the first part a path.

This is imposing a complex infrastructure for state-info maintenance
in the server side, in the state info identifier allocation process.
A CGI application no longer could simply generate a Cookie: header,
but would have to ask the server to allocate it, so that it falls into
the server's unique state identifier space.  The same identifier would
be shared between different applications on the same server, which may
not always be desirable.

Furthermore, a shortcoming in the state-info spec as opposed to the
Cookie spec is that state identifiers cannot be shared between hosts
(unless yet some more infrastructure is laid down on the server
cluster side).  Not all systems are self-contained in a single host,
and therefore there is value in being able to share cookies accross
different hosts.

In order for the state-info to be useful, it has to be usable.  In
theory it may seem great, but the moment you apply it in practice
you'll bump into problems.  Those problems have for the most part
already been thought of and solved in Netscape's Magic Cookies, and
they've been proven to work in real-life applications.  I don't claim
that there isn't be room for improvement, but I think time would be
better spent in finding those improvements and adding them to cookies,
rather than taking a step back and starting from scratch again with
something that isn't all that much better.

Cheers,
--
Ari Luotonen				ari@netscape.com
Netscape Communications Corp.		http://home.netscape.com/people/ari/
501 East Middlefield Road
Mountain View, CA 94043, USA		Netscape Server Development Team

Received on Saturday, 9 December 1995 17:55:47 UTC