Re: HTTP Session Extension draft

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

Aside from the issue of tracking, I suggest that the decision to
maintain a session should always be initiated by the client.  That
is, the client should offer to use a session, and the server should
either accept the offer or not.

I see no point in trying to define a mechanism for servers to
ask a client to maintain a session, if the client has not already
indicated a willingness to do so.  My intuition is that this
mechanism would become quite complex, and would almost never pay
off.  Session-capable clients, I believe, would almost always offer
to use sessions, since it doesn't really cost them anything.

A client (or proxy) that initially doesn't want to use sessions
probably would not accept the offer from a server.

Remember, any participant (client, server, or proxy) can close
a session at any time, so I see no reason for a session-capable
client to ever not request the use of a session.  (Perhaps someone
will contradict me on this.)

    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 :)

The TCP specifications require that the default initial KEEPALIVE timer
be at least 2 hours.  I see no reason for any idle session to last
this long; the server should probably kill off idle sessions after
a few minutes.  So there should never be any keepalives sent.

In fact, I don't see why any HTTP client or server should use KEEPALIVE
at all; application-level timeouts should work just as well.  Perhaps
some version of the HTTP spec should recommend against using KEEPALIVE.

-Jeff

Received on Thursday, 6 July 1995 10:19:39 UTC