HttpUrlConnector to support domain fronting

[Kenneth Liang]

There is this PR which added SNI support to HttpUrlConnector: #5241 . Before this PR it was possible to set the Host header value to a value that is different from the request URI host. ie:
requested endpoint: https://www.google.com/
client uses endpoint: https://www.google.com/
Host: www.amazon.com
I believe there is no SNI value set during TLS handshake before this PR, but have not checked thoroughly. The TLS handshake would validate that the server cert contains www.google.com and the request with Host: www.amazon.com is allowed.

After this PR, this is no longer possible. HttpUrlConnector will now connect using the IP address directly and use the Host header value for SNI.
requested endpoint: https://www.google.com/
client uses endpoint: https://ip-address-of-google/
Host: www.amazon.com
SNI value: www.amazon.com
The TLS handshake would validate that the server cert contains www.amazon.com and fail if it doesn't.

In most cases this is fine, but in some cases like a proxy server, we need to pass the Host header we received untouched. And in this case the host header value will be different from the requested endpoint host. We need a way to configure Jersey to support this:
requested endpoint: https://www.google.com/
client uses endpoint: https://ip-address-of-google/ or https://www.google.com/ (doesnt matter which here)
Host: www.amazon.com
SNI value: www.google.com (MAIN difference)
The TLS handshake would validate that the server cert contains www.google.com and fail if it doesn't. If successful, we can send HTTP request with Host: www.amazon.com

So overall, HttpUrlConnector needs to support domain fronting behavior where the SNI value and Host header value can be different. Currently it does not support it. Both values are the same.

[jansupol]

When the host is the same as the HTTP HOST header, the SNIHostName is not set.

The requested behaviour may be implemented by introducing the SNI_HOST_NAME property which would take precedence over the HTTP Host and would not set the actual SNIHostName in the case the host in the request would be the same as the SNI_HOST_NAME property. How does it sound?

[Kenneth Liang]

Hi jansupol. Thanks for your response. That sounds perfect. To make sure I understand. We will introduce a new property, ie: ClientProperties.SNI_HOST_NAME . Then I believe we can just use that to skip setting SNIHostName (and SNI behavior in general) in HttpUrlConnector on a per-request basis, ie:

Invocation.Builder builder = webTarget.request()
    .property(ClientProperties.SNI_HOST_NAME, "same-host-as-request");
// Request will have a Host header with a different host from the request

Yes, I think that should work and allow HttpUrlConnector to support domain fronting behavior again.