[...]
>If your application requires a "stateful dialog" between client and
>server, clearly there are interactions with caching: the if a request
>for resource R is made first with dialog identifier X and subsequently
>with dialog identifier Y, a proxy must not satisfy the second request
>with a cached response from the first request.
True, with statefull dialogs, caching must be disabled. This however
does not mean, as you said in your original `session-id redux'
message, that
> The cookie [or session-id] must be part of the key a proxy cache uses
> to find cache hits, [...].
Another way to disable caching is for the service author to put a
Expires: <yesterday> headers in the response. Thus, we get the
following proxy requirements:
- the proxy must of course not cache beyond the expires date
(I hear some braindead system managers configure their proxies
to cache even expired stuff for a small amount of time, contrary
to what the spec says.)
- session-id (or cookie) is *not* part of the cache key
- to handle a request with cache key CK and session-id SI:
1) if there is a non-expired entity under cache key CK,
return it
2) if there is no (or no un-expired) entry cached under CK, pass
the request (with the session-id) to the server, and cache the
response under CK if not forbidden by an Expires <yesterday>
header.
Under this scheme, entities (like inline pictures or product
description pages in a shopping (basket) application) that do not
depend on the session-id can be cached as usual.
Compare this to the session-id-in-the-url hacks that are currently
used often by shopping (basket) applications. There, product
description pages must always be dynamically generated, and thus
cannot be cached, because every URL on the product description page
must have the session-id in it.
Clearly, in terms of bandwidth, session-id-in-the-url is a very costly
solution to the statefull dialog problem. Also, it is not without its
problems: the user loses the `already visited link' rendering by the
browser between sessions, and if the user stores an URL with a
session-id in it in his personal hotlist, or, worse, puts it on a
`list of interesting products you can buy in virtual shops' he
maintains on the web....
More to the point, HTTP must provide at least one session-id
equivalent header that does *not* belong to the cache key. If no such
header is present, statefull dialogs in which only only a small amount
of the response entities are state-dependent will keep requiring much
more bandwidth than needed.
[...]
>On the other hand, my Request-ID proposal had no caching interactions.
As I explained above, session-id and cookie have more caching
interactions than, say, the From and Date headers. Servers always had
the option of returning something different for requests that have
identical cache keys: they should just tell the caches that they do so
by using Expires headers on the responses.
>Yikes!!! My most recent set of proposals vanished into the bitbucket!
Did they? I just reread your old request-id proposal, and it still
looks good to me, as long as the request-id uses a different $session
string for each server it talks to.
>Before Brian and others throw in the towel, consider this revised
>set of proposals:
>I'm not risking email again. I'll stick it on the web:
>http://www.w3.org/hypertext/WWW/Protocols/demographics.html
I just read it. Good work! Being able to point to this document will
save me quite some time when writing a summary of the session-id
thread.
Do you want the 128 bit true-random number in III to be remembered by
the client across sessions (invocations), or is this exactly not what
you want?
If you don't want it to be remembered, I think that I. and III. in
your revised proposal are basically equivalent. That is not
necessarily a bad thing, I. could be the
session-id-not-in-the-cache-key (I disagree strongly with what you say
about inappropriate use at the end of I.), and III. could be the
session-id-in-the-cache-key.
>Dan
Koen.