You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CacheControl does not deal with Vary / secondary keys #37
If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated by a secondary key for the values of the original request's selecting header fields (Section 4.1).
Discussion of "secondary keys" (a term completely undefined in the RFC itself) tempesta-tech/tempesta#508 -- part of the issue I have with the spec is that it assumes that you are working with a cache which even provides primary and secondary keys. As The Insanity of the Vary Header says:
This isn't really a major problem for developers writing clients and servers, but it's a pain for people trying to write caches. In fact, I haven't found a private cache implementation that actually does this yet.
and
If you think the specification is bad, you should see the implementations.
So even when CacheControl tells you to do the right thing, you're still going to be hosed unless your cache implementation can deal with the ambiguity: the cache entry can be either a single response, or a map of multiple stored responses.
Activity
[-]CacheControl does not implement secondary keys[/-][+]CacheControl does not deal with Vary / secondary keys[/+]