commit d2a09c1e0b335aab4c604189c7c38ae93131621a
parent 5e060d0bcb9af77e7b6d11acba99db6219d4f68e
Author: Daniele Sluijters <daenney@users.noreply.github.com>
Date: Sun, 11 Dec 2022 11:51:07 +0100
[docs] Caching webfinger with nginx (#1242)
This explains how nginx can be used to cache webfinger responses and
potentially serve stale responses in case GTS is down. This can be
useful to do in order to ensure webfinger keeps working even if you're
doing some maintenance.
Diffstat:
1 file changed, 72 insertions(+), 0 deletions(-)
diff --git a/docs/installation_guide/nginx.md b/docs/installation_guide/nginx.md
@@ -184,3 +184,75 @@ server {
## Extra Hardening
If you want to harden up your NGINX deployment with advanced configuration options, there are many guides online for doing so ([for example](https://beaglesecurity.com/blog/article/nginx-server-security.html)). Try to find one that's up to date. Mozilla also publishes best-practice ssl configuration [here](https://ssl-config.mozilla.org/).
+
+## Caching Webfinger
+
+It's possible to use nginx to cache the webfinger responses. This may be useful in order to ensure clients still get a response on the webfinger endpoint even if GTS is (temporarily) down.
+
+You'll need to configure two things:
+* A cache path
+* An additional `location` block for webfinger
+
+First, the cache path which needs to happen in the `http` section, usually inside your `nginx.conf`:
+
+```nginx.conf
+http {
+ ... there will be other things here ...
+ proxy_cache_path /var/cache/nginx keys_zone=ap_webfinger:10m inactive=1w;
+}
+```
+
+This configures a cache of 10MB whose entries will be kept up to one week if they're not accessed. The zone is named `ap_webfinger` but you can name it whatever you want. 10MB is a lot of cache keys, you can probably use a much smaller value on small instances.
+
+Second, actually use the cache for webfinger:
+
+```nginx.conf
+server {
+ server_name example.org;
+ location /.well-known/webfinger {
+ proxy_set_header Host $host;
+ proxy_set_header X-Forwarded-For $remote_addr;
+ proxy_set_header X-Forwarded-Proto $scheme;
+
+ proxy_cache ap_webfinger;
+ proxy_cache_background_update on;
+ proxy_cache_key $scheme://$host$uri$is_args$query_string;
+ proxy_cache_valid 200 10m;
+ proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504 http_429;
+ proxy_cache_lock on;
+ add_header X-Cache-Status $upstream_cache_status;
+
+ proxy_pass http://localhost:8080;
+ }
+
+ location / {
+ proxy_pass http://localhost:8080/;
+ proxy_set_header Host $host;
+ proxy_set_header Upgrade $http_upgrade;
+ proxy_set_header Connection "upgrade";
+ proxy_set_header X-Forwarded-For $remote_addr;
+ proxy_set_header X-Forwarded-Proto $scheme;
+ }
+ client_max_body_size 40M;
+
+ listen [::]:443 ssl ipv6only=on; # managed by Certbot
+ listen 443 ssl; # managed by Certbot
+ ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem; # managed by Certbot
+ ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem; # managed by Certbot
+ include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
+ ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
+}
+```
+
+The `proxy_pass` and `proxy_set_header` are mostly the same, but the `proxy_cache*` entries warrant some explanation:
+
+* `proxy_cache ap_webfinger` tells it to use the `ap_webfinger` cache zone we previously created. If you named it something else, you should change this value
+* `proxy_cache_background_update on` means nginx will try and refresh a cached resource that's about to expire in the background, to ensure it has a current copy on disk
+* `proxy_cache_key` is configured in such a way that it takes the query string into account for caching. So a request for `.well-known/webfinger?acct=user1@example.org` and `.well-known/webfinger?acct=user2@example.org` are not seen as the same
+* `proxy_cache_valid 200 10m;` means we only cache 200 responses from GTS and for 10 minutes. You can add additional lines of these, like `proxy_cache_valid 404 1m;` to cache 404 responses for 1 minute
+* `proxy_cache_use_stale` tells nginx it's allowed to use a stale cache entry (so older than 10 minutes) in certain cases
+* `proxy_cache_lock on` means that if a resource is not cached and there's multiple concurrent requests for them, the queries will be queued up so that only one request goes through and the rest is then answered from cache
+* `add_header X-Cache-Status $upstream_cache_status` will add an `X-Cache-Status` header to the response so you can check if things are getting cached. You can remove this.
+
+Tweaking `proxy_cache_use_stale` is how you can ensure webfinger responses are still answered even if GTS itself is down. The provided configuration will serve a stale response in case there's an error proxying to GTS, if our connection to GTS times out, if GTS returns a 5xx status code or if GTS returns 429 (Too Many Requests). The `updating` value says that we're allowed to serve a stale entry if nginx is currently in the process of refreshing its cache. Because we configured `inactive=1w` in the `proxy_cache_path` directive, nginx may serve a response up to one week old if the conditions in `proxy_cache_use_stale` are met.
+
