RE: Clarification on cacheability

so do you think that a server should just
respond 200 ok with the navigation document instead of
the content-body ?


> -----Original Message-----
> From: Jeffrey Mogul [mailto:mogul@pa.dec.com]
> Sent: Wednesday, December 22, 1999 1:16 PM
> To: Josh Cohen (Exchange)
> Cc: http-wg@hplb.hpl.hp.com
> Subject: Re: Clarification on cacheability 
> 
> 
> Josh Cohen writes:
>     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 with 206.  In
>     this (the wap case), caching is what you want, so sending a
>     cache control would be the desired result if the cache cached
>     it.
> 
> I'm not sure I agree.  I don't see any reason why a 206 response
> should not be cached by a proxy that "recognizes" the response.
> (The language that you quoted from section 6.1, "an unrecognized
> response MUST NOT be cached", is a little vague about what
> "recognize" means, but I think we probably agree on that.)
> 
> For example, an HTTP/1.1 server should be able to send
> 
> 	HTTP/1.1 206 Partial Content
> 	Date: whatever
> 	Content-Range: whatever
> 	Etag: "whatever"
> 	Cache-control: max-age=1138
> 
> This means that
> 	(1) a proxy that does not "understand" 206 responses
> 	MUST NOT cache it -- since otherwise the partial
> 	content might be returned to an equally naive HTTP/1.0
> 	browser.
> 	(2) a proxy that does understand 206 responses can
> 	only cache it for 1138 seconds.
> 
> If we followed your interpretation, there would be no way
> for a server to put restrictions on the caching of an
> HTTP/1.1-specific response (via Cache-Control or Expires)
> without allowing HTTP/1.0 caches to store it - yuck.
> 
>     If the default is to not cache it, why not allow cache
>     control to allow caching if either: the cache understands the
>     response code OR if the response is safe to cache "in the
>     normal way"?
> 
> I suppose we could have defined a cache-control directive that
> says "this response is safe to cache by a proxy that
> doesn't actually understand the response status code", but I think
> that would not have been very easy to specify.
> 
> I actually do not understand why you want to treat the "navdoc"
> as a 3xx "Redirection" response instead of treating it as
> opaque (to HTTP) content.  You haven't provided quite enough
> context to explain why this mechanism should be integrated
> with HTTP, instead of layered above it.
> 
> -Jeff
>