Re: HTTP Session Extension draft

Putting off server-initiated sessions until a new compliance-level is
reached makes sense.  I do think there are a couple of big wins in
allowing both sides to negotiate a session (primarily in the arena of
customizing presentation based on what has already been seen, but also
in terms of resource allocation), so it may make sense to note the
intention to extend the Connection: maintain syntax at a later time.
That way those who implement now can put in the appropriate hooks for
later functionality.
			Regards,
				Ted Hardie





> >
> >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.  The browser could respond to
> >such a request by a server with a simple Session: maintain
> >confirmation.
> I don't think that would work. The main reason is that most clients are
> waiting for the server to close the connection to know when they have
> reached the end of a response. Therefore when a non-compliant client
> connects to a server and the server tries to open the negotiation, the
> client will be stuck in limbo. If this extension gets incorporated into HTTP
> 1.1 or something where compliance is necessary in order to advertise a
> client as being HTTP 1.1, then maybe we could have servers initiate the
> sessions. For right now it seems to me that clients should always negotiate
> the Session Extension and then just close the connection if they have
> nothing more to request.
>

Received on Wednesday, 5 July 1995 13:44:55 UTC