I have tried connecting the NIOSocketChannel with a tcp client to the server:
(let [[host port] (str/split uri #":")
client-channel (:aleph/channel req)]
(-> (d/let-flow [tcp-server-stream (tcp/client {:host host :port (Integer/parseInt port)})]
(s/connect (netty/source client-channel) tcp-server-stream)
(s/connect tcp-server-stream (netty/sink client-channel)))
(d/catch
(fn [_]
{:status 500})))
{:status 200})
But, when I use the proxy and run curl -v , I get this error:
* CONNECT phase completed
* CONNECT tunnel established, response 200
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
* TLSv1.3 (OUT), TLS alert, record overflow (534):
* OpenSSL/3.4.0: error:0A0000C6:SSL routines::packet length too long
* closing connection #0
Is there a way to limit the size of messages sent when using manifold.stream/connect?@ye.edward.zhijia Very few people ever used the CONNECT functionality; you're the first I know of. It's implemented, but I never personally used it. Iirc, it only works for HTTP/1 connections anyway. There was so little demand, I never added it to the HTTP/2 overhaul.
With that background out of the way, let me say that you should probably not need to do anything as low-level as using a NioSocketChannel directly. Since CONNECT is essentially a relay, your proxy can be thought of as BOTH server and client, and you should be able to use Manifold streams to accomplish all you want
E.g., receive connections like a server, but then use a client to open a connection to the destination, and forward the incoming data. The Ring spec mandates InputStreams, but those can be wrapped in Manifold streams (or use raw streams for a low overhead alternative if you're willing to clear the ByteBufs yourself). Then, use manifold.stream/connect to hook them all up. Ditto for the reverse direction.