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

On Wed, 30 Jan 2013, Roy T. Fielding wrote:

> Neither of which is relevant to this discussion of cache control. It is
> not the recipients job to second guess the origin server.

In this case, the origin server didn't tell the recipient what to do.
The only sane handling of an error is to minimize possible damage. Damage
from caching something which shouldn't be cached is that private
content will be revealed to an unauthorized recipient. Caching is
always optional, so not caching something the server thought could
be cached is at most a performance issue. We've expended an enormous
amount of effort with all the rules and support around insuring
correct behavior around caching. Why would be specify conflict
resolution which assumes more relaxed rules?


> 
> ....Roy
> 
> 
> On Jan 30, 2013, at 1:37 PM, David Morris <dwm@xpasc.com> wrote:
> 
> > 
> > 
> > On Wed, 30 Jan 2013, Roy T. Fielding wrote:
> > 
> >> 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.
> > 
> > Ummm ... that interpretation applied to a conflict in a privacy setting
> > makes no sense ... a conflcit regarding privacy and/or security must
> > always be resolved with the most restrictive directive.
> > 
> 
>

Received on Thursday, 31 January 2013 03:12:50 UTC