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

On Jan 30, 2013, at 6:34 AM, Mark Nottingham wrote:
> On 28/01/2013, at 9:22 AM, Roy T. Fielding <fielding@gbiv.com> 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?

Yes.  Generally speaking, if the origin server puts two mutually
exclusive directives in the same header field, they want the
recipient to apply the most lenient one to which they are fully
compliant (i.e., the same principle we define for extensions).

If the origin server doesn't want that, then it doesn't send public.

I don't see anything vague about it (at least no more vague than the
concept of caching itself).  And keep in mind that this is only a
MAY for caches: they don't have to cache it; they have permission to.

> "…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.

That's fine, but we still need to publish 22 today.

....Roy

Received on Wednesday, 30 January 2013 16:56:25 UTC