- From: Alex Hopmann <hopmann@holonet.net>
- Date: Wed, 5 Jul 1995 20:15:18 -0700
- 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: http://home.mcom.com/newsref/std/cookie_spec.html 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. hopmann@holonet.net
Received on Wednesday, 5 July 1995 20:16:52 UTC