haproxy does not add headers conditionally
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I have the following config, it's under the frontend
section for tls connection and haproxy terminates https connections:
acl domain-acl-host hdr(host) -i domain.tld
rspadd X-Foo: bar if domain-acl-host
rspadd X-Baz: baz
http-response set-header X-Bar bar if domain-acl-host
use_backend backend_name if domain-acl-host
The use_backend
directive works conditionally as expected (there are multiple different domain names served, and they are chosen correctly)
But headers are not added/set to the response conditionally.
I expect 3 extra headers to be added there: X-Foo
, X-Baz
, and X-Bar
, but only X-Baz
is added:
< HTTP/1.1 302 Found
< Server: nginx
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Cache-Control: max-age=0, must-revalidate, private
< Date: Sun, 14 Oct 2018 20:25:59 GMT
< Location: https://domain.tld/somewhere/else
< X-Baz: baz
I'm sure I'm missing something trivial, but reading documentation or google did not help.
PS: it's haproxy 1.8.8
https http haproxy
add a comment |Â
up vote
1
down vote
favorite
I have the following config, it's under the frontend
section for tls connection and haproxy terminates https connections:
acl domain-acl-host hdr(host) -i domain.tld
rspadd X-Foo: bar if domain-acl-host
rspadd X-Baz: baz
http-response set-header X-Bar bar if domain-acl-host
use_backend backend_name if domain-acl-host
The use_backend
directive works conditionally as expected (there are multiple different domain names served, and they are chosen correctly)
But headers are not added/set to the response conditionally.
I expect 3 extra headers to be added there: X-Foo
, X-Baz
, and X-Bar
, but only X-Baz
is added:
< HTTP/1.1 302 Found
< Server: nginx
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Cache-Control: max-age=0, must-revalidate, private
< Date: Sun, 14 Oct 2018 20:25:59 GMT
< Location: https://domain.tld/somewhere/else
< X-Baz: baz
I'm sure I'm missing something trivial, but reading documentation or google did not help.
PS: it's haproxy 1.8.8
https http haproxy
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have the following config, it's under the frontend
section for tls connection and haproxy terminates https connections:
acl domain-acl-host hdr(host) -i domain.tld
rspadd X-Foo: bar if domain-acl-host
rspadd X-Baz: baz
http-response set-header X-Bar bar if domain-acl-host
use_backend backend_name if domain-acl-host
The use_backend
directive works conditionally as expected (there are multiple different domain names served, and they are chosen correctly)
But headers are not added/set to the response conditionally.
I expect 3 extra headers to be added there: X-Foo
, X-Baz
, and X-Bar
, but only X-Baz
is added:
< HTTP/1.1 302 Found
< Server: nginx
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Cache-Control: max-age=0, must-revalidate, private
< Date: Sun, 14 Oct 2018 20:25:59 GMT
< Location: https://domain.tld/somewhere/else
< X-Baz: baz
I'm sure I'm missing something trivial, but reading documentation or google did not help.
PS: it's haproxy 1.8.8
https http haproxy
I have the following config, it's under the frontend
section for tls connection and haproxy terminates https connections:
acl domain-acl-host hdr(host) -i domain.tld
rspadd X-Foo: bar if domain-acl-host
rspadd X-Baz: baz
http-response set-header X-Bar bar if domain-acl-host
use_backend backend_name if domain-acl-host
The use_backend
directive works conditionally as expected (there are multiple different domain names served, and they are chosen correctly)
But headers are not added/set to the response conditionally.
I expect 3 extra headers to be added there: X-Foo
, X-Baz
, and X-Bar
, but only X-Baz
is added:
< HTTP/1.1 302 Found
< Server: nginx
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Cache-Control: max-age=0, must-revalidate, private
< Date: Sun, 14 Oct 2018 20:25:59 GMT
< Location: https://domain.tld/somewhere/else
< X-Baz: baz
I'm sure I'm missing something trivial, but reading documentation or google did not help.
PS: it's haproxy 1.8.8
https http haproxy
https http haproxy
asked 5 hours ago
zerkms
2471414
2471414
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
there is no host header in the response headers, your acl never matches.
use something like this:
http-request set-var(txn.foo) req.hdr(host)
http-response set-header bar 1 if var(txn.foo) foo.bar
New contributor
txn.foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
I can confirm it works, but don't you think it's a bug? Isn'tacl
supposed to be set during request phase and survive til the end of transaction? It works fine withsni
, whilesni
is only available during the tls handshake, long before request, yet it still is possible to match against it
â zerkms
4 hours ago
1
no it's working as intended. the acl is evaluated on responses because of your use of rspadd/http-response, and on responses, the hdr fetch can't find a host header. I would think sni is a different beast because it does not change with each request or response, headers do.
â txn.foo
4 hours ago
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
there is no host header in the response headers, your acl never matches.
use something like this:
http-request set-var(txn.foo) req.hdr(host)
http-response set-header bar 1 if var(txn.foo) foo.bar
New contributor
txn.foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
I can confirm it works, but don't you think it's a bug? Isn'tacl
supposed to be set during request phase and survive til the end of transaction? It works fine withsni
, whilesni
is only available during the tls handshake, long before request, yet it still is possible to match against it
â zerkms
4 hours ago
1
no it's working as intended. the acl is evaluated on responses because of your use of rspadd/http-response, and on responses, the hdr fetch can't find a host header. I would think sni is a different beast because it does not change with each request or response, headers do.
â txn.foo
4 hours ago
add a comment |Â
up vote
2
down vote
accepted
there is no host header in the response headers, your acl never matches.
use something like this:
http-request set-var(txn.foo) req.hdr(host)
http-response set-header bar 1 if var(txn.foo) foo.bar
New contributor
txn.foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
I can confirm it works, but don't you think it's a bug? Isn'tacl
supposed to be set during request phase and survive til the end of transaction? It works fine withsni
, whilesni
is only available during the tls handshake, long before request, yet it still is possible to match against it
â zerkms
4 hours ago
1
no it's working as intended. the acl is evaluated on responses because of your use of rspadd/http-response, and on responses, the hdr fetch can't find a host header. I would think sni is a different beast because it does not change with each request or response, headers do.
â txn.foo
4 hours ago
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
there is no host header in the response headers, your acl never matches.
use something like this:
http-request set-var(txn.foo) req.hdr(host)
http-response set-header bar 1 if var(txn.foo) foo.bar
New contributor
txn.foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
there is no host header in the response headers, your acl never matches.
use something like this:
http-request set-var(txn.foo) req.hdr(host)
http-response set-header bar 1 if var(txn.foo) foo.bar
New contributor
txn.foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
txn.foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 4 hours ago
txn.foo
361
361
New contributor
txn.foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
txn.foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
txn.foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
I can confirm it works, but don't you think it's a bug? Isn'tacl
supposed to be set during request phase and survive til the end of transaction? It works fine withsni
, whilesni
is only available during the tls handshake, long before request, yet it still is possible to match against it
â zerkms
4 hours ago
1
no it's working as intended. the acl is evaluated on responses because of your use of rspadd/http-response, and on responses, the hdr fetch can't find a host header. I would think sni is a different beast because it does not change with each request or response, headers do.
â txn.foo
4 hours ago
add a comment |Â
1
I can confirm it works, but don't you think it's a bug? Isn'tacl
supposed to be set during request phase and survive til the end of transaction? It works fine withsni
, whilesni
is only available during the tls handshake, long before request, yet it still is possible to match against it
â zerkms
4 hours ago
1
no it's working as intended. the acl is evaluated on responses because of your use of rspadd/http-response, and on responses, the hdr fetch can't find a host header. I would think sni is a different beast because it does not change with each request or response, headers do.
â txn.foo
4 hours ago
1
1
I can confirm it works, but don't you think it's a bug? Isn't
acl
supposed to be set during request phase and survive til the end of transaction? It works fine with sni
, while sni
is only available during the tls handshake, long before request, yet it still is possible to match against itâ zerkms
4 hours ago
I can confirm it works, but don't you think it's a bug? Isn't
acl
supposed to be set during request phase and survive til the end of transaction? It works fine with sni
, while sni
is only available during the tls handshake, long before request, yet it still is possible to match against itâ zerkms
4 hours ago
1
1
no it's working as intended. the acl is evaluated on responses because of your use of rspadd/http-response, and on responses, the hdr fetch can't find a host header. I would think sni is a different beast because it does not change with each request or response, headers do.
â txn.foo
4 hours ago
no it's working as intended. the acl is evaluated on responses because of your use of rspadd/http-response, and on responses, the hdr fetch can't find a host header. I would think sni is a different beast because it does not change with each request or response, headers do.
â txn.foo
4 hours ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f935492%2fhaproxy-does-not-add-headers-conditionally%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password