On 11/1/2018 11:24 AM, Sean Mullan wrote:
On 10/31/18 11:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need
richer information for the und
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 un
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
On 10/31/18 11:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need richer
information for the underlying TLS connections, for example the
n
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
som
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 wrote:
>
> Hi all,
>
> I think it should be possible to suppl
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
I removed the deprecation parts in the update. Here is the new webrev:
http://cr.openjdk.java.net/~xuelei/8212261/webrev.01/
And the CSR was updated accordingly.
https://bugs.openjdk.java.net/browse/JDK-8213161
Thanks,
Xuelei
On 11/1/2018 4:57 AM, Chris Hegarty wrote:
On 31 Oct 2018, a
> On 31 Oct 2018, at 20:03, Xuelei Fan wrote:
>> ...
> Yes. I had the same concern about the optional operation. However, I came
> to a different conclusion if I'm from viewpoint of these users that need to
> use this new operation.
>
> If an application have to use this new operation, for e
