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

Received on Wednesday, 22 December 1999 13:19:41 UTC