Possible optimization to State-Info proposal

I mentioned this before, obliquely in a response on another topic, but
if I'm right, what follows can significantly reduce the potential
performance problems with DMK's State-Info proposal.

In the current version of the proposal (Dave, maybe you should
increment your file number when you change the contents) DMK states
that caching proxies "must pass along a State-Info request header from
the requesting client to the next server, even if it has cached the
requested resource locally."

At first this seemed right, and in fact I made some arguments about
the potential performance impact.  But somebody please tell me what is
wrong with the following reasoning: if a resource is in a cache, it
should only be there because it is possible to "legally" fetch the
resource from the cache without contacting the origin server.  If this
were not the case, the document should not be cached.  Any IDEMPOTENT
method by definition has no side effects at the origin server.  Only
idempotent requests can be served from caches.  Any non-idempotent
method is not allowed to retrieve a cached copy of a resource -- it
must make a request to the origin server.  Key conclusion: An
idempotent request such as GET, which produces no side effects, cannot
affect the state of a stateful dialog.  Therefore, it seems
unnecessary for requests that can be satisfied out of a cache to pass
through any information to the next server.

This, of course, makes it even more imperative that caches not serve
cached documents they shouldn't.

With the recent addition to the proposal that clients stay in the
"have state-info" state when there is no state-info in the server's
(or cache's) response, this means that caches need not "reflect"
state-info either.

--Shel Kaphan

Received on Thursday, 24 August 1995 18:09:16 UTC