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

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Feb 2013 17:34:24 +0100

On 2013-01-30 15:34, Mark Nottingham wrote:
>
> On 28/01/2013, at 9:22 AM, Roy T. Fielding <[email-masked]> wrote:
>
>> Fine, but I hope you realize that is what RFC2616 defined. Combining cacheability and freshness into one category in p6 lost that distinction, and yes it was an intended design. There is nothing wrong with telling a cache that a response doesn't have a fixed expiration time. That's why found the prior text so disconcerting in p2.
>>
>> The alternative would be to say that if a response contains public but no max-age, then a cache cannot reuse it without revaluation, which is clearly not what the origin server wants.
>
> To catch folks on the list up, Roy has since created:
>    http://trac.tools.ietf.org/wg/httpbis/trac/ticket/430
> … and incorporated a proposal.
>
> """
> The "public" response directive indicates that any cache &MAY; store the
> response and reuse it for later requests, even if the response would
> normally be non-cacheable or cacheable only within a non-shared cache.
> (See <xref target="caching.authenticated.responses"/> for additional
> details related to the use of public in response to a request containing
> <x:ref>Authorization</x:ref>.)
> """
>
> Does anyone have a problem with re-opening the definition of public?
>
> Personally - I'm not against it in principle, but I don't like this specific text. A large part of why we restricted the effect of public in #268 was that this is absurdly vague and open to interpretation; e.g., does it mean that "public" in a response that also has "no-store" can be happily stored?
>
> "…even if the response would normally be non-cacheable or cacheable only within a non-shared cache" needs work. I'm happy to make a specific proposal, given a bit of time, and if folks are amenable to doing so.
>
> I'm re-opening the ticket pending this discussion.
>
> Regards,
>
> --
> Mark Nottingham   http://www.mnot.net/

How can we make progress here?

We have tons of changes in the editor's copy, so we really should ship 
-22 as soon as possible.

With respect to this bug, we have

a) the text that was in 2616,

b) the text that has been in httpbis for long,

and

c) Roy's latest changes to b).

Can we ship either b) or c) as -22, and then try to resolve the issue 
quickly, ship -23, and do a final WGLC?

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 8 Feb 2013 01:04:10 -0800

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.

....Roy

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 08 Feb 2013 22:35:38 +1300

> 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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Feb 2013 11:04:27 +1100

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 <[email-masked]> wrote:

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

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 19 Feb 2013 16:20:26 +1300

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

one more difficult case is present...

How to interpret Cache-Control:private,private="foo"

For now we are going to interpret it as Cache-Control:private in Squid.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Feb 2013 14:22:18 +1100

> For now we are going to interpret it as Cache-Control:private in Squid.

I think that is the correct interpretation; 'private' without an argument appears in the response, therefore it can't be stored by a shared cache.

Cheers,