Re: HTTP Session Extension draft

    >HTTP is stateless, as far as I can tell, because it was the simplest
    >way to get something going, and the original designers didn't know
    >any better.
    
    No way.  I think you guys are confusing the statelessness of HTTP
    with the non-persistence of the underlying transport implementation
    on top of TCP.
    
Mea culpa.  I know the difference, I should have been more precise.

    HTTP is stateless because each request is an independent
    entity that does not depend upon the state left over from any prior
    request (the client may change its behavior based on prior requests,
    but that's different).  Contrast this with FTP, where all commands are
    relative to the prior state.  Even with the session extension, or
    keep-alive, or whatever we want to call it, HTTP will remain a
    stateless protocol.
    
This seems to be up for debate.  The persistent-connection model that
Venkata Padmanabhan and I have been working on for the past year has
implicitly assumed that all HTTP headers would be transmitted for each
request.

However, the draft that started this whole thread, 
	http://ugly.resnova.com/draft-ietf-http-ses-ext-00.txt
says:
   In order to maximize performance beyond just the TCP problem, the
   session extension specifies that several request header fields be 
   saved for the duration of the connection. These include the accepts,
   accept-charset, accept-language, and authentication request fields.
   Unless the client sends a new value for one of these header fields,
   each subsequent request is treated as if its header fields are the
   same as the previous request.
In other words, the "session model", in contrast to the "persistent
connection model", seems to explicitly require the server to maintain
state.

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

The client is not allowed to send a second request until it sees
one of these responses, so there should never be any ambiguity.

-Jeff

Received on Monday, 10 July 1995 12:58:50 UTC