Change Details

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.

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. ##### Outcome * 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. ##### Todo * [ ] 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.

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. ##### Outcome * 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. ##### Todo * [ ] 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.