I wonder something. I was testing with Edge browser which sends Accept-Encoding: gzip, deflate, br, and I have encode zstd br gzip in my Caddyfile, why does Edge still receive gzip encoded content instead of brotli? Is it because Edge has br last in the list? I’d like Caddy to choose the encoding based on the order in Caddyfile.
I don’t have any brotli plugin installed. Can you run caddy adapt -p and show the encode handler config? It should have a prefer field that gets filled.
Basically, it should be respecting the order of encoders you list in your Caddyfile. The code is doing sorting according to “q-factor” (which your client is not setting, so that’s not relevant) then by prefer order.
Thanks! I’m aware that the brotli encoding isn’t as fast, and CPU has been less of a bottle neck than bandwidth usage for me. For example file listings compress to half the size with br compared to gzip. But this was a while ago, so I’m grateful you pointed to the C brotli version. I’ll try it!
I have changed to c-brotli and also changed the order to br, zstd, gzip. Unfortunately it still chooses gzip in both Edge and Chrome.
Looking at the logs I see that brotli is stripped when accessing the site through my works computer (even though the dev-tools in the browser says brotli). This explains why the result is gzipped. When accessing the page via my phone I am correctly getting brotli compressed content.
Thanks for the heads up on the c-brotli and the trusted_proxies!
I don’t see how, if you have a TLS connection to Caddy. The request is encrypted. If something tampered with it, it would break the connection and you would see a TLS error.
You are correct. But our company installs a certificate and so can alter/decrypt all traffic. Computers without this certificate cannot use internet at all.