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.hega...@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<and...@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
