Re: Collapsing private requests

HI Erik,

> On 15 Nov 2022, at 9:02 pm, Erik Witt <erik.witt@baqend.com> wrote:
> 
> Hi everyone!
> 
> I have a quick question on how to interpret the HTTP Caching spec. I have sent this question a week ago but I think it was blocked because I wasn't subscribed to the list at the time - so I hope this is not a duplicate.
> 
> To the question:
> 
> Is it allowed for a CDN to collapse requests and then send responses that are marked as private in the cache control header to different users (also including potential set-cookie headers)?
> 
> We have seen this behaviour on HTML requests in the past and were wondering if the spec forbids it.
> 
> The section we found relevant to the question were:
> * section 4 saying "A cache can use a response that is stored or storable to satisfy multiple requests, provided that it is allowed to reuse that response for the requests in question. This enables a cache to collapse requests — or combine multiple incoming requests into a single forward request upon a cache miss — thereby reducing load on the origin server and network."
> * section 5.2.2.7 about the private directive saying "The unqualified private response directive indicates that a shared cache MUST NOT store the response (i.e., the response is intended for a single user)." But at the same time "Note: This usage of the word "private" only controls where the response can be stored; it cannot ensure the privacy of the message content".
> 
> Could you help me with that question?

A spec-conformant HTTP cache that's a shared cache cannot. The note you reference isn't normative, and is pointing out the limits of 'private' a security mechanism, not placing constraints (or loosening them) on how the directive is interpreted.

That said, CDN caches sometimes deviate from spec conformance, often to improve cache hit rates for content they consider 'typical'.

 Often, they have dashboards/control panels that let this behaviour be tweaked; have you looked there?

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 21 November 2022 01:06:05 UTC