Topic on Manual talk:$wgCdnServers/Flow

An Nginx example would probably help more people.

To my knowledge, MediaWiki only supports Squid and Varnish purging.

Nginx supports HTTP PURGE so it should work. I'm trying to set it up right now.

OK, this is really complicated. There are two ways one could make the purging work with Nginx, but in both cases I worry that it may break something unrelated, because I would technically be lying to MediaWiki about how my infrastructure is set up.

Let me start by explaining my setup, which is very simple:

1. Nginx is the entry point for the outside world, serving static content and executing PHP code via FastCGI / PHP-FPM. (Standard Nginx setup for MediaWiki, with short/pretty URL rewriting. You can find the sample Nginx config on this wiki.)
2. The FastCGI module of Nginx supports caching responses from PHP-FPM, and I use this instead of putting Varnish in front of the server. This means static content isn't cached, only responses from PHP, but that's OK.

Following are the two methods one could use to make MW send a PURGE command to Nginx under such a setup:

1. Put 127.0.0.1 into $wgCdnServers, and set $wgInternalServer to 127.0.0.1 as well. If I understand correctly, this makes MW tell cURL to connect to "127.0.0.1", using the proxy server "127.0.0.1", and cURL interprets this to mean not using a proxy server, since the proxy and the destination are the same. So, cURL will directly send PURGE commands to 127.0.0.1:1080, and you can make Nginx handle them by adding a server block to your config that listens on port 1080.
2. Put 127.0.0.1 into $wgCdnServers, but don't touch $wgInternalServer. This way, cURL will send a CONNECT command to 127.0.0.1:1080, asking it to connect to e.g. example.org:443. You add a server block to your Nginx config listening on 1080 and acting as a forward proxy, but ignoring the host specified in the CONNECT command and just going to 127.0.0.1:1081 or whatever, where the PURGE command will go. You add yet another server block to your Nginx config listening on 1081, and handle the PURGE command there.

As you can see, both options are terrible hacks. In the first variant, if I understand the MW code correctly, you end up relying on cURL doing the right thing when the specified proxy server is the same as the actual destination. In the second variant, you have an additional layer of indirection in Nginx, though that should arguably be fine. In both variants, you're telling MW that a CDN server exists at 127.0.0.1, which is not true. While you can make Nginx handle the PURGE command on port 1080, who knows what else MW may decide to do with the information that there's supposedly a CDN server at that address?

I think we need someone with deep understanding of MW code to tell us whether there's a good way to get this working.

By the way, I don't actually understand why MW tries to use the CDN servers as a forward proxy, instead of sending them the PURGE command directly. Doesn't that defeat the entire purpose? The PURGE should go to the CDN. If MW just tries to use the CDN as a forward proxy to connect back to itself, obviously it's not going to be purging anything?!

I've since been told I should set wgInternalServer to something like "http://example.org" and that this should work fine, and indeed it seems to work well. I'm planning to document my config soon on a page titled Manual:Nginx caching (does not yet exist).