On Wed, Jan 12, 2022 at 11:58 AM Aleksandar Lazic <[email protected]>
wrote:
> Well, looks like you want a forward proxy like squid not a reverse proxy
> like haproxy.
>
The application being load balanced is a proxy, so http_proxy is not a good
fit (and as you mention on the deprecation list), but haproxy as a load
balancer is a much better at front-ending this environment than any other
solution available.
We upgraded to 2.4 recently, and a Java application that uses these proxy
servers is what exposed this issue for us. Even if we were to use squid,
we would still run into this, as I would want to ensure that squid was
highly available for the environment, and we would hit the same code path
when going through haproxy to connect to squid.
The only option currently available in 2.4 that I am aware of is to setup
internal-only frontend/backend paths with accept-invalid-http-request
configured on those paths exclusively for Java clients to use. This is
effectively how we have worked around this for now:
listen proxy
bind :8080
mode http
option httplog
server proxy1 192.0.2.1:8080
server proxy2 192.0.2.2:8080
listen proxy-internal
bind :8081
mode http
option httplog
option accept-invalid-http-request
server proxy1 192.0.2.1:8080 track proxy/proxy1
server proxy2 192.0.2.2:8080 track proxy/proxy2
This is a viable workaround for us in the short term, but this would not be
a solution that would work for everyone. If the uri parser patches I found
in the 2.5/2.6 branches are the right ones to make haproxy more permissive
on matching the authority with the host in CONNECT requests, that will
remove the need for the parallel frontend/backends without validation
enabled. I hope to be able to have time to test a 2.4 build with those
patches included over the next few days.
