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

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.