Re: Possible optimization to State-Info proposal
Dave Kristol (dmk@allegra.att.com)
Fri, 25 Aug 95 10:02:32 EDT
Shel Kaphan <sjk@amazon.com> wrote:
> 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.
> 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.
This idea sounds promising. Let me expand a bit from an operational
standpoint. Remember the recent change whereby a user agent retains
its State-Info if it receives no State-Info from a server. If caching
proxies followed the rule that they cached only those documents for
which they received no State-Info from the origin server, and if origin
servers were careful to send State-Info only when it changed, I believe
caching proxies would be able to cache anything cachable (in the
State-Info context).
Upon getting a one, a caching proxy could satisfy a request for a
resource from the cache if there were a fresh one available, whether or
not the request contained a State-Info request header. (That's a
change, and it would indeed enhance caching.)
The idea of an idempotent method could be expanded to imply that, not
only does the resource not change, but its State-Info does not change
either. (I guess that's obvious if you bundle State-Info into a
larger concept of "the resource".)
Nice idea! If the dust settles without major objections, I'll add this
to a state-info-01 I-D. That will be a couple of weeks, after some
vacation.
Dave Kristol