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

> > Personally, I think that "no-cache" is much more clear than "reload".
> > "reload" makes me think of reload buttons on browsers, and these have
> > little to do with the caching of normal requests.
> 
> I was just about to say something about this as well, but different.
> 
> 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, ...

Actually, what the current implementation understand with "Pragma:
no-cache" is "guarantee contact with the origin server".  The proxies
may still do conditional GETs wrt their own cached copies.

> ... such that
> 
>     GET / HTTP/1.1
>     Cache-Control: no-cache
> 
> will indeed result in a "reload" action, but

The reload may be serviced from a proxy cache, though (but the proxy
*has* made an up-to-date check that has finally reached the origin
server).

>     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 not necessarily true in current implementations.  Proxies may
do a conditional GET wrt their own cached copy (the L-M times may be
different; in practice they're the same most of the time).

I'm not arguing one way or another, just stating a fact of current
implementations.

Cheers,
--
Ari Luotonen				ari@netscape.com
Netscape Communications Corp.		http://home.netscape.com/people/ari/
501 East Middlefield Road
Mountain View, CA 94043, USA		Netscape Server Development Team

Received on Wednesday, 10 January 1996 11:50:00 UTC