Re: Session-Id

In article <199507220339.XAA24369@hapeville.cc.gatech.edu> J. Pitkow writes:
>
>Yup, and they thought the initial IP allocation scheme would scale well
>too.  How does your solution handle multiple hosts? and situations
>where IPs are hashed to different machines for the same object space 
>like at NCSA and other large sites?
>

Look, if you want a proof of concept try the Netscape site.  They are
a large site.  Access their homepage using a recent Netscape browser.
Their server generates a server-side session-id plus other information
and stores it in a client-side data base on your machine.  For X
versions you can find it in $HOME/.netscape-cookies, for the Mac it is
in a file called "MagicCookie". (I don't know where it is for
Windows).

I assume it is used to generate click trails through their server.
BTW this client side data base exists across sessions with an expiration
date. All the details are in their cookie spec.

We can argue about whether this meets everyones needs or invades privacy,
etc., but it is kind of silly to say it won't work.

Paul Burchard writes:
>> My objections to session-ID are more fundamental.  I feel we are  
>> about to create a crippled mini-HTTP-within-HTTP for special "small"  
>>  objects stuffed into HTTP headers.  I will try to put together an  
>> alternate proposal based on HTTP's existing Link: capability.
>

Sounds interesting.



-- 

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Saturday, 22 July 1995 06:56:43 UTC