- From: Dave Kristol <dmk@allegra.att.com>
- Date: Sat, 9 Dec 1995 21:25:51 -0500
- 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 implemented. > >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