W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: #430 / #268 - definition of "public"

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Fri, 08 Feb 2013 22:35:38 +1300
Message-ID: <5114C6EA.7030701@treenet.co.nz>
To: ietf-http-wg@w3.org
On 8/02/2013 10:04 p.m., Roy T. Fielding wrote:
> Actually, I was wrong about the precedence rule on cache-control.
> It turns out that only applies to extension directives that
> specifically override existing directives.
> RFC2616 does have a general rule for precedence in section 13.1.3
> that I just found only after researching the history of Cache-Control
> back to the original drafts:
>     The Cache-Control header allows a client or server to transmit a
>     variety of directives in either requests or responses. These
>     directives typically override the default caching algorithms. As a
>     general rule, if there is any apparent conflict between header
>     values, the most restrictive interpretation is applied (that is, the
>     one that is most likely to preserve semantic transparency). However,
>     in some cases, cache-control directives are explicitly specified as
>     weakening the approximation of semantic transparency (for example,
>     "max-stale" or "public").
> so the opposite rule that exists for directive extensions (extensions can
> override more restrictive standard directives) does not apply when we are
> considering two standard directives. Hence, no-store and no-cache should
> still override public except for the one case that is explicitly specified.
> Or at least it would if something like the above text is restored in p6.

I think the relationship between no-cache and public is irrelevant, 
since no-cache does permit caching with revalidate contitions.

CC:no-store,public and CC:private,public are the difficult cases.

Received on Friday, 8 February 2013 09:36:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC