Re: Session-ID proposal

-- [ From: Bob Wyman * EMC.Ver #2.5.02 ] --

V1.6 of Dave Kristol's proposal states in section 3.1 that "The origin
server effectively ends a session by sending back no State-Info header." The
fact that the session is terminated by *not* sending back a State-Info
header is what leads to the requirement for "reflecting" which is discussed
in Section 4.1 of his proposal.

I suggest that the rule in Section 3.1 be changed to read "The origin server
ends a session by sending back a State-Info header with no value." And, I
would rewrite the first paragraph of Section 3.2 to read as follows:

"In the normal case, a user agent is expected to remember the State-Info
response header it receives from each origin-server (distinguished by name
or IP address and Port) and return it with all subsequent requests to that
origin server. Each State-Info response header overwrites any previously
remembered value for that origin server. If the value of the State-Info
response header is empty, the user agent discards any remembered State-Info
for that origin server." 

This change will result in essentially the same protocol, however, there
would be lower network resource consumption since less State-Info would flow
across the network. Servers would tend to send State-Info only when it
changes -- not to keep a session alive. Since State-Info can grow to be very
large in some implementations (i.e. where you are sending a full shopping
cart back and forth) this savings could end up being significant.

I don't think this amendment will increase the complexity of either the
server or the client. As far as the server goes, the same logic that would
have had it decide not to send State-Info in the response would now cause it
to send null State-Info. As far as the client goes, the only difference
would be that it would have to remember to always send State-Info when
talking to the origin server -- instead of simply remembering to send it on
the next request to the origin-server. Since the "next request" is an
arbitrarily large number of requests after the previous one, the client has
to put the State-Info into some form of intra-session persistent storage
anyway.

In one way, this proposed modification would actually end up making the
State-Info mechanism more robust during the transitional period before
servers generally understand and handle State-Info correctly. For instance,
some CGI interfaces allow a script to add headers to an outgoing response.
Given such a server, it would be possible for script writers to start using
State-Info as soon as clients can handle it, even if the server is not able
to. However, if a CGI script on such a server was to add State-Info to a
response, it is likely that the client will get false "session end" messages
if the user hits a page not managed by the CGI script and thus probably
ignoring State-Info headers. Given the re-write, the client would ignore the
fact that it didn't get any State-Info back and would continue to send it in
future requests until either it gets null State-Info from the CGI script or
until it terminates execution. Thus, CGI scripts can be written to use State
-Info now, even on servers which don't support it -- if the amendment is
accepted.


		bob wyman

Received on Tuesday, 22 August 1995 20:24:11 UTC