Willy, Am 19.03.2018 um 11:54 schrieb Willy Tarreau: >> This issue prevents me from submitting one domain to the HSTS preload >> list, as I need to perform a redirect on the zone's apex and that >> redirect does not include the HSTS header. > > I *suspect* that in the end we could simply add a series of "header" > statements to the redirect rules. These ones would be followed by a > log-format expression making it possible to send various elements in > these response. But if it's mainly needed for HSTS, probably that in > the end we could be fine with (at least initially) adding a single > "header" directive. We'd then have : > > http-request redirect location "/foo" header x-my-header "my-expression" >
HSTS probably is the most important one. Personally I also add the unique-id-header to the responses to be able to correlate them to my logs: > unique-id-header X-Req-ID > http-response set-header X-Req-ID %[unique-id] It would be good to have them in the redirect responses (but not really critical). As a side question: Why do I have to do unique-id-header, instead of http-request set-header for the unique request ID? And why can't I capture it with capture (request|response) header but instead have to plug into manually into the log format? This feels inconsistent. ----- I don't really like the duplication of configuration, though. This would be introducing a special case where really no special case should be needed and would require me to update headers in two places. But I'm also not deep enough in haproxy's internals to know how hard it would be treating the `redirect` like a regular backend response and applying the regular http-response logic there. Best regards Tim Düsterhus
