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

Right, and those cases are made clear here:

https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#response.cacheability

Closing as incorporated.


On 08/02/2013, at 8:35 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

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

--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 18 February 2013 00:04:57 UTC