Option to supply custom hostname verifier to HTTP client

[Anders Wisch]

Yes, although this is more restrictive because it means I have to have common name or subject
alternative names in the self-signed certificate for “localhost”, “localhost.localdomain”,
“127.0.0.1”, or similar so that my requests get routed to the local server. Testing hostname-based
redirects under SSL is also made difficult by the host header being on the restricted list. If
the hostname verifier used the contents of the host header instead of the URI's host, and the host
header was customizable, then a self-signed certificate with CN and SAN entries for all of the
names in question would work (provided I supplied a dummy TrustManager like you suggested).

> On Nov 1, 2018, at 11:45 AM, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> 
> You could also isolate the behavior to a specific SSLContext (and therefore HttpClient)
> by initializing the SSLContext with a dummy TrustManager (if it's only for testing).
> 
> - Michael.
> 
> On 01/11/2018, 18:09, Anders Wisch wrote:
>> Thankfully, all of my uses are for testing. To test hostname-based redirects or integration tests of
>> server code under SSL I start short-lived servers that serve self-signed certificates. Test cases
>> use HTTP clients that disable hostname verification, connect to a local address and port, and
>> sometimes vary the contents of the “Host” header. Since tests can run in parallel to speed up suite
>> execution and since other tests require secure hostname verification, it’s useful to be able to
>> isolate the behavior.
>> 
>>> On Nov 1, 2018, at 10:53 AM, Chris Hegarty<chris.hegarty at oracle.com>  wrote:
>>> 
>>> In order to evaluate this request, can you please provide
>>> use-cases for such. What “secure” server are you trying
>>> to connect to that is unwilling to identify itself in its
>>> certificate.
>>> 
>>> -Chris.
>>> 
>>>> On 1 Nov 2018, at 17:48, Anders Wisch<anders at featureshock.com>  wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I think it should be possible to supply a custom javax.net.ssl.HostnameVerifier while building a
>>>> java.net.http.HttpClient. While it is possible to disable standard hostname verification via the
>>>> system property “jdk.internal.httpclient.disableHostnameVerification”, this doesn’t allow you to
>>>> quarantine the behavior to a single HTTP client within the JVM.
>>>> 
>>>> Thanks for your consideration,
>>>> Anders Wisch
>>>> 
>>>> 
>>