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

In this case we're talking about a response with public and no-store

I've always felt relying on unknown caches to obey C-C directives as 
part of your security model is at best extremely weak.

If as a website operator you really have a problem with the possibility 
of some other user getting the content you generated for someone else 
due to some bad intermediary cache, then maybe you should be ensuring 
the URIs are different, or that the content is somehow secured.

>From testing we've done here, over 80% of C-C response headers are used 
to suppress caching.  Often in as many ways as the website author can 
think of.

To derive any real value to a customer out of running a cache, you 
basically have to flagrantly diregard and even downright overrule the 
C-C directives.  Otherwise it's not worth the cost (mainly extra request 
latency).

Very few sites actually try to promote it (e.g. Google maps).  Even 
heuristic caching is not quite enough, as there commonly is no 
Last-Modified header (about 50% of requests with no Expiry or max-age or 
s-maxage have no Last-Modified either).

IME most sites specify cache-suppressive C-C response headers in cases 
they don't really need to.  This results in clients having to maintain 
maps of sites that they ignore C-C from.

Anyway I digress.  It would be nice if there were some way to attempt to 
start to clean this up, and defining precedence of operators would be a 
big help.

Adrien

------ Original Message ------
From: "David Morris" <dwm@xpasc.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 31/01/2013 4:12:19 p.m.
Subject: 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:42:03 UTC