4 ms·
> 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 pa
by 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.