Hi,

On Tue, Apr 23, Christian Ruppert wrote:
> we have an older setup using nbproc >1 and having a listener for the
> initial tcp connection and one for the actual SSL/TLS, also using
> tcp mode which then goes to the actual frontend using http mode.
> Each being bound to different processes.
> So here's the test config I've used:

(Your config seems quite similar to what I tested in this thread:
https://www.mail-archive.com/[email protected]/msg32255.html)

It kind of works if you add a second bind (with proto h2) to some_frontend
and from h2test_tcp.tls use server h2 if { ssl_fc_alpn h2 }
(BUT client can (at least in theory) choose alpn h2 and speak http/1.1).

So using mode http on h2test_tcp.tls is probably safer choice.

> listen h2test_tcp
>     mode tcp
>     bind :444
>     option tcplog
>     log global
>     server socket-444-h2test unix@/run/haproxy-444-h2test.sock
> send-proxy-v2
> 
> listen h2test_tcp.tls
>     mode tcp
>     option tcplog
>     log global
>     bind unix@/run/haproxy-444-h2test.sock accept-proxy user haproxy
> group haproxy mode 600 ssl crt /etc/haproxy/ssl/h2test.pem alpn
> h2,http/1.1
>     server socket-444_2 unix@/run/haproxy-444_2-h2test.sock
> send-proxy-v2
> 
> frontend some_frontend
>     mode http
>     log global
>     bind unix@/run/haproxy-444_2-h2test.sock id 444 accept-proxy
> user haproxy group haproxy mode 600
>     bind :80
> 
>     ...

[...]

> curl says:
> # curl -k4vs 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F127.0.0.1%3A444%2F&data=02%7C01%7C%7Ca512378ae52d4457158908d6c7f5fb34%7C87879f2e73044bf2baf263e7f83f3c34%7C0%7C1%7C636916256693248226&sdata=Fw%2F21TnhE6yuJJq4dDDZf%2BdJfIVX3b6yR4nVjoD%2BkhA%3D&reserved=0
>  --http2
> *   Trying 127.0.0.1...
> * TCP_NODELAY set
> * Connected to 127.0.0.1 (127.0.0.1) port 444 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * Cipher selection:

[...]

> * Using HTTP2, server supports multi-use
> * Connection state changed (HTTP/2 confirmed)
> * Copying HTTP/2 data in stream buffer to connection buffer after
> upgrade: len=0
> * Using Stream ID: 1 (easy handle 0x56087e29b770)
> >GET / HTTP/2
> >Host: 127.0.0.1:444
> >User-Agent: curl/7.64.1
> >Accept: */*
> >
> * http2 error: Remote peer returned unexpected data while we
> expected SETTINGS frame.  Perhaps, peer does not support HTTP/2
> properly.
> * Connection #0 to host 127.0.0.1 left intact
> * Closing connection 0
> 
> Can anybody else confirm that? Tested with HAProxy 1.9.6.
> Any ideas what might be the reason? Right now, I'd guess that's a
> Problem with H/2 and those sockets on the HAProxy side.

I think the problem is that "bind unix@/run/haproxy-444_2-h2test.sock"
expects/speaks http/1.1.

-Jarno

-- 
Jarno Huuskonen

Reply via email to