I wanted to create connecthandler for clientBoostrap that will take ByteBuffer for InboundIn and IOData for OutboundIn and HTTPClientResponse for InboundOut and HTTPServerRequestPart.
can anyone guide me on this. Thanks
Are you attempting to decrypt HTTPS traffic?
yes
In that case the answer is "this is quite complex".
Writing a transparent decrypting MITM proxy requires first writing the infrastructure required to issue TLS certificates on the fly. The way proxies like mitmproxy or Charles achieve this capability is that they first have you install a root certificate into your trust store, to which they hold the private key. They then act as an on-the-fly CA, creating new certificates for hosts as you attempt to connect through the proxy. Your system will trust these certificates (as it trusts the root), and they allow your proxy to act as a TLS man-in-the-middle.
Getting this working is substantially more complex than wiring up NIO to use these certificates, so I'd recommend starting by trying to get this on-the-fly certificate production working.
@lukasa thanks for your time let me try this part starting by trying to get this on-the-fly certificate production working. and then will get back to you.
@lukasa one more thing can i only parse https header's with query parameter at ServerBoostrap with connectHandler having
typealias InboundIn = HTTPServerRequestPart
typealias OutboundOut = HTTPServerResponsePart
by using the below link
swift-nio-examples/ConnectHandler.swift at main · apple/swift-nio-examples · GitHub
if i search https://jsonplaceholder.typicode.com/todos/1
then mentioned code print jsonplaceholder.typicode.com:443 not the full url.
without using mitm.
Thanks
That's correct. The initial request is a CONNECT request, which only identifies the host the client would like to proxy to. If you want the full URL, you have to decrypt the subsequent TLS connection.
correct me if i'm wrong:
do i need mitm for decrypt the subsequent TLS connection or i can do it without mitm this?
Yes, because the TLS connection is encrypted for the target TLS server, you can't read that, that's the point of the encryption 
So with the MITM you "fake" to the client that you are the real server, hence you can decrypt the traffic and then reinitiate the request with the real target server.