Subject: RE: Clarification on cacheability

From: "Josh Cohen (Exchange)" <[email-masked]>
Date: Wed, 22 Dec 1999 12:01:02 -0800

> -----Original Message-----
> From: Roy T. Fielding [mailto:[email-masked]]
> Sent: Wednesday, December 22, 1999 11:55 AM
> To: Josh Cohen (Exchange)
> Cc: HTTP-WG (E-mail)
> Subject: Re: Clarification on cacheability 
> 
> 
> >So, my question essentially comes down to this:
> >If I invent a new 3xx status code, or overload an existing 3xx
> >code but I include a cache-control: header to explicitly
> >allow caching, can a cache cache the results?
> 
> Only if the cache recognizes (understands the semantics of) the
> new status code.
> 
> BTW, this is what you want for the WAP answer.  If they try 
> to use anything
> other than a 3xx, they are on their own.
>
Thanks for the response.
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?

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.
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"?

> ....Roy

---

From: Jeffrey Mogul <[email-masked]>
Date: Wed, 22 Dec 1999 13:16:07 -0800

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 22 Dec 1999 14:34:45 -0800

>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.

>cache it.  However, that would be broken, thus you shouldnt send cache

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.

....Roy