Re: Possible optimization to State-Info proposal
Dave Kristol (dmk@allegra.att.com)
Mon, 28 Aug 95 12:16:22 EDT
Rather than clog the 'net with Koen Holtman's last message and my
annotations, let me try to identify what I think I don't understand
about his response. Please note I will be away for a week starting
today, so things should quiet down. :-)
I think we need definitions for: idempotent (method) and dynamic
response. It isn't enough to say idempotent == {GET, HEAD}.
I think the prevailing definition of an idempotent {method, URI} pair
is that you get back exactly the same content each time you make a
request with that pair.
A dynamic response is a time- or context-dependent (State-Info
dependent, possibly) response to a {method, URI} pair.
The problem I have is, the user agent can't tell, a priori, whether a
given request is dynamic or not. Apparently the only way to tell is to
look for a Pragma: no-cache or Expires: <yesterday> header. Do those
reach the user agent reliably (assuming the origin server produces
them)?
Koen said:
Suppose that a response is dynamic, i.e. suppose it has a Pragma: no-cache
or Expires: <yesterday> header. This means that the proxy is forbidden
from caching the response. Suppose that the proxy, for whatever reason, is
unwilling or unable to comply to this restriction. If this is the case,
and State-Info headers are involved, them the cache should return a HTTP
error code 501 (Not Implemented) to the requesting client, and throw away
the response.
If you're going to introduce dependencies on State-Info specifically,
you could just as well introduce the requirement that responses that
contain State-Info not be cached. Why the need for extra headers?
Is there ever a reason to cache a response that contains State-Info?
In this case, the caching server would respond with 501 when it saw
State-Info.
Dave Kristol