I tried it again with "deflate" and "identity", and in each case got back a plaintext response with no compression.
Maybe your browser doesn't send the Accept-Encoding header at all? In that case, according to the spec, "If no Accept-Encoding header field is in the request, any content coding is considered acceptable by the user agent."[0] If your browser doesn't send Accept-Encoding but still relies on a specific encoding or no encoding, it's your browser that is broken, not the server.
I will say that it was weird because at the time, I also tested loading the main page and a couple other blog posts on the site. Only this particular one, however, was an issue, and I figured it was probably an anti-hug mechanism where the site forces Brotli compression for a resource if that resource was frequently being accessed over a certain threshold.
I honestly have no idea though. It's weird. What I do know is that it wasn't just my browser - I was having a similar issue with wget, where it got back encoded Brotli data without having asked for it. (wget does support Brotli, but doesn't send an Accept-Encoding header or, it seems, decode the output unless told to specifically.) But, again, I'm not having the issue now, and as you say, not sending an Accept-Encoding header means anything goes so it's not really the same thing as how it worked on my browser.
Hmm, I got br when I dropped the header (see below). Either way, the server's behavior matches the spec, so there's something up with the client if they're seeing nonsense.
Request:
GET https://jakearchibald.com/2023/against-self-closing-tags-in-html/
Accept: text/html
Ah, you know what, IntelliJ automatically adds an Accept-Encoding header if I leave it off, I didn't realize that until just now. Curl is a better test because it doesn't try to be clever.
There's still definitely something wrong with OP's client, because the server does exactly what it's supposed to.
I ran this HTTP request (in IntelliJ's HTTP client):
And got back this response: I tried it again with "deflate" and "identity", and in each case got back a plaintext response with no compression.Maybe your browser doesn't send the Accept-Encoding header at all? In that case, according to the spec, "If no Accept-Encoding header field is in the request, any content coding is considered acceptable by the user agent."[0] If your browser doesn't send Accept-Encoding but still relies on a specific encoding or no encoding, it's your browser that is broken, not the server.
[0] https://www.rfc-editor.org/rfc/rfc9110#field.accept-encoding