Re: why no-cache is not reload

Ted writes:
> 	The text in 10.8 of draft-ietf-http-v11-spec-01.html seems
> to indicate that no-cache from a client to a server always requests
> an authoritative version:
> 
> "The 'no-cache' directive on a request message requires any cache to
> forward the request toward the origin server even if it has a cached
> copy of what is being requested.  This allows a client to insist upon
> receiving an authoritative response to its request.  It also allows a
> client to refresh a cached copy which is known to be corrupted or stale."

No, it says "authoritative response".  If the response happens to be
a 200 status, then you have effected a "reload".  If the response is
a 304 status, then you have effected a "refresh".  Thus, saying that
"no-cache" is equivalent to "reload" is wrong.  All existing software
uses these semantics for IMS and Pragma: no-cache.

> 	On a related note, does cache-control: max-age 0 also force
> a reload (by asking for a copy of the resource that is no older than
> 0 seconds old?).

No, it forces a "refresh" (i.e., a conditional GET on the next inbound
server w/max-age=0, which results in a conditional GET on the origin).
It is possible that the refresh will result in a reload, but only if
the server decides that the resource has changed.

I realize that this may seem confusing, but we need to understand that
the two concepts of "don't answer from a cache" and "conditional GET"
are completely orthogonal -- the fact that they are used in tandem to
achieve a forced refresh versus a forced reload does not mean we should
change the names to be more "meaningful", particularly when such a name
change would in fact be less meaningful then what we use now.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Saturday, 17 February 1996 02:00:03 UTC