Re: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received

Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.01/ Integrated the fix for JDK-8208642, "Server initiated TLSv1.2 renegotiation fails if Java client allows TLSv1.3". SSLHandshake.java is updated to use negotiated version so that TLS 1.2 HelloRequest is acceptable in TLS 1.3 client s

Re: Connection timeouts in JEP 321 (HTTP Client)

Simone, > On 1 Aug 2018, at 20:20, Simone Bordet wrote: > > Hi, > > On Wed, Aug 1, 2018 at 5:10 PM Chris Hegarty wrote: >> Before trying to draft the javadoc, the semantic we want for this >> overall timeout is that it should approximately related to the observed >> time spent in send[Async].

Re: Connection timeouts in JEP 321 (HTTP Client)

Hi, On Wed, Aug 1, 2018 at 5:10 PM Chris Hegarty wrote: > Before trying to draft the javadoc, the semantic we want for this > overall timeout is that it should approximately related to the observed > time spent in send[Async]. I'm not sure I agree, especially for sendAsync(), which should setup

Re: Connection timeouts in JEP 321 (HTTP Client)

Hi, On Wed, Aug 1, 2018 at 5:01 PM Michael McMahon wrote: > I can understand that a server might respond early with an error code > like 500 before the client has finished sending a very large request body, > but I don't see how a server would likely respond early with 200. > Surely, the server h

Re: Connection timeouts in JEP 321 (HTTP Client)

Simone, Thanks for you prompt and detailed reply. Comments inline. > On 31 Jul 2018, at 22:07, Simone Bordet wrote: > > ... > I would argue that you would put this method in HttpClient and so it > is HttpClient that needs to be configured with the connectTimeout. Good suggestion. I agree, and

Re: Connection timeouts in JEP 321 (HTTP Client)

Simone, Just to clarify a couple of points below: On 31/07/2018, 22:07, Simone Bordet wrote: Hi, On Tue, Jul 31, 2018 at 9:58 PM Chris Hegarty wrote: It is unfortunate that this has come up so late the JDK 11 lifecycle, but since this has API impact, and is the right thing to do, it is cert

Priority can be set for HttpClient with HTTP/1.1

Hi, Priority is only defined for version HTTP_2 (and that's clear from the javadoc). However, it's possible to construct an instance of HttpClient with a priority value and with version HTTP_1_1 (tested with Java "9.0.1"). I feel that it will be less error prone for the users if conflicting combina