Re: HTTP Session Extension draft

>I'm not convinced that this is a bad idea.  It might improve performance
>(although I would guess that the main advantage will come from reduced
>cryptographic operations when doing authentication and privacy).  It
>might not require much extra work on the part of the server (since
>the server will need at least some "state" to hold on to the TCP
>connection).  And a server implementor who prefers not to implement
>any state-saving mechanism could simply refuse to allow sessions.
>
>However, it might be wise to consider modifying the session model
>so that the server can reply with either of two codes:
>	Connection: maintain-stateful
>indicating that the server is remembering the client's request header
>fields, or
>	Connection: maintain-stateless
>indicating that the server is not remembering, and the client must
>retransmit all relevant request headers per method invocation.
>(Of course, the server has a third option: return neither code,
>implicitly indicating "nonpersistent-stateless".)
While in principle your above suggest seems perfectly sound I would rather
leave it out since I do think that there can be quite a bit to be gained in
being able to omit sending most of the headers. I guess the most convincing
reason however to me is just a reduced complexity one. I wanted to add as
few options as possible.

I have actually been having some private mail discussions with several
people latelly in which they were expressing their frustrations with the #
of accept headers you would have to transmit in order to properly negotiate
a wide variety of new content-types.

I admit that this doesn't absolve us from having to fix the Accepts: field.
(In that the # of accepts field headers grows far too large with lots of
features & content types to negotiate), but I still think it helps is fit
most requests into one TCP packet.


Quick question since I'm not familiar with most other HTTP server designs.
Is it really going to be difficult to keep things like accepts header
information along with the connection (in any particular implementation)? It
seems to me that somewhere you need to keep track of your sockets, whether
its by thread, process, or just a pool. And so just keeping that info
associated with the sockets/connections/whatever-your-platform-calls-it
shouldn't really be difficult.

Alex Hopmann
ResNova Software, Inc.
hopmann@holonet.net

Received on Monday, 10 July 1995 13:49:07 UTC