W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: making progress on State-Info

From: Dave Kristol <dmk@allegra.att.com>
Date: Sat, 9 Dec 1995 21:25:51 -0500
Message-Id: <v01530500aceff3ec287f@[]>
To: Ari Luotonen <luotonen@netscape.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Ari Luotonen <luotonen@netscape.com> wrote:
>> [DMK wrote:]
>> 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.

Whoa!  I don't think I *impose* anything.  I pointed out that a server
implementation could choose to structure its State-Info, or not.  How the
server implements them will naturally have an impact on how CGIs are
>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.

This is definitely true.
>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.

[Sorry, Larry M.]  Yes, I agree that Cookies are used and work for
real-life applications.  I welcome the possibility to improve them.  Many
of us await a more detailed specification of the current Cookie mechanism
so we can do just that.

Dave Kristol
Received on Saturday, 9 December 1995 18:29:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC