Do not resolve unresolved address for request if the first handler in pipeline is SocksProxyHandler

Expected behavior

Some interface for handlers (for example CanConnectUnresolved) that will force Netty to not resolve unresolved addresses for requests with the first handler that implemented this interface.

Socks5ProxyHandler & Socks4ProxyHandler have support for unresolved addresses and can be marked with this interface. It’s a very good way for actual proxy usage because this way address will not be resolved in the restricted network (e.g. Russian internet 😦 ) where DNS answers can be compromised.

Actual behavior

Netty always forces address resolving before starting the request pipeline.

Steps to reproduce

Start an HTTP request to the unresolved socket address.

[lygoing]

Bootstrap bootstrap = new Bootstrap();
bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

is OK.

[amal]

@normanmaurer I’m using netty via the heavily customized AsyncHttpClient.

SOCKS proxy support was added basing on this pull request: https://github.com/AsyncHttpClient/async-http-client/pull/1466/files#diff-e8a099a4ff024fa6b7322065055df7e0R413 It’s a link to the exact lines with pipeline change for adding proxy.

The main difference was that it didn’t work for me that way. I spent much time to understand that this way domain name address was resolved in my home network, not using the proxy so my network provider returned invalid IP address instead of actual, replacing responses from name servers. SocksProxyHandler class receives an already resolved address and uses IP address instead of domain for the new connection via proxy.

All works like a charm when SocksProxyHandler classes receive not resolved socket address and use the domain name instead of IP for connection. This way proxy resolves the name itself in the normal “not limited network”.