W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

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

From: Adrien W. de Croy <adrien@qbik.com>
Date: Wed, 30 Jan 2013 21:27:26 +0000
To: "Roy T. Fielding" <fielding@gbiv.com>, "Mark Nottingham" <mnot@mnot.net>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "Julian F. Reschke" <julian.reschke@gmx.de>
Message-Id: <emb035a71e-30e4-4dc6-a8d4-43e268e32f7f@bombed>

------ 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 
>>>  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 
>>  response and reuse it for later requests, even if the response would
>>  normally be non-cacheable or cacheable only within a non-shared 
>>  (See <xref target="caching.authenticated.responses"/> for additional
>>  details related to the use of public in response to a request 
>>  <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.



>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.
Received on Wednesday, 30 January 2013 21:28:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC