3 ms·
Client<>Proxy hop has very different characteristics than Proxy<>Server hop, so you may want to use different caching strategies for each. For example, cache o
by pornel 5y ago
Client<>Proxy hop has very different characteristics than Proxy<>Server hop, so you may want to use different caching strategies for each.
For example, cache on clients for a long time, because the network is slow and expensive there, but cache on the proxy server only for a short time, so that it updates from the server relatively often.
Or you may want a reverse: cache on clients only for a few seconds, because you can't purge clients' caches. But tell the proxy to cache forever, because you will manually purge its cache when something changes.
This was previously sort-of possible with max-age vs s-maxage, but other cache directives don't have two versions. Notably, stale-while-revalidate didn't work.
Stale-while-revalidate has different implications on each hop. On the client it means it's stale until the next page load, which may be undesirable. On a proxy that keeps getting hits all the time, it's only a slight propagation delay.
- potamic 5y ago> because you will manually purge its cache when something changes. If you're talking to the proxy separately, it's no longer a proxy right? It's as good as part of your infrastructure. As long as you're able to talk to the entity directly, is there a need to allow for something like this in the standard?
- mvolfik 5y agoI suppose this could be useful for 'public' proxies where you are able to invalidate cache with an API call, but can't create arbitrary logic for the cache
- pornel 5y agoSince HTTPS everywhere happened there are no truly public proxies any more, but you often still work with reverse proxies, load balancers, WAF middleboxes, and CDNs. A standard still helps unify things across vendors/implementations. A cacheable HTTP request is still an HTTP request, even if you use some other method to purge it later.