Follow

Keep Up to Date with the Most Important News

By pressing the Subscribe button, you confirm that you have read and are agreeing to our Privacy Policy and Terms of Use
Contact

Replace reqirep directive in HAProxy 2.2.25

I’ve upgraded from an old version of HAProxy to the 2.2.25.
In the configuration file I have this line:

reqirep Destination:\ https(.*) Destination:\ http\\1

With 2.2.25, I get this error:

Errors found while starting haproxy
[NOTICE] 064/171311 (1035) : haproxy version is 2.2.25-50b5f5d
[ALERT] 064/171311 (1035) : parsing [/var/etc/haproxy_test/haproxy.cfg:102] : The 'reqirep' directive is not supported anymore since HAProxy 2.1. Use 'http-request replace-header' instead.
[ALERT] 064/171311 (1035) : Error(s) found in configuration file : /var/etc/haproxy_test/haproxy.cfg
[ALERT] 064/171311 (1035) : Fatal errors found in configuration. 

What is the new syntax in 2.2.25?

MEDevel.com: Open-source for Healthcare and Education

Collecting and validating open-source software for healthcare, education, enterprise, development, medical imaging, medical records, and digital pathology.

Visit Medevel

I had a look to http-request replace-header but it doesn’t work 🙁

>Solution :

The equivalent configuration would be

http-request replace-header Destination (?i)https(.*) http\1

Please see https://docs.haproxy.org/2.2/configuration.html#http-request%20replace-header for the complete documentation of the http-request replace-header rule.

Note that all http-request rules are evaluated in the strict order they are stated in the configuration file. This order may differ from the order in which the rules where evaluated before with the req* rules.

Also note that in the search regex, I used an inline modifier to turn on case-insensitive matching. This makes the query equivalent to your reqirep rule which also uses case-insensitive matching. By default, http-request replace-header matches case-sensitive (i.e. equivalent to reqrep).

Finally, the double backslash in \\1 in your original configuration is odd. I assume this is an artifact of your quoting and/or templating language. When using your actual original statement, your Destination header would be replaced with the literal http\1 value rather than inserting the remainder of the header value matched in the regex.

Add a comment

Leave a Reply

Keep Up to Date with the Most Important News

By pressing the Subscribe button, you confirm that you have read and are agreeing to our Privacy Policy and Terms of Use

Discover more from Dev solutions

Subscribe now to keep reading and get access to the full archive.

Continue reading