With the release of 12.0.1, I tested this again and still see issues with
an endless loop in the way the HttpsServer handles this situation so I do
not believe this is the same issue as JDK-8214418.
Jay
On Mon, Feb 11, 2019 at 2:59 AM Daniel Fuchs
wrote:
> Hi Jay,
>
>
> It looks like this is JD
Hi Severin,
Yes - sorry about that - as Sean explained we had to keep
that bug report private.
However you should be able to find all the information about the
issue in the public review thread in the security-dev archive:
http://mail.openjdk.java.net/pipermail/security-dev/2018-December/019100
On 3/6/19 4:55 AM, Severin Gehwolf wrote:
On Mon, 2019-02-11 at 10:58 +0100, Daniel Fuchs wrote:
It looks like this is JDK-8214418 - which has been fixed
in 12.0.1 b03 and 13-ea b04.
Is there any reason why JDK-8214418 is not public?
"You can't view this issue"
There are internal hostnames
On Mon, 2019-02-11 at 10:58 +0100, Daniel Fuchs wrote:
> It looks like this is JDK-8214418 - which has been fixed
> in 12.0.1 b03 and 13-ea b04.
Is there any reason why JDK-8214418 is not public?
"You can't view this issue"
Thanks,
Severin
Hi Jay,
It looks like this is JDK-8214418 - which has been fixed
in 12.0.1 b03 and 13-ea b04. The issue was with the
half closed semantics of the SSL engine in TLS 1.3.
best regards,
-- daniel
On 08/02/2019 21:43, Jay Modi wrote:
Hi,
I've been doing some testing with Apache HttpClient again
Hi,
I've been doing some testing with Apache HttpClient against the
com.sun.net.httpserver.HttpsServer that is included with the JDK and came
across some interesting behavior that occurs when using TLSv1.3, but
TLSv1.2 works normally. If the client manually calls Socket#shutdownOutput
and Socket#s
