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

Re: HTTP Session Extension draft

From: Ted Hardie <hardie@merlot.arc.nasa.gov>
Date: Thu, 6 Jul 1995 09:15:37 -0700 (PDT)
Message-Id: <199507061615.JAA20038@merlot.arc.nasa.gov>
To: Brian Behlendorf <brian@organic.com>
Cc: hopmann@holonet.net, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
The Session-ID: proposal and the idea of both sides of a connection
being able to request that the connection remain open are not, I
think, necessarily at odds.  I agree that Session-IDs can be used
to generate stateful information for use by servers, but there
are situations when a maintained session may be a better idea for
resource allocation reasons or because of the type of data the
server will be putting out.  Consider as an example the current "server-push"
Netscape animations (these mimic the behavior of a server-initiated maintain,
without negotiation--the server just doesn't close the connection).  As
I mentioned to Alex in email, there are times when the server knows what
kind (and amount) of data will be put on the wire and the client does not.

In the clicktrail example, I believe that many things could be accomplished
by Session-ID:, but that some fairly important things could not.  In a
Session-ID: clicktrail you get information about what documents are selected
as they are selected; with a maintained connection you could instrument a
browser to provide information about what is done with the information while
it is being viewed on the client end.  Even knowing whether the browser was
the active application during the "dead time" that appears in server logs
would be a big win in our understanding of what the users are up to.  

Given the negotiation needed for client-initiated sessions, I don't really see 
disadvantage for letting the server negotiate something similar with the client.

					Ted Hardie
Received on Thursday, 6 July 1995 09:13:04 UTC

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