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

Re: HTTP Session Extension draft

From: Alex Hopmann <hopmann@holonet.net>
Date: Wed, 5 Jul 1995 20:15:18 -0700
Message-Id: <199507060315.UAA15180@holonet.net>
To: Brian Behlendorf <brian@organic.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On July 5, 1995 Brian Behlendorf wrote:
>On Wed, 5 Jul 1995, Ted Hardie wrote:
>> I also wonder how difficult it would be to allow either side to open
>> the negotiation for a maintained session.  Could we allow the server
>> to send "Session: maintain" in response to a request which (from the
>> servers' point of view) is likely to be followed by requests for which
>> a session-orientation is useful?  Many servers would like to have
>> "click-trail" traces of web users' traversals; if you allow the server
>> to initiate a session, the current kludges using cgi scripts and
>> hidden variables could be eliminated. 
>I'd rather see "clicktrails" tracked by browsers sending Session-ID: 
>lines (which we talked about here a while ago, Bill put in emacs-W3, and 
>I'm hoping is on the list for HTTP/1.x) than by persistant connections.
>You could also use that ID as a key to other stateful information the 
>server wants to keep, but only for a short term.  Also, maintaining that 
>connection might not necessarily improve bandwidth - the thought of busy 
>servers with 1000 concurrent parallel connections all sending KEEPALIVE 
>packets is a little scary :)  
Well the first thing to keep in mind is that those same busy servers are
keeping 1000 records for closed connections that are in the time-wait state.
Note that I am not advocating irresponsible use of sessions, although it
would make sense to me that a clinet might request a session for every HTTP
request that it makes under the assumtion that 90% of HTML pages have some
images on them. And if they dont, you just close the connection as soon as
you have recevied it anyway.

About click-trails and Session-ID's, I would like to point out that Netscape
has something called their Cookie proposal. I was hoping they would
introduce it themselves, but anyway, the URL is:


Basically the gist of it is that a server can return to a client a "cookie"
which is a named piece of data that the client will then return to the
server whenever it is requesting a particular part of URL space. It could
accomplish many of the same things as Session-ID's with the added ability of
keeping track of more information for online shopping, etc..

Alex Hopmann
ResNova Software, Inc.
Received on Wednesday, 5 July 1995 20:16:52 UTC

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