MediaWiki has traditionally used the Cache-Control header to control the CDN (i.e. Squid reverse proxy), then the Cache-Control header for clients has been specified in Squid configuration. Specifically, when a certain URL regex matches, the Cache-Control header is stripped out and replaced with the configured header.
This is not ideal, as noted by Gabriel in a comment in the original code. It would be better if MediaWiki specified both headers in its response, so that the URL regex and client Cache-Control header does not need to be maintained in the CDN configuration. Originally, this would have required a Squid patch, but now that we are switching to Varnish, the feature can be implemented with VCL.
Specifically, MW should send a Client-Cache-Control header which Varnish will rewrite to Cache-Control as appropriate.
- Less MediaWiki-related configuration needed in Varnish VCL.
- Consolidate the code logically part of MediaWiki actually inside MediaWiki.
- Reduce risk of accidental exposure of the internal cache headers to the outside world in case of bugs in Varnish.
- Decide on the order of the below, and/or decide whether to have MW send both for a while.
- Write VCL code to support Surrogate-Control.
- Change the Cache-Control headers sent by MediaWiki to send the s-maxage values that are meant for internal use only (require PURGE control) to not be sent as part of that header. And instead send it as a separaet Surrogate-Control header instead.