Has Content-Length: volpeon.ink/_astro/_category_.DTW9tSzV.css
Doesn't have Content-Length: volpeon.ink/_astro/about.ArvwJ6Ft.css

You can verify both are precompressed by appending ".br".

@volpeon Second one sends as "transfer-encoding: chunked" for me, which means the length header can't be present with the response, the length is instead sent with each chunk.

@lnkr @forst
Wait a second, I think you didn't request any compression so Caddy serves the uncompressed file. If you add Accept-Encoding: br, the header will be gone

@irenej Not for me ​​

@lnkr Someone else said they're getting the header, too. This is so weird. I was checking with Firefox and Chromium with caching disabled, and both of them say the header is absent

@lnkr @forst
Wait a second, I think you didn't request any compression so Caddy serves the uncompressed file. If you add Accept-Encoding: br, the header will be gone

@volpeon @lnkr I think the question has to be posed differently: why does Caddy not serve a precompressed version?
On the screenshot, "live.br" is compressed on the fly and "prep.br" is the precompressed one.
Is there some sort of a rewrite rule, a regex, a wildcard that would affect this?

@forst @lnkr Wait, you're saying that Caddy is compressing the file itself even though I added a precompressed one? What the fuck

Has Content-Length: volpeon.ink/_astro/_category_.DTW9tSzV.css
Doesn't have Content-Length: volpeon.ink/_astro/about.ArvwJ6Ft.css

You can verify both are precompressed by appending ".br".

@volpeon > You can verify both are precompressed by appending ".br".

BRAZIL MENTIONED

@volpeon @lnkr Correct, that's my current hypothesis. Content-Length would be unknown at the start of the transfer, since it's compressing on the fly.