Comment by saltcured
3 days ago
It pains me to think about the important ones like varying on session cookie and authorization headers, and how badly some middleware can confuse things.
We generate custom content for a given authentication context. We definitely want caching at the user agent, but we want the cache keyed by the authenticated identity. Otherwise something like logging out and logging in as a different identity can produce monstrously confused results when an SPA or similar mixes some cached and some fresh responses into one page.
Cache invalidation, one of the two hard problems in computer science.
I'm sure most people here already knows the joke, but for the lucky 10,000, here's the full joke:
There are only two hard problems in computer science. Naming things, cache invalidation, and off-by-one errors.
And, for those who don't know who the lucky 10,000 are, https://xkcd.com/1053/
Wait a second, if you decided to become intermediary in the protocol then you are supposed to add value, not take away the features that already exists.
Although its not clear from the article itself, my gut feeling is that some big enough client arm twisted them to support it before they sign the contract again
Implementing the HTTP/1.1 caching mechanism at the proxy server is delightfully simple if you just ignore it entirely. But if you decide to do some caching on your own, you better implement the semantics in the way the clients and the servers expect it to be. Which is not simple at all if you're doing the caching to eke some performance improvements.