my haproxy config details are below. i am using haproxy to load balance 2 squid instances, and the http/layer 7 aware configs in haproxy trap these requests and fail them.
[root@haproxy]# haproxy -v HA-Proxy version 2.1.11-9da7aab 2021/01/08 - https://haproxy.org/ Status: stable branch - will stop receiving fixes around Q1 2021. Known bugs: http://www.haproxy.org/bugs/bugs-2.1.11.html Running on: Linux 5.11.22-100.fc32.x86_64 #1 SMP Wed May 19 18:58:25 UTC 2021 x86_64 global daemon log localhost local1 notice log-send-hostname router maxconn 1024 pidfile /var/run/haproxy.pid stats socket /var/run/haproxy.sock level admin stats maxconn 2 tune.ssl.default-dh-param 2048 #see https://mozilla.github.io/server-side-tls/ssl-config-generator/ for the below #the above now redirects to https://ssl-config.mozilla.org/ ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets defaults balance leastconn log global mode http option contstats timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s frontend proxy bind 192.168.120.1:8080 option httplog option http-keep-alive option forwardfor except 127.0.0.0/8 default_backend proxy backend proxy source 192.168.120.1 http-reuse always option http-keep-alive option httpchk GET /squid-internal-periodic/store_digest HTTP/1.1 server proxyA 192.168.88.1:3128 check inter 10000 server proxyB 192.168.88.2:3128 check inter 10000 On 1/12/22 11:58 AM, Aleksandar Lazic wrote: > > On 12.01.22 17:06, Andrew Anderson wrote: >> >> >> On Thu, Dec 30, 2021 at 10:15 PM Willy Tarreau <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Wed, Dec 29, 2021 at 12:29:11PM +0100, Aleksandar Lazic wrote: >> > > 00000 CONNECT download.eclipse.org:443 HTTP/1.1\r\n >> > > 00043 Host: download.eclipse.org\r\n >> > > 00071 User-Agent: Apache-HttpClient/4.5.10 >> (Java/11.0.13)\r\n >> > > 00124 \r\n >> >> It indeed looks like a recently fixed problem related to the >> mandatory >> comparison between the authority part of the request and the Host >> header >> field, which do not match above since only one contains a port. >> >> >> I don't know how pervasive this issue is on non-Java clients, but the >> sendCONNECTRequest() method from >> Java's HttpURLConnection API is responsible for the authority/host >> mismatch when using native Java HTTP >> support, and has been operating this way for a very long time: >> >> /** >> * send a CONNECT request for establishing a tunnel to proxy server >> */ >> private void sendCONNECTRequest() throws IOException { >> int port = url.getPort(); >> >> requests.set(0, HTTP_CONNECT + " " + connectRequestURI(url) >> + " " + httpVersion, null); >> requests.setIfNotSet("User-Agent", userAgent); >> >> String host = url.getHost(); >> if (port != -1 && port != url.getDefaultPort()) { >> host += ":" + String.valueOf(port); >> } >> requests.setIfNotSet("Host", host); >> >> The Apache-HttpClient library has a similar issue as well (as >> demonstrated above). >> >> More recent versions are applying scheme-based normalization >> which consists >> in dropping the port from the comparison when it matches the scheme >> (which is implicitly https here). >> >> >> Is there an option other than using "accept-invalid-http-request" >> available to modify this behavior on the >> haproxy side in 2.4? I have also run into this with Java 8, 11 and >> 17 clients. >> >> Are these commits what you are referring to about scheme-based >> normalization available in more recent >> versions (2.5+): >> >> https://github.com/haproxy/haproxy/commit/89c68c8117dc18a2f25999428b4bfcef83f7069e >> >> (MINOR: http: implement http uri parser) >> https://github.com/haproxy/haproxy/commit/8ac8cbfd7219b5c8060ba6d7b5c76f0ec539e978 >> >> (MINOR: http: use http uri parser for scheme) >> https://github.com/haproxy/haproxy/commit/69294b20ac03497e33c99464a0050951bdfff737 >> >> (MINOR: http: use http uri parser for authority) >> >> If so, I can pull those into my 2.4 build and see if that works >> better for Java clients. > > Well, looks like you want a forward proxy like squid not a reverse > proxy like haproxy. > https://en.wikipedia.org/wiki/HTTP_tunnel > > As you don't shared your config I assume you try to use option > http_proxy which will be deprecated. > http://cbonte.github.io/haproxy-dconv/2.5/configuration.html#4-option%20http_proxy > > >> Andrew > > Regards Alex >
