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

On 2013-01-30 15:34, 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?
>
> "…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

Received on Sunday, 3 February 2013 16:34:53 UTC