Re: Long broken option http_proxy: should we kill it ?
On 08.07.21 19:44, Aleksandar Lazic wrote: On 08.07.21 18:33, Willy Tarreau wrote: Hi all, Amaury discovered that "option http_proxy" was broken. I quickly checked when it started, and it got broken with the introduction of HTX in 1.9 three years ago. It still used to work in legacy mode in 1.9 and 2.0 but 2.0 uses HTX by default and legacy disappeared from 2.1. Thus to summarize it, no single version emitted during the last 2.5 years saw it working. As such I was considering removing it from 2.5 without prior deprecation. My opinion is that something that doesn't work for 2.5 years and that triggers no single report is a sufficient indicator of non-use. We'll still need to deploy reasonable efforts to see under what conditions it can be fixed and the fix backported, of course. Does anyone object to this ? For a bit of background, this option was added 14 years ago to extract an IP address an a port from an absolute URI, rewrite it to relative and forward the request to the original IP:port, thus acting like a non-resolving proxy. Nowadays one could probably achieve the same by doing something such asthe following: http-request set-dst url_ip http-request set-dst-port url_port http-request set-uri %[path] And it could even involve the do_resolve() action to resolve names to addresses. That's why I'm in favor of not even trying to keep this one further. +1 to remove Funny part, there was a question in SO about this topic ;-) https://stackoverflow.com/questions/68321275/unable-to-implement-haproxy-as-forward-proxy-for-https Thanks, Willy
Re: Long broken option http_proxy: should we kill it ?
On 08.07.21 18:33, Willy Tarreau wrote: Hi all, Amaury discovered that "option http_proxy" was broken. I quickly checked when it started, and it got broken with the introduction of HTX in 1.9 three years ago. It still used to work in legacy mode in 1.9 and 2.0 but 2.0 uses HTX by default and legacy disappeared from 2.1. Thus to summarize it, no single version emitted during the last 2.5 years saw it working. As such I was considering removing it from 2.5 without prior deprecation. My opinion is that something that doesn't work for 2.5 years and that triggers no single report is a sufficient indicator of non-use. We'll still need to deploy reasonable efforts to see under what conditions it can be fixed and the fix backported, of course. Does anyone object to this ? For a bit of background, this option was added 14 years ago to extract an IP address an a port from an absolute URI, rewrite it to relative and forward the request to the original IP:port, thus acting like a non-resolving proxy. Nowadays one could probably achieve the same by doing something such asthe following: http-request set-dst url_ip http-request set-dst-port url_port http-request set-uri %[path] And it could even involve the do_resolve() action to resolve names to addresses. That's why I'm in favor of not even trying to keep this one further. +1 to remove Thanks, Willy
Long broken option http_proxy: should we kill it ?
Hi all, Amaury discovered that "option http_proxy" was broken. I quickly checked when it started, and it got broken with the introduction of HTX in 1.9 three years ago. It still used to work in legacy mode in 1.9 and 2.0 but 2.0 uses HTX by default and legacy disappeared from 2.1. Thus to summarize it, no single version emitted during the last 2.5 years saw it working. As such I was considering removing it from 2.5 without prior deprecation. My opinion is that something that doesn't work for 2.5 years and that triggers no single report is a sufficient indicator of non-use. We'll still need to deploy reasonable efforts to see under what conditions it can be fixed and the fix backported, of course. Does anyone object to this ? For a bit of background, this option was added 14 years ago to extract an IP address an a port from an absolute URI, rewrite it to relative and forward the request to the original IP:port, thus acting like a non-resolving proxy. Nowadays one could probably achieve the same by doing something such asthe following: http-request set-dst url_ip http-request set-dst-port url_port http-request set-uri %[path] And it could even involve the do_resolve() action to resolve names to addresses. That's why I'm in favor of not even trying to keep this one further. Thanks, Willy
