Support client SNI

[mheath]

Support client SNI

[mheath]

I hacked this together: mheath@2c2b80d and it works. I'm not sure that getting the remote address for the SslHandler from the Channel is the best/right way to do it or not.

[mp911de]

+1 for SNI. Using the channel's remote address could conflict with proxy handlers. An unresolved InetSocketAddress with the intended endpoint address (derived from a URI or similar) should work.

[mheath]

@mp911de When you talk about a 'proxy handler' are you referring to an HTTP proxy or some kind of Java proxy?

If it's a HTTP proxy, you would have to use the proxy's address in the SNI request since the client would be doing TLS with the proxy and the proxy would be doing TLS with the intended endpoint. If the client were to send the intended endpoint's address and the proxy is using SNI, the TLS negotiation would fail.

[mp911de]

Sorry for being imprecise. The HTTP proxy endpoint vs. intended endpoint was my issue which you described above.

[simonbasle]

@mheath after looking a bit more in depth at the issue with @smaldini, we don't think the approach of using the Channel's SocketAddress is the correct one.

I have put together a change that:

• captures the SocketAddress originally provided by the client (so not the resolved and actually connected address, but rather the one targeted by eg. a GET).
• adds a getSNI() method to ContextHandler which is used when calling the addSslAndLogHandlers static method. By default it returns null, which ignores SNI
• implements getSNI so that http client context implementations extract the hostname and port out of the captured SocketAddress (provided it is not null and is an InetSocketAddress), thus enabling SNI for the clients.