Fix Version/s: None
Component/s: Stack Documentation and UX
Currently we set Cache-Control: max-age=31536000 so that Fastly caches uploads from LTD Mason for a year on its POPs. This has the side-effect of also having browsers potentially cache documentation on the client for up to a year. In practice, browsers churn through their cache space more quickly, but I've noticed that Safari has no cap on its cache space, and therefore can hold onto pages for a long time.
The solution is to set a Surrogate-Control max age to 1 year, and have Cache-Control: max-age=0, private, must-revalidate. This will be done on LTD Keeper during the copy phase of a build into an edition (since it is reasonable for a client to cache a build forever), but then give us the flexibility to update an edition instantly.
Also discovered an issue with adapting S3 surrogate-key metadata to a proper header for Fastly.
Applied https://docs.fastly.com/guides/purging/setting-surrogate-key-headers-for-amazon-s3-origins for x-amz-surrogate-key (Fastly version #18).
This Fastly doc page gives an example of Cache-Control: no-cache, no-store, must-revalidate to force a browser not to cache content.
This Google doc page explains Cache-Control very well: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching
Based on the Google doc, I think for editions Cache-Control: no-cache is appropriate. This allows browsers to have a cache the actual content, but then ask the Fastly if the content has changed via the ETag. While this triggers HTTP requests, it at least conserves bandwidth.