The responses are not compressed. I can confirm by not seeing Content-Encoding response header and both ‘size’ and ‘transfer size’ in firefox devtools show close values.
caddy’s file-server directive. Responses are compressed as expected
Reverse proxy to python -m http.server. Also works . Responses are compressed.
One thing I noticed is that my real application does not send ‘Content-Length’ header. Does that cause caddy to not compress response? It does send the content-type header though which is compressible (text/html)
6. Links to relevant resources:
Side Note: Documentation does not have ‘brotli’ as compression option. But I see in source code. Not sure docs need to be updated or brotli is not ready yet.
The encoder won’t operate unless we have at least 512 bytes to bother encoding, by default. Here’s where Caddy attempts to determine the content length:
It first checks if the buffered response we have is greater than the length; if it isn’t, it checks whether the supplied Content-Length meets the required length. I understand this would be useful in cases where the response is chunked but the first chunk is smaller than the minimum, in which event Caddy would trust the length reported by the upstream server instead.
So, I’d be leaning towards the issue here being that the response is too small to bother encoding.
The responses are definitely much bigger than 512 bytes. Was ~ 65Kb. From the code, it looks like the length of first write call is only considered. I will try to put some logging around and check what is happening.