Haproxy seemingly substitutes brotli with gzip in "Accept-Encoding" header - gzip

Question

Im struggling to figure out why haproxy seemingly replaces br with gzip in "Accept-Encoding" header as request passes haproxy.
My application currently structured like this:
HAPROXY(tls termination) -> varnish -> apache
So I test like this:
curl -I --http2 -H 'Accept-Encoding: br' -I https://mysite.dev:31753?tru
So - sending single GET request to haproxy that strictly asks for brotly only (using curl)...
So that's what I would expect to see coming to varnish, but what is actually coming into varnish is these 2 requests:
HEAD request with br
GET request with gzip value instead...
I'm so confused - why are there 2 requests now? I did not configure compression in haproxy how can it be rewriting br to gzip.
Requests coming to varnish (I get this using tcpflow program):
172.030.000.035.41382-172.030.000.034.00080: HEAD /?tru HTTP/1.1
user-agent: curl/7.68.0
accept: */*
accept-encoding: br
host: mysite.dev:31753
x-client-ip: 192.168.10.103
x-forwarded-port: 31753
x-forwarded-proto: https
x-forwarded-for: 192.168.10.103
connection: close
172.030.000.034.41882-172.030.000.033.00080: GET /?tru HTTP/1.1
user-agent: curl/7.68.0
accept: */*
x-client-ip: 192.168.10.103
x-forwarded-port: 31753
x-forwarded-proto: https
X-Forwarded-For: 192.168.10.103, 172.30.0.35
host: mysite:31753
Accept-Encoding: gzip
X-Varnish: 328479
My haproxy config looks like so:
Haproxy
global
maxconn 1024
log stdout format raw local0
ssl-default-bind-options ssl-min-ver TLSv1.2
defaults
log global
option httplog
option http-server-close
mode http
option dontlognull
timeout connect 5s
timeout client 20s
timeout server 45s
frontend fe-wp-combined
mode tcp
bind *:31753
tcp-request inspect-delay 2s
tcp-request content accept if HTTP
tcp-request content accept if { req.ssl_hello_type 1 }
use_backend be-wp-recirc-http if HTTP
default_backend be-wp-recirc-https
backend be-wp-recirc-http
mode tcp
server loopback-for-http abns#wp-haproxy-http send-proxy-v2
backend be-wp-recirc-https
mode tcp
server loopback-for-https abns#wp-haproxy-https send-proxy-v2
frontend fe-wp-https
mode http
bind abns#wp-haproxy-https accept-proxy ssl crt /certs/fullkeychain.pem alpn h2,http/1.1
# whatever you need todo for HTTPS traffic
default_backend be-wp-real
frontend fe-wp-http
mode http
bind abns#wp-haproxy-http accept-proxy
# whatever you need todo for HTTP traffic
redirect scheme https code 301 if !{ ssl_fc }
backend be-wp-real
mode http
balance roundrobin
option forwardfor
# Send these request to check health
option httpchk
http-check send meth HEAD uri / ver HTTP/1.1 hdr Host haproxy.local
http-response del-header Server
http-response del-header via
server wp-backend1 proxy-varnish:80 check
http-request set-header x-client-ip %[src]
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
Please help if anyone knows what's happening here - extremely stumped.

Answer 1

nvm.upon further investigation it turned out that I was mixing up tcpflow results.
apparently it was varnish all along that was automatically encoding gzip, after I disabled it - I got br back as expected.