RE: Clarification on cacheability

> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@kiwi.ICS.UCI.EDU]
> Sent: Wednesday, December 22, 1999 2:35 PM
> To: Josh Cohen (Exchange)
> Cc: HTTP-WG (E-mail)
> Subject: Re: Clarification on cacheability 
> 
> 
> >So, what do you mean by that?  SHould they re-use a 3xx code 
> that allows
> >caching ? Which of those would be best ? 
> >The idea of using 305 Use proxy came up, what do you think of that?
> 
> I'd just define a new 3xx code and use that.
>
that sounds good, except that existing caches cant cache it.
 
> >In regard to your 206 rationale..
> >The 206 is a clear case of why you dont want to cache, but by default
> >it wouldnt be.  Actively adding cache-control would instruct 
> the cache to
> >cache it.  However, that would be broken, thus you shouldnt 
> send cache
> >control
> 
> No, you are confusing the requirements.  A cache that doesn't 
> understand 206
> won't cache it because of the MUST NOT on unrecognized codes.  A cache
> that does understand 206 will look at the cache-control field.
> 
> These are forward-looking requirements: we don't know what 
> the semantics
> of the new code may be, and this is the only way to specify 
> proper handling
> of future sementics in the presence of intermediary caches.
> 
> I think the WAP folks are confused in any case -- it would be 
> foolish to
> mark a client-specific redirection response as cacheable by anything
> less than a fully-compliant 1.1 proxy with Vary, which itself 
> is so rare
> that they should just assume that their new code will be understood by
> any cache that might gain from caching it.
> 
But any cache can cache it as long as it obeys the cache-control/expires
header.
The navdoc is safe to cache..
> ....Roy
>