David Morris wrote:
> I must have missed something ... if I build an application which needs
session
> like control, I have a real hard time believing that I would find any
> intermediate caching (as in proxy) acceptable.
This is almost certainly to be the case, however, the client which is the
remote end of your session may have other interactions with the server on
which your app runs. It is possible that the client will interleave non-
cachable requests to your application with requests for which the responses
are cacheable. (Example: I'm buying some books from your application but get
bored and decide to check out the "What's new page on your server." Then,
after fooling around a bit, I return to the book-buying process.) Because
HTTP is connectionless, the only way to make sure that sessions continue is
to send the State-Info: whenever the client requests the server (or with
cookies: whenever it requests specific paths on the server.) Sometimes, the
requests will go to applications that don't require or can't use the State-
Info and those apps may return cachable data. There isn't much anyone can do
to prevent that.
> Providing a mechanism where any
> arbitrary user could retrieve information cached from a session-id based
> connection seems like an unnecessary exposure of semi-private information.
None of the proposals that I have seen (Dave Kristol's, Cookies, Koen's, etc
.) have this property. All provide some mechanism to prevent inappropriate
caching of session related information. If anything, the current proposals
all do too much to prevent or forbid otherwise valid caching.
> Hence, I would contend State-Info will have little impact since caching
> would/should be disabled in most contexts where State-Info applies.
State-Info: will have an impact if:
1. Use of State-Info: prevents caching that would otherwise be permitted.
In the example above, the "what's new" page is probably cachable. However,
if State-Info: use can prevent that page from being cached, this would not
be good. Cache builders also need to think about whether arrival of a
response which contains State-Info: should be allowed to change the caching
status of an earlier response for the same URL that did not contain State-
Info.
2. If State-Info headers become large: i.e. if people starting putting
kilobytes of shopping cart information into State-Info, then this will tend
to consume more than a justified amount of net resources. (NOTE: I have
proposed mechanisms by which servers can ensure that State-Info headers are
always very small -- and private.)
bob wyman