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

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

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)

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)

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)

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: 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