- From: <hallam@vesuvius.ai.mit.edu>
- Date: Tue, 07 May 96 11:46:22 -0400
- To: Dave Kristol <dmk@allegra.att.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: hallam@vesuvius.ai.mit.edu
Dave writes: >This is functionally equivalent to Netscape's cookie scheme, a >derivative of which is being standardized as an HTTP "state management" >proposal. For the current set of documents, see >http://www.research.att.com/~dmk/cookie.html. I'm not so sure that this is the case, was the proposal for an authentication token to be created by the client or by the server? If the token is created by the client then there is nothing to distinguish this scheme from cookies. There is a significant advantage to having the client create an opaque, unlinkable session identifier to avoid the need to use cookies. Client created session ids are much more cache friendly than cookies. There is no way a cache can know to create a cookie itself where cookies are being used as authentication tokens. On the other hand a client generated token can be recorded by the client and forwarded (if necessary) to the origin server in a log file exchange scheme. See the following drafts for details: http://www.w3.org/pub/WWW/TR/WD-session-id.html http://www.w3.org/pub/WWW/TR/WD-proxy.html http://www.w3.org/pub/WWW/TR/WD-logfile.html Phill
Received on Tuesday, 7 May 1996 09:08:31 UTC