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

------ Original Message ------
From: "Roy T. Fielding" <fielding@gbiv.com>
>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.
ok, I think this should be in the spec somewhere.

It's great to have a deterministic way to evaluate precedence of c-c 
directives when they conflict, so we should lead implementors in the 
same direction.

Regards

Adrien


>
>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 21:28:17 UTC