RE: Cache-Control

> -----Original Message-----
> From: Jeffrey Mogul [mailto:mogul@pa.dec.com]
> Sent: maandag 14 augustus 2000 20:24
> To: Joris Dobbelsteen
> Cc: http-wg@cuckoo.hpl.hp.com
> Subject: Re: Cache-Control
>
>
>    My question is what should a proxy/user-agent do if it receives
>    the request:
>
> 	cache-control: private, public, max-age=180, s-maxage=120
>
> I'm going to assume that the word "request" in your email is
> a mistake, and that you meant "response".  Three of the four
> directives you listed are undefined for requests.  With
> that in mind:

I didn't see that at time I was writing the mail, but you are right,
I meant response instead of request.

>
> The answer is different for a (shared) proxy and for a (non-shared)
> user-agent.
>
> A user-agent (presumably with a "non-shared cache") should
> ignore the "private" and "s-maxage" directives, and so
> this is equivalent *FOR A NON-SHARED CACHE* to
>
> 	Cache-Control: max-age=180

What about "public"???

>
> A shared proxy cache, on the other hand, has no sensible
> way to interpret this header field, because RFC2616 says:
>
>    public
>       Indicates that the response MAY be cached by any cache,
> even if it
>       would normally be non-cacheable or cacheable only within a non-
>       shared cache. (See also Authorization, section 14.8, for
>       additional details.)
>
>    private
>       Indicates that all or part of the response message is
> intended for
>       a single user and MUST NOT be cached by a shared cache. This
>       allows an origin server to state that the specified parts of the
>       response are intended for only one user and are not a valid
>       response for requests by other users. A private
> (non-shared) cache
>       MAY cache the response.
>
> Given that the "private" directive in your example does NOT list
> any specific parts of the response, it therefore must refer to
> the entire response.  But this means that the "public" and
> "private" directives are conflicting, and so the server that
> sent the response has a bug.

Ok, that's true. That is why I send this example, to see how you (HTTP WG)
think how to handle this...

>
> As a general rule, I would recommend that if a received
> response appears to be buggy, it is stupid to cache it.
> (Another way to look at this: if the server implementor
> appears to have misunderstood the HTTP caching specification,
> then a cache implementor ought to protect the user from
> that implementor's mistake.)  Don't cache responses if
> they cannot unambiguously be cached with "semantic transparency"
> (see RFC2616).

Let's if I understand it right:
Meaning your recommendation whould be:

Private Cache (NON-SHARED)
    Cache it (max-age = 180)

Public Cache (SHARED)
    Don't cache it (conflicting cache-control)
    However on the other had, the server did send s-maxage=120,
    so it's caring for public caches.....

>
> -Jeff
>
>

- Joris

Received on Tuesday, 15 August 2000 06:39:48 UTC