stuartpb
commented
9 years ago I'm not sure I really agree with this, actually - caching is more of a deployment concern, which means it should live somewhere outside the codebase (controlled by a dashboard and/or a toolbelt).
I still think a standard for configuring this is right, but I think... maybe have a normative note that this should be handled as something like a layer that is tracked outside of your application (so I have a Git repo for my app that the devs use, and a Git repo for my config that ops use, and deployment layers the config over the codebase, either (high-tech) using a union or (low-tech) using cp -rf).
The spec needs mechanisms for cache control beyond just adding/setting static headers, specifically around the proxying of requests from other servers (which, when combined with load balancing mechanisms, is a sensible way to build distributed application CDN functionality).
Specifically, if I request a file from an endpoint CDN, I'm going to get a cache control header that tells me the content should be cached for 30 minutes. That's fine for the many end user agents that consume the content, but the edge servers' cache needs to be a little fresher than that, waiting no longer than, say, thirty seconds between requests.
Should maybe also be some implementor notes explaining how far to trust cache values (SHOULDs and MAYs), including why you should distrust them (ie. it might sound harmful to drop a 30-minute cache header to 30 seconds, but so long as it's controlling the behavior of the few servers that will be handling the requests by the end UAs, it's not passing the buck - it's the server doing the proxying that's going to bear the weight of the downgrade, not the one it's proxying to).
This is also an interesting point to start considering how the files and specs interact.