W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1999

RE: Clarification on cacheability

From: Josh Cohen (Exchange) <joshco@Exchange.Microsoft.com>
Date: Wed, 22 Dec 1999 17:28:09 -0800
Message-ID: <BFF90FB6CF66D111BF4F0000F840DB850BCBBEE1@lassie.dns.microsoft.com>
To: "'Roy T. Fielding'" <fielding@kiwi.ICS.UCI.EDU>, "Josh Cohen (Exchange)" <joshco@Exchange.Microsoft.com>
Cc: "HTTP-WG (E-mail)" <http-wg@hplb.hpl.hp.com>
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@kiwi.ICS.UCI.EDU]
> 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.
Received on Thursday, 23 December 1999 01:31:54 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:34 EDT