HAProxy community

Vary: Accept-Encoding remove

Hi,

I’m testing this to load balance a web applications however the developers are telling me that I cannot have vary: Accept-Encoding over the headers, if I use the web application directly on it’s web server indeed I don’t have that header but passing through HAProxy I get that.

How do I disable it?

Haproxy will set the Vary: Accept-Encoding header, if it compresses the response, which is required to avoid messing up intermediate downstream caching proxies:

Also see:
https://www.mail-archive.com/haproxy@formilux.org/msg34225.html

There is no reason to disable it, other than buggy downstream HTTP user-agents. But, if you cannot live with it, then you need to disable compression.

Thanks for the response I don’t have compression enabled does it come by default?

No, that’s certainly not default.

Please provide the output of haproxy -vv as well as the complete configuration (formatted with the code tags </> above).

This is the output of the haproxy -vv

HA-Proxy version 2.0.7 2019/09/27 - https://haproxy.org/
Build options :
TARGET = linux-glibc
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered -Wno-missing-field-initializers -Wtype-limits
OPTIONS = USE_ZLIB=yes

Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER -PCRE -PCRE_JIT -PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED -REGPARM -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H -VSYSCALL +GETADDRINFO -OPENSSL -LUA +FUTEX +ACCEPT4 -MY_ACCEPT4 +ZLIB -SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS

Default settings :
bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_THREADS=64, default=2).
Built with network namespace support.
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Built with zlib version : 1.2.7
Running on zlib version : 1.2.7
Compression algorithms supported : identity(“identity”), deflate(“deflate”), raw-deflate(“deflate”), gzip(“gzip”)
Built without PCRE or PCRE2 support (using libc’s regex instead)
Encrypted password support via crypt(3): yes

Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as cannot be specified using ‘proto’ keyword)
h2 : mode=HTX side=FE|BE mux=H2
h2 : mode=HTTP side=FE mux=H2
: mode=HTX side=FE|BE mux=H1
: mode=TCP|HTTP side=FE|BE mux=PASS

Available services : none

Available filters :
[SPOE] spoe
[COMP] compression
[CACHE] cache
[TRACE] trace

I see something about the use of zlib however in my configuration I don’t have any reference to compression actually I left it very simple just to see if the header would get disabled but it didn’t here’s my config.

global
log 127.0.0.1 local2
log 127.0.0.1 local2 notice
chroot /var/lib/haproxy
stats timeout 30s
maxconn 2000
user haproxy
group haproxy
daemon

defaults
log global
option httplog
option dontlognull
option redispatch
retries 10
timeout connect 5000
timeout client 50000
timeout server 50000
timeout http-keep-alive 10s
timeout check 1000s

frontend http_front-balancer1
bind *:80
default_backend Tomcats1
mode http

backend Tomcats1
balance roundrobin
option httpchk GET /
http-check expect status 200
cookie LB_SESSION insert
default-server inter 3s fall 3 rise 2
server T1 172.20.11.135:8080 cookie t1 check
server T2 172.20.28.65:8080 cookie t2 check

listen stats
bind *:8082
stats enable
stats show-node
stats uri /stats
stats refresh 5s

In this configuration, haproxy will not add a Vary header. Make sure that there are no obsolete haproxy processes running in the background (with old configuration), this often happens as haproxy uses SO_REUSPORT, allowing the kernel to bind multiple processes to the same listening socket.

If you can guarantee that the only haproxy instance is running this specific configuration, I suggest you run curl -vv <affected-destination-URL> against haproxy and for comparison, against the backend directly. Provide the output of both and put it into code tags </> here.