Subject: RE: Clarification on cacheability

From: "Josh Cohen (Exchange)" <[email-masked]>
Date: Wed, 22 Dec 1999 17:28:09 -0800

> -----Original Message-----
> From: Roy T. Fielding [mailto:[email-masked]]
> Sent: Wednesday, December 22, 1999 5:15 PM
> To: Josh Cohen (Exchange)
> Cc: HTTP-WG (E-mail)
> Subject: Re: Clarification on cacheability 
> 
> 
> >But any cache can cache it as long as it obeys the 
> cache-control/expires
> >header.
> >The navdoc is safe to cache..
> 
> If one client is led to believe that they have received a 
> representation
> of the requested resource, while another client is led to believe that
> they have received instructions on how to navigate to such a 
> representation,
> then the navdoc is not safe for a shared cache.  

this is the case.  This is why I started the discussion since I thought
sending back 200 OK (with the unexpected navdoc) was a mistake.

As usual, your comments are excellent.  
if a GET to a URL ALWAYS results in a (unexpected navdoc), then
is it really safe to cache?
I guess if there is any chance that the response could be different,
based on client auth, client type, or whatever, then it is not safe to
cache. (especially since caches dont filter based on accept before
returning responses)
Its likely that one client who passes an accept: navdoc could
cause the cache to cache a navdoc.  Later a client that does not
pass the accept: navdoc would incorrectly get a navdoc that it
cant understand.  Thus the caching is broken.

---

From: [email-masked] (Koen Holtman)
Date: Thu, 23 Dec 1999 13:44:12 +0100 (MET)

Josh Cohen:
[...]
>cache. 

It _is_ safe to make the response cacheable as long as you use Vary
correctly, this is what Vary was invented for.

>(especially since caches dont filter based on accept before
>returning responses)

As Roy said, most (all?) 1.1 caches don't actually implement the
refined filtering made possible by Vary.  They implement the Vary
requirements in 1.1 by treating 'Vary: anything' as equivalent to
'no-cache'.

But you can still use Vary if you want to help possible future caches:
I would consider this to be good protocol design.  You can find some
examples of the use of Vary+Expires in RFC2295.

Koen.