- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Fri, 08 Feb 2013 22:35:38 +1300
- 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. Amos
Received on Friday, 8 February 2013 09:36:10 UTC