Re: HTTP Session Extension draft

(sorry for the large amount of included text)

On Wed, 5 Jul 1995, Alex Hopmann wrote:
> 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.

Huh?  Not a well-tuned server serving to responsible clients :)  And in 
that case it's the kernel, not the http daemons.  I'm particularly 
addressing the situation, which I though ted was suggesting, whereby a 
connection is kept open between page accesses (not just between inlined 
media accesses).  I don't think my usage is exactly typical, but I know 
that the amount of time I spend inbetween consecutive hits to the same 
server varies greatly - so what would be the appropriate length of time 
before the server says "forget it, the client's taken too long to 
followup...".  

> 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.

That's just how it should work - anything more liberal, though, like 
holding the connection open in anticipation of more clicks, seems like it 
might be past the point of diminishing returns.  It'll obviously take a 
bake-off of come sorts to determine that though.  I do know that 
fixed-number-of-process-based http daemons (netsite, apache, etc) would 
have trouble with idle but still open and stateful connections.  

> 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

Right, it was discussed on www-talk about 4 months ago (I think), in response
to my proposal for a simple Session-ID header (random string generated at
application launch time, static only during the duration of the visit, useful
for threading together interleaved but separate users from behind firewalls
so an accurate count of visitors can be obtained).  Their proposal is
certainly more powerful than simple Session-ID's, but I had questions as to
whether the power it grants is in the most progressive direction - it allows
the server to build smarter and smarter mechanisms, like shopping carts, when
really shopping carts should be a client-side application in my opinion. 
Won't stop it from being put into Netscape 1.2 of course, with the
corresponding "you must be using N1.2 to view these pages!"  messages across
the net I'm sure.... 

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/

Received on Wednesday, 5 July 1995 20:48:44 UTC