Hi all, I just checked and the issue is still present in current master. Could you maybe have a look at this issue?
It smells a bit like this could potentially be connected to the issue discussed in the thread "Lua sample fetch logging ends up in response when doing http-request redirect". However, I couldn't reproduce my issue when `http-request redirect`, neither with the patch nor without so it might also be a red herring. Regards, Holger Holger Just wrote: > Hi there, > > I observed some strange behavior when trying to use a `http-response > replace-header` rule. As soon as I start using fetched samples in the > replace-fmt string, the resulting header value is garbled or empty > (depending on the HAProxy version). > > Please consider the config in the attachment of this mail (in order to > preserve newlines properly). As you can see, we add a Set-Cookie header > to the response in the backend which is altered again in the frontend. > Specifically, the configuration intends to replace the expires tag of > the cookie as set by the backend and set a new value. > > With this configuration, I observe the following headers when running a > `curl http://127.0.0.1:8000`: > > HAProxy 1.5.14 and haproxy-1.5 master: > > Set-Cookie: WeWeWeWeWeWeWeWeWeWeWeWeWeWeWeW > X-Expires: Wed, 05 Oct 2016 11:51:01 GMT > > haproxy-1.6 master and current haproxy master: > > Set-Cookie: > X-Expires: Wed, 05 Oct 2016 11:51:01 GMT > > The `http-response replace-header` rule works fine if we replace the > sample fetch with a variable like %T. In that case, the value is > properly replaced. Any use of a sample fetch results in the above > garbled output. > > The exact same behavior can be observed if a "real" backend is setting > the original Set-Cookie header instead of using the listen / backend > hack in the self-contained config I posted. > > Am I doing something wrong here or is it possible that there is an issue > with applying sample fetches here? > > > I tested with both on freshly compiles HAProxies on MacOS with `make > TARGET=generic` as well as on a HAProxy 1.5.14 with the following stats: > > HA-Proxy version 1.5.14 2015/07/02 > Copyright 2000-2015 Willy Tarreau <wi...@haproxy.org> > > Build options : > TARGET = linux2628 > CPU = generic > CC = gcc > CFLAGS = -m64 -march=x86-64 -O2 -g -fno-strict-aliasing > OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=1 > > Default settings : > maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 > > Encrypted password support via crypt(3): yes > Built with zlib version : 1.2.8 > Compression algorithms supported : identity, deflate, gzip > Built with OpenSSL version : OpenSSL 1.0.2j 26 Sep 2016 > Running on OpenSSL version : OpenSSL 1.0.2j 26 Sep 2016 > OpenSSL library supports TLS extensions : yes > OpenSSL library supports SNI : yes > OpenSSL library supports prefer-server-ciphers : yes > Built with PCRE version : 8.35 2014-04-04 > PCRE library supports JIT : no (USE_PCRE_JIT not set) > Built with transparent proxy support using: IP_TRANSPARENT > IPV6_TRANSPARENT IP_FREEBIND > > 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. > > Thanks for your help, > Holger
