robertknight
commented
1 year ago Setting Cache-Control: no-cache in h-assets alone is not enough in our production environment because Cloudflare's Browser Cache TTL policy overrides it. The policy is currently configured to set a default TTL of 30 minutes.
The behavior we want is 30 minutes (or similar) for successful requests and no caching for failed requests. There is an option to request CF to respect origin headers rather than override them. This now works for 404 responses as the origin's Cache-Control: no-cache is propagated but we'd need to set Cache-Control ourselves for 200 responses.
If a downstream application using this package is deployed to multiple servers during a release, and session affinity / sticky sessions are not set up or fail to "stick" for some reason, then we can get a situation where the initial page load is served by a different version of the application than the subsequent asset requests. If the asset hashes changed between releases, then this package's view will return a 404.
The 404 response is currently served without any special headers, so default caching headers from eg. Cloudflare will be added. In the production h environment, this means that a request for assets with an incorrect / version-mismatched cache will get a
cache-control: 1800header added, althoughcf-cache-statusalways reports a MISS.This means:
Proper solutions here would either be to deploy the assets to a CDN ahead of application deployment, and / or ensure the downstream application has session affinity / sticky sessions set up.
It might however be worth also adding headers on the 404 response from this package to try to prevent downstream caching by the CDN or browser. At least that way once the rollout completes (usually in a couple of minutes), the problem will go away after a page reload.