#430 / #268 - definition of "public"

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?

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

Received on Wednesday, 30 January 2013 14:35:17 UTC