In cache.c there's:
/* As per RFC7231#5.3.4, "If no Accept-Encoding field is in the request,
* any content-coding is considered acceptable by the user agent". */
if (count == 0)
encoding_bitmap = ~0;
(and even though that references RFC 7231 similar semantics are in RFC 9110)
However with brotli and zstd clients may support the encodings in
reponses, however only over HTTPS. This means for HTTP traffic the
cache (if shared between HTTPS and HTTP and with process-vary on)
could store a response in zstd or brotli but a client may not per spec
be able to decode it.
Ideally to comply with the spirit of the HTTP specs (although this is
poorly specified per e.g.
https://github.com/whatwg/fetch/issues/716#issuecomment-383553819);
haproxy's cache should take into account the protocol used and not
offer a brotli or zstd response if the request came in over plain
HTTP.
I tried to workaround this a bit with set-uri including https:// or
http:// per[1] to alter the cache key but this has some undesired side
effects like changing what the backend app sees.
Given this is poorly defined I think in some ways ignoring this makes
sense, i.e. simply delete those lines of code and treat a lack of
Accept-Encoding the same as empty (see 3bc6af41); this will mostly
affect non-browser clients. But I suspect someone probably already
relies on it working the other way around, so it likely needs a
configuration option.
David
[1]:
https://www.haproxy.com/documentation/haproxy-configuration-tutorials/proxying-essentials/http-rewrites/#set-the-uri
