Re: Cache behavior in the absence of a Fresh-until: header

    The current semantics of 
    
	Cache-Control: no-cache
    
    are identical to that of
    
	Pragma: no-cache
    
    which is not the semantics of a "reload" action.  "no-cache" means
    no interference from the cache, such that
    
	GET / HTTP/1.1
	Cache-Control: no-cache
    
    will indeed result in a "reload" action, but
    
	GET / HTTP/1.1
	If-Modified-Since: Wed, 10 Jan 1996 10:07:34 GMT
	Cache-Control: no-cache
    
    is only a conditional GET that is answered by the origin server
    (i.e., a freshness check on the origin) which may still result in
    a 304 response and thus is not considered a "reload" action.
    
This is why I tried to make a distinction between "reload" and
"revalidate".  According to both the HTTP/1.0 and 1.1 specs, 

	"Pragma: no-cache" ... allows a client to refresh a cached
	copy which is known to be corrupted or stale.

I think we seem to agree that the protocol has to provide a way
for a client to say "reload this resource from the origin server
no matter what", since it's possible that a cache could have a
corrupt copy but not realize it.

What I couldn't deduce from those specs is what is supposed to
happen in the following scenario.

Suppose we have a "paranoid" client that, for whatever reason, wants to
insist on revalidation (but not reloading) on all of a set of
retrievals.  For example, I might be visiting a server that apparently
has been sending out totally bogus Fresh-until: (or Expiration:)
values, and I've learned the hard way that revalidation is necessary.
On the other hand, the bandwidth to the server is limited, so I don't
want to reload a bunch of large files.

When any client visits a page for the first time, it does an
unconditional GET (because it has neither a cache validator nor a
last-modified time).  If the cache has a fresh copy of the resource, we
would normally expect it to serve it from the cache.  If the paranoid
client includes "no-cache" on one of these GETs, then the cache would
have to reload it; it doesn't have the option of simply revalidating
(under the semantics that Roy describes).

This is why I proposed separate "reload" and "revalidate" cache-control
request directives.

I am not committed to the name "reload"; if you want to call it
"no-cache", that's fine with me.  But I think we need to have both
directives available.

And if you really want "no-cache" to mean "reload if neither
If-modified-since: nor If-valid: is included, otherwise revalidate" I
suppose that is OK (since I don't expect that a client would send a
conditional if it also wanted to insist on a reload); it just seems
simpler to me to define "no-cache" as "always reload" and "revalidate"
as "always revalidate", and not have to tie their semantics to other
headers.

-Jeff

Received on Wednesday, 10 January 1996 22:36:01 UTC