Le 1/13/22 à 02:57, Aleksandar Lazic a écrit :
On 12.01.22 21:52, Andrew Anderson wrote:
On Wed, Jan 12, 2022 at 11:58 AM Aleksandar Lazic <[email protected]
<mailto:[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.
By design is HAProxy a reverse proxy to a origin server not to a forwarding
proxy which is the reason why the
CONNECT method is a invalid method.
Because of that fact I would not use "mode http" for the squid backend/servers
because of the issues you
described.
Why not "mode tcp" with proxy protocol
http://www.squid-cache.org/Doc/config/proxy_protocol_access/ if you
need the client ip.
Hi,
CONNECT method is valid and HAproxy supports it. It doesn't handle it by itself
however. It forwards it to the server.
Since the 2.4, a scheme-based normalization is performed on the requests after
the parsing but with some limitation. The target-uri must be in absolute-form.
Thus CONNECT requests are not normalized. But as said, the normalization is
performed after the H1 parsing. Idea is to sanitize the request before sending
it to the server and to simplify host-based routing configurations.
However, during H1 parsing, the authority found in the URI is validated against
the Host header. At this stage, both must be identical. Otherwise an error is
reported. "accept-invalid-http-request" option is a valid workaround in this case.
So now the question is to know if a pre-normalization must be performed during
H1 parsing or not (in addition to the one performed during the request
analysis). And if it should be extended to CONNECT requests. In practice, it is
only an issue for CONNECT requests because the absolue-form is not the common
form for URIs in H1.
--
Christopher Faulet
