From chris.hegarty at oracle.com  Mon Oct  1 14:02:16 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 1 Oct 2018 15:02:16 +0100
Subject: RFR [12] 8209454: [error-prone] TypeParameterUnusedInFormals in
 jdk.net
Message-ID: <a10ffcbe-8504-a5ae-bb71-d76d30de9d6d@oracle.com>

The declaration of the implementation private method `checkValueType`,
has a misuse of generics by only using a naked type parameter as a
return type. One solution is to ensure that the return type is a subtype
of the known SocketFlow type, by passing the expected class literal.

http://cr.openjdk.java.net/~chegar/8209454.00/

-Chris.

From chris.hegarty at oracle.com  Mon Oct  1 14:08:33 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 1 Oct 2018 15:08:33 +0100
Subject: RFR [12] 8211325: test/jdk/java/net/Socket/LingerTest.java fails with
 cleaning up
Message-ID: <65d7ab87-b6cf-8fea-ac3e-9815d1b73d8d@oracle.com>

Similar to the recent test fix for 8211092 [1], this change proposes to
modify the test so that it's main method does not return until all
threads, created by the test, terminate. This is important when run in
samevm / agentvm mode.

The change avoids any potential issues where jtreg may attempt to "clean
-up" these threads ( the clean up fails quite often as the closer thread
can linger in blocking close ).

http://cr.openjdk.java.net/~chegar/8211325.00/index.html

-Chris.

P.S. I'll fix some of the unrelated indentation issue before pushing,
which have been deliberately omitted to avoid confusing the actual
changes.

[1] https://bugs.openjdk.java.net/browse/JDK-8211092

From daniel.fuchs at oracle.com  Mon Oct  1 15:38:53 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 1 Oct 2018 16:38:53 +0100
Subject: RFR [12] 8209454: [error-prone] TypeParameterUnusedInFormals in
 jdk.net
In-Reply-To: <a10ffcbe-8504-a5ae-bb71-d76d30de9d6d@oracle.com>
References: <a10ffcbe-8504-a5ae-bb71-d76d30de9d6d@oracle.com>
Message-ID: <fa6b84bf-47c1-347a-ac14-501f1c730268@oracle.com>

Hi Chris,

I believe you should get rid of the parameter U: I do not
see it's purpose in this class. I suggest simplifying into:

  <T> T checkValueType(Object value, Class<T>) { }


best regards,

-- daniel

On 01/10/2018 15:02, Chris Hegarty wrote:
> The declaration of the implementation private method `checkValueType`,
> has a misuse of generics by only using a naked type parameter as a
> return type. One solution is to ensure that the return type is a subtype
> of the known SocketFlow type, by passing the expected class literal.
> 
> http://cr.openjdk.java.net/~chegar/8209454.00/
> 
> -Chris.


From daniel.fuchs at oracle.com  Mon Oct  1 15:42:28 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 1 Oct 2018 16:42:28 +0100
Subject: RFR [12] 8211325: test/jdk/java/net/Socket/LingerTest.java fails
 with cleaning up
In-Reply-To: <65d7ab87-b6cf-8fea-ac3e-9815d1b73d8d@oracle.com>
References: <65d7ab87-b6cf-8fea-ac3e-9815d1b73d8d@oracle.com>
Message-ID: <8b36c4c6-1123-1305-2ba7-68e2ad7dc7b1@oracle.com>

Looks good to me.

Nit indentation at line 142:
  142             if (!other.connected()) {

best regards,

-- daniel

On 01/10/2018 15:08, Chris Hegarty wrote:
> Similar to the recent test fix for 8211092 [1], this change proposes to
> modify the test so that it's main method does not return until all
> threads, created by the test, terminate. This is important when run in
> samevm / agentvm mode.
> 
> The change avoids any potential issues where jtreg may attempt to "clean
> -up" these threads ( the clean up fails quite often as the closer thread
> can linger in blocking close ).
> 
> http://cr.openjdk.java.net/~chegar/8211325.00/index.html
> 
> -Chris.
> 
> P.S. I'll fix some of the unrelated indentation issue before pushing,
> which have been deliberately omitted to avoid confusing the actual
> changes.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8211092


From chris.hegarty at oracle.com  Mon Oct  1 17:08:46 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 1 Oct 2018 18:08:46 +0100
Subject: RFR [12] 8211325: test/jdk/java/net/Socket/LingerTest.java fails
 with cleaning up
In-Reply-To: <8b36c4c6-1123-1305-2ba7-68e2ad7dc7b1@oracle.com>
References: <65d7ab87-b6cf-8fea-ac3e-9815d1b73d8d@oracle.com>
 <8b36c4c6-1123-1305-2ba7-68e2ad7dc7b1@oracle.com>
Message-ID: <266699F6-93FE-4282-97C6-26FBCFB97E65@oracle.com>



> On 1 Oct 2018, at 16:42, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Looks good to me.
> 
> Nit indentation at line 142:
> 142             if (!other.connected()) {

Thanks. I?ll fix the before pushing.

-Chris.

> best regards,
> 
> -- daniel
> 
> On 01/10/2018 15:08, Chris Hegarty wrote:
>> Similar to the recent test fix for 8211092 [1], this change proposes to
>> modify the test so that it's main method does not return until all
>> threads, created by the test, terminate. This is important when run in
>> samevm / agentvm mode.
>> The change avoids any potential issues where jtreg may attempt to "clean
>> -up" these threads ( the clean up fails quite often as the closer thread
>> can linger in blocking close ).
>> http://cr.openjdk.java.net/~chegar/8211325.00/index.html
>> -Chris.
>> P.S. I'll fix some of the unrelated indentation issue before pushing,
>> which have been deliberately omitted to avoid confusing the actual
>> changes.
>> [1] https://bugs.openjdk.java.net/browse/JDK-8211092
> 


From chris.hegarty at oracle.com  Tue Oct  2 08:11:54 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 2 Oct 2018 09:11:54 +0100
Subject: RFR [12] 8209454: [error-prone] TypeParameterUnusedInFormals in
 jdk.net
In-Reply-To: <fa6b84bf-47c1-347a-ac14-501f1c730268@oracle.com>
References: <a10ffcbe-8504-a5ae-bb71-d76d30de9d6d@oracle.com>
 <fa6b84bf-47c1-347a-ac14-501f1c730268@oracle.com>
Message-ID: <80643085-129E-4EA4-868D-2B36CBC22E2E@oracle.com>


> On 1 Oct 2018, at 16:38, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Chris,
> 
> I believe you should get rid of the parameter U: I do not
> see it's purpose in this class. I suggest simplifying into:
> 
> <T> T checkValueType(Object value, Class<T>) { }

Good suggestion. So the full diff is:

--- a/src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java
+++ b/src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java
@@ -206,7 +206,7 @@
 
                 if (option == SO_FLOW_SLA) {
                     assert flowSupported;
-                    SocketFlow flow = checkValueType(value, option.type());
+                    SocketFlow flow = checkValueType(value, SocketFlow.class);
                     setFlowOption(fd, flow);
                 } else if (option == TCP_QUICKACK) {
                     setQuickAckOption(fd, (boolean) value);
@@ -254,7 +254,7 @@
     }
 
     @SuppressWarnings("unchecked")
-    private static <T> T checkValueType(Object value, Class<?> type) {
+    private static <T> T checkValueType(Object value, Class<T> type) {
         if (!type.isAssignableFrom(value.getClass())) {
             String s = "Found: " + value.getClass() + ", Expected: " + type;
             throw new IllegalArgumentException(s);


-Chris.


From daniel.fuchs at oracle.com  Tue Oct  2 08:42:22 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 2 Oct 2018 09:42:22 +0100
Subject: RFR [12] 8209454: [error-prone] TypeParameterUnusedInFormals in
 jdk.net
In-Reply-To: <80643085-129E-4EA4-868D-2B36CBC22E2E@oracle.com>
References: <a10ffcbe-8504-a5ae-bb71-d76d30de9d6d@oracle.com>
 <fa6b84bf-47c1-347a-ac14-501f1c730268@oracle.com>
 <80643085-129E-4EA4-868D-2B36CBC22E2E@oracle.com>
Message-ID: <c3011171-7e14-9f3f-cc3a-9437e94d9449@oracle.com>

Yes! Thanks chris, that looks better to me
(and less mysterious) :-)

best regards,

-- daniel

On 02/10/2018 09:11, Chris Hegarty wrote:
> 
>> On 1 Oct 2018, at 16:38, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi Chris,
>>
>> I believe you should get rid of the parameter U: I do not
>> see it's purpose in this class. I suggest simplifying into:
>>
>> <T> T checkValueType(Object value, Class<T>) { }
> 
> Good suggestion. So the full diff is:
> 
> --- a/src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java
> +++ b/src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java
> @@ -206,7 +206,7 @@
>   
>                   if (option == SO_FLOW_SLA) {
>                       assert flowSupported;
> -                    SocketFlow flow = checkValueType(value, option.type());
> +                    SocketFlow flow = checkValueType(value, SocketFlow.class);
>                       setFlowOption(fd, flow);
>                   } else if (option == TCP_QUICKACK) {
>                       setQuickAckOption(fd, (boolean) value);
> @@ -254,7 +254,7 @@
>       }
>   
>       @SuppressWarnings("unchecked")
> -    private static <T> T checkValueType(Object value, Class<?> type) {
> +    private static <T> T checkValueType(Object value, Class<T> type) {
>           if (!type.isAssignableFrom(value.getClass())) {
>               String s = "Found: " + value.getClass() + ", Expected: " + type;
>               throw new IllegalArgumentException(s);
> 
> 
> -Chris.
> 


From daniel.fuchs at oracle.com  Tue Oct  2 10:48:04 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 2 Oct 2018 11:48:04 +0100
Subject: RFR [12] 8211349: Bad HTML in {@link} for
 HttpResponse.BodyHandlers.ofPublisher
Message-ID: <bb10c1d0-0e09-e387-3994-cab9d175dd03@oracle.com>

Hi,

Please find below a doc-only fix for:

8211349: Bad HTML in {@link} for HttpResponse.BodyHandlers.ofPublisher
https://bugs.openjdk.java.net/browse/JDK-8211349

Webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8211349/webrev.00/index.html

I have looked at all occurrences @link/@linkplain in the file, and
also took the opportunity to fix some inconsistencies in the use
of @link vs @linkplain.

best regards,

-- daniel

From chris.hegarty at oracle.com  Tue Oct  2 10:52:55 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 2 Oct 2018 11:52:55 +0100
Subject: RFR [12] 8211349: Bad HTML in {@link} for
 HttpResponse.BodyHandlers.ofPublisher
In-Reply-To: <bb10c1d0-0e09-e387-3994-cab9d175dd03@oracle.com>
References: <bb10c1d0-0e09-e387-3994-cab9d175dd03@oracle.com>
Message-ID: <8D4CC823-FA17-4B27-ABC1-11F3FA781DAB@oracle.com>


> On 2 Oct 2018, at 11:48, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a doc-only fix for:
> 
> 8211349: Bad HTML in {@link} for HttpResponse.BodyHandlers.ofPublisher
> https://bugs.openjdk.java.net/browse/JDK-8211349
> 
> Webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8211349/webrev.00/index.html

Looks good.

-Chris.

From serguei.spitsyn at oracle.com  Wed Oct  3 04:50:45 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 2 Oct 2018 21:50:45 -0700
Subject: [CAUTION] RFR : 8211146 : fix problematic elif-tests after recent
 gcc warning changes Werror=undef
In-Reply-To: <9af9d8c2-2580-0f25-2881-f4d76b2596a9@oracle.com>
References: <VI1PR02MB43848F1264D70778F41C82F293150@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <3667f01e602a47a59739dfb6b73dcd5c@sap.com>
 <9af9d8c2-2580-0f25-2881-f4d76b2596a9@oracle.com>
Message-ID: <af61e9c6-59ad-eeda-f7b5-d2c4553ab135@oracle.com>

+1 (if you still need it)

Thanks,
Serguei

On 9/26/18 4:41 AM, David Holmes wrote:
> That all seems fine to me.
>
> Thanks for fixing.
>
> David
>
> On 26/09/2018 5:48 AM, Langer, Christoph wrote:
>> Hi Matthias,
>>
>> looks good (and trivial). Ccing serviceability-dev because of change 
>> in libjdwp.
>>
>> Best regards
>>
>> Christoph
>>
>> *From:*nio-dev <nio-dev-bounces at openjdk.java.net> *On Behalf Of 
>> *Baesken, Matthias
>> *Sent:* Mittwoch, 26. September 2018 11:25
>> *To:* 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 
>> net-dev <net-dev at openjdk.java.net>; nio-dev at openjdk.java.net
>> *Cc:* Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Schmidt, Lutz 
>> <lutz.schmidt at sap.com>
>> *Subject:* [CAUTION] RFR : 8211146 : fix problematic elif-tests after 
>> recent gcc warning changes Werror=undef
>>
>> Hello, please review this small build fix .
>>
>> After the recent? changes? to ?the gcc compile flags?? with 8211029?? 
>> ??,? most of our? Linux builds stopped working .
>>
>> Error :
>>
>> === Output from failing command(s) repeated here ===
>>
>> * For target support_native_java.base_libnet_DatagramPacket.o:
>>
>> In file included from 
>> /OpenJDK/8210319/jdk/src/java.base/share/native/libnet/net_util.h:31:0,
>>
>> ?????????????????from 
>> /OpenJDK/8210319/jdk/src/java.base/share/native/libnet/DatagramPacket.c:27:
>>
>> /OpenJDK/8210319/jdk/src/java.base/unix/native/libnet/net_util_md.h:50:7: 
>> error: "__solaris__" is not defined [-Werror=undef]
>>
>> #elif __solaris__
>>
>> ??????? ^
>>
>> After looking into it,? it seems? that? the 
>> jdk/src/java.base/unix/native/libnet/net_util_md.h??? compile error 
>> is only triggered on older Linux OS? (e.g. SLES11).
>>
>> Probably that?s why it was not seen at Oracle ?after? puhsing after 
>> 8211029?? .
>>
>> Some greps? showed me a number of similar problematic #elif-checks 
>> for OS, I adjusted them too .
>>
>> Bug / webrev :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8211146
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8211146.0/ 
>> <http://cr.openjdk.java.net/%7Embaesken/webrevs/8211146.0/>
>>
>> Thanks, Matthias
>>


From michael.x.mcmahon at oracle.com  Thu Oct  4 16:09:12 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 04 Oct 2018 17:09:12 +0100
Subject: RFR: 8211420: com.sun.net.httpserver.HttpServer returns Content-length
 header for 204 response code
Message-ID: <5BB63B28.5080108@oracle.com>

Could I get the following fix reviewed please?

http://cr.openjdk.java.net/~michaelm/8211420/webrev.1/index.html

Thanks,
Michael

From daniel.fuchs at oracle.com  Thu Oct  4 16:44:49 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 4 Oct 2018 17:44:49 +0100
Subject: RFR: 8211420: com.sun.net.httpserver.HttpServer returns
 Content-length header for 204 response code
In-Reply-To: <5BB63B28.5080108@oracle.com>
References: <5BB63B28.5080108@oracle.com>
Message-ID: <4f16974e-e379-9f79-e3d6-66e9ad10f9f7@oracle.com>

Hi Michael,

Impl:

  213         boolean noContentLengthHeader = false; // must not send 
Content-length is set

did you mean "... if set"?

Otherwise looks OK.

best regards,

-- daniel

On 04/10/2018 17:09, Michael McMahon wrote:
> Could I get the following fix reviewed please?
> 
> http://cr.openjdk.java.net/~michaelm/8211420/webrev.1/index.html
> 
> Thanks,
> Michael


From michael.x.mcmahon at oracle.com  Thu Oct  4 16:45:17 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 04 Oct 2018 17:45:17 +0100
Subject: RFR: 8211420: com.sun.net.httpserver.HttpServer returns
 Content-length header for 204 response code
In-Reply-To: <4f16974e-e379-9f79-e3d6-66e9ad10f9f7@oracle.com>
References: <5BB63B28.5080108@oracle.com>
 <4f16974e-e379-9f79-e3d6-66e9ad10f9f7@oracle.com>
Message-ID: <5BB6439D.6060500@oracle.com>

Daniel,

Yes, that is what was meant.

Thanks,
Michael.

On 04/10/2018, 17:44, Daniel Fuchs wrote:
> Hi Michael,
>
> Impl:
>
>  213         boolean noContentLengthHeader = false; // must not send 
> Content-length is set
>
> did you mean "... if set"?
>
> Otherwise looks OK.
>
> best regards,
>
> -- daniel
>
> On 04/10/2018 17:09, Michael McMahon wrote:
>> Could I get the following fix reviewed please?
>>
>> http://cr.openjdk.java.net/~michaelm/8211420/webrev.1/index.html
>>
>> Thanks,
>> Michael
>

From openjdk at suche.org  Thu Oct  4 17:41:05 2018
From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=)
Date: Thu, 4 Oct 2018 19:41:05 +0200
Subject: HttpClient Headers
In-Reply-To: <5B72E057.3050900@oracle.com>
References: <5B72E057.3050900@oracle.com>
Message-ID: <eb62cf2d-b341-c9f2-f14f-d5119399e289@suche.org>

Hi,

i have an question about the new HttpClient from JDK11.

Is there any good reason that the Referer header is restricted?
Because i have scenarios where the customer server expect Referer header 
in the Login sequence.
So is there any way how to set restricted headers?


Gru? Thomas

On 14.08.2018 15:59:51, Michael McMahon wrote:
> Hi,
>
> This is an important fix for 11 which addresses the problem where 
> HTTP/1.0
> responses that do not include a content-length header are not handled 
> correctly.
>
> http://cr.openjdk.java.net/~michaelm/8207966/webrev.2/index.html
>
> Thanks,
> Michael.
>

From chris.hegarty at oracle.com  Fri Oct  5 09:30:58 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 5 Oct 2018 10:30:58 +0100
Subject: RFR: 8211420: com.sun.net.httpserver.HttpServer returns
 Content-length header for 204 response code
In-Reply-To: <5BB63B28.5080108@oracle.com>
References: <5BB63B28.5080108@oracle.com>
Message-ID: <ee56bda7-7c71-d5fd-02a1-a29cf3b72e79@oracle.com>

On 04/10/18 17:09, Michael McMahon wrote:
> Could I get the following fix reviewed please?
> 
> http://cr.openjdk.java.net/~michaelm/8211420/webrev.1/index.html

Looks good. Trivially, can you update the copyright year
in the test before pushing.

-Chris

From michael.x.mcmahon at oracle.com  Fri Oct  5 10:18:16 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 05 Oct 2018 11:18:16 +0100
Subject: HttpClient Headers
In-Reply-To: <eb62cf2d-b341-c9f2-f14f-d5119399e289@suche.org>
References: <5B72E057.3050900@oracle.com>
 <eb62cf2d-b341-c9f2-f14f-d5119399e289@suche.org>
Message-ID: <5BB73A68.2000809@oracle.com>

Hi Thomas,

Yes, I just looked at RFC7231 (section 5.5.2) and while there are 
security implications
of usage of the 'Referer' header, the HTTP client library does not have 
the relevant context
to decide whether it should be set or not. My view is that this is the 
responsibility of
the calling code. We will probably do a review of all of these 
restricted headers and
then propose a change to this area.

Thanks,

Michael.

On 04/10/2018, 18:41, Thomas Lu?nig wrote:
> Hi,
>
> i have an question about the new HttpClient from JDK11.
>
> Is there any good reason that the Referer header is restricted?
> Because i have scenarios where the customer server expect Referer 
> header in the Login sequence.
> So is there any way how to set restricted headers?
>
>
> Gru? Thomas
>
> On 14.08.2018 15:59:51, Michael McMahon wrote:
>> Hi,
>>
>> This is an important fix for 11 which addresses the problem where 
>> HTTP/1.0
>> responses that do not include a content-length header are not handled 
>> correctly.
>>
>> http://cr.openjdk.java.net/~michaelm/8207966/webrev.2/index.html
>>
>> Thanks,
>> Michael.
>>

From chris.hegarty at oracle.com  Tue Oct  9 11:03:41 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 9 Oct 2018 12:03:41 +0100
Subject: RFR [12] 8211902: broken link in java.net.http.WebSocket.Builder
Message-ID: <777ABB79-3326-4EA8-8438-546BDA7A3C35@oracle.com>

Trivially, this link should refer to HttpClient, rather than HttpRequest.

--- a/src/java.net.http/share/classes/java/net/http/WebSocket.java
+++ b/src/java.net.http/share/classes/java/net/http/WebSocket.java
@@ -197,7 +197,7 @@
          * <li> {@link SecurityException} -
          *          if a security manager has been installed and it denies
          *          {@link java.net.URLPermission access} to {@code uri}.
-         *          <a href="HttpRequest.html#securitychecks">Security checks</a>
+         *          <a href="HttpClient.html#securitychecks">Security checks</a>
          *          contains more information relating to the security context
          *          in which the the listener is invoked.
          * <li> {@link IllegalArgumentException} -

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181009/4e0e4ec7/attachment.html>

From Alan.Bateman at oracle.com  Tue Oct  9 11:09:22 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 9 Oct 2018 12:09:22 +0100
Subject: RFR [12] 8211902: broken link in java.net.http.WebSocket.Builder
In-Reply-To: <777ABB79-3326-4EA8-8438-546BDA7A3C35@oracle.com>
References: <777ABB79-3326-4EA8-8438-546BDA7A3C35@oracle.com>
Message-ID: <2dd8c0bd-8f31-c1a0-ad64-eeabb76bc795@oracle.com>



On 09/10/2018 12:03, Chris Hegarty wrote:
> Trivially, this link should refer to HttpClient, rather than HttpRequest.
>
> --- a/src/java.net.http/share/classes/java/net/http/WebSocket.java
> +++ b/src/java.net.http/share/classes/java/net/http/WebSocket.java
> @@ -197,7 +197,7 @@
> ? ? ? ? * <li> {@link SecurityException} -
> ? ? ? ? *? ? ? ? ? if a security manager has been installed and it denies
> ? ? ? ? *? ? ? ? ? {@link java.net.URLPermission access} to {@code uri}.
> - ? ? ? ? *? ? ? ? ? <a 
> href="HttpRequest.html#securitychecks">Security checks</a>
> + ? ? ? ? *? ? ? ? ? <a href="HttpClient.html#securitychecks">Security 
> checks</a>
> ? ? ? ? *? ? ? ? ? contains more information relating to the security 
> context
> ? ? ? ? *? ? ? ? ? in which the the listener is invoked.
> ? ? ? ? * <li> {@link IllegalArgumentException} -
>
Looks good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181009/444bf39b/attachment.html>

From daniel.fuchs at oracle.com  Tue Oct  9 11:37:52 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 9 Oct 2018 12:37:52 +0100
Subject: RFR [12] 8211902: broken link in java.net.http.WebSocket.Builder
In-Reply-To: <777ABB79-3326-4EA8-8438-546BDA7A3C35@oracle.com>
References: <777ABB79-3326-4EA8-8438-546BDA7A3C35@oracle.com>
Message-ID: <fb320332-4101-461e-38cc-437ef3a9392e@oracle.com>

Hi Chris,

Looks good but maybe you could fix "the the" at
the same time.

On 09/10/2018 12:03, Chris Hegarty wrote:
>  ? ? ? ? ? *? ? ? ? ? in which the the listener is invoked.

cheers,

-- daniel


From chris.hegarty at oracle.com  Tue Oct  9 11:38:04 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 9 Oct 2018 12:38:04 +0100
Subject: RFR [12] 8211902: broken link in java.net.http.WebSocket.Builder
In-Reply-To: <fb320332-4101-461e-38cc-437ef3a9392e@oracle.com>
References: <777ABB79-3326-4EA8-8438-546BDA7A3C35@oracle.com>
 <fb320332-4101-461e-38cc-437ef3a9392e@oracle.com>
Message-ID: <0C811984-B5BE-470B-B5C1-8CFB13E664A6@oracle.com>


> On 9 Oct 2018, at 12:37, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Chris,
> 
> Looks good but maybe you could fix "the the" at
> the same time.

Argh! yes, of course. I?ll fix this before pushing.

-Chris.


From chris.hegarty at oracle.com  Tue Oct  9 13:10:04 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 9 Oct 2018 14:10:04 +0100
Subject: RFR [12] 8211927: Add additional diagnostic information to
 java/net/BindException/Test.java
Message-ID: <251AF5D9-AC77-46FD-8C28-2656DE8FB28A@oracle.com>

This test has been failing intermittently for a long time. It is difficult
to diagnose the cause of the failure, as the test output doesn?t
provide much information. Time to add some diagnostic output.

--- a/test/jdk/java/net/BindException/Test.java
+++ b/test/jdk/java/net/BindException/Test.java
@@ -26,9 +26,15 @@
  * @bug 4417734
  * @key intermittent
  * @summary Test that we get a BindException in all expected combinations
+ * @library /test/lib
+ * @build jdk.test.lib.NetworkConfiguration
+ *        jdk.test.lib.Platform
+ * @run main Test -d
  */
+
 import java.net.*;
 import java.util.Enumeration;
+import jdk.test.lib.NetworkConfiguration;
 
 public class Test {
 
@@ -106,6 +112,7 @@
 
         } catch (BindException be) {
             gotBindException = true;
+            failed_exc = be;
         } catch (Exception e) {
             failed = true;
             failed_exc = e;
@@ -152,6 +159,7 @@
             if (!failed) {
                 if (gotBindException) {
                     System.out.println("Got expected BindException - test passed!");
+                    failed_exc.printStackTrace(System.out);
                 } else {
                     System.out.println("No BindException as expected - test passed!");
                 }
@@ -160,6 +168,7 @@
         }
         if (gotBindException) {
             System.out.println("BindException unexpected - test failed!!!");
+            failed_exc.printStackTrace(System.out);
         } else {
             System.out.println("No bind failure as expected - test failed!!!");
         }
@@ -206,6 +215,11 @@
          */
         InetAddress addrs[] = { ia4_this, ia6_this };
 
+        if (!silent) {
+            System.out.println("Using ia4_this:" + ia4_this);
+            System.out.println("Using ia6_this:" + ia6_this);
+        }
+
         Object tests[][] = getTestCombinations();
 
         for (int i=0; i<tests.length; i++) {
@@ -227,6 +241,9 @@
         System.out.println(count + " test(s) executed. " + failures + " failure(s).");
 
         if (failures > 0) {
+            System.err.println("********************************");
+            NetworkConfiguration.printSystemConfiguration(System.err);
+            System.out.println("********************************");
             throw new Exception(failures + " tests(s) failed - see log");
         }
     }


-Chris.

From daniel.fuchs at oracle.com  Tue Oct  9 13:39:35 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 9 Oct 2018 14:39:35 +0100
Subject: RFR [12] 8211927: Add additional diagnostic information to
 java/net/BindException/Test.java
In-Reply-To: <251AF5D9-AC77-46FD-8C28-2656DE8FB28A@oracle.com>
References: <251AF5D9-AC77-46FD-8C28-2656DE8FB28A@oracle.com>
Message-ID: <d20a36c2-cd43-1eb6-ae71-bd2a26faedfb@oracle.com>

Hi Chris,

If that works with jtreg, then looks good to me :-)

best regards,

-- daniel

On 09/10/2018 14:10, Chris Hegarty wrote:
> This test has been failing intermittently for a long time. It is difficult
> to diagnose the cause of the failure, as the test output doesn?t
> provide much information. Time to add some diagnostic output.
> 
> --- a/test/jdk/java/net/BindException/Test.java
> +++ b/test/jdk/java/net/BindException/Test.java
> @@ -26,9 +26,15 @@
>    * @bug 4417734
>    * @key intermittent
>    * @summary Test that we get a BindException in all expected combinations
> + * @library /test/lib
> + * @build jdk.test.lib.NetworkConfiguration
> + *        jdk.test.lib.Platform
> + * @run main Test -d
>    */
> +
>   import java.net.*;
>   import java.util.Enumeration;
> +import jdk.test.lib.NetworkConfiguration;
>   
>   public class Test {
>   
> @@ -106,6 +112,7 @@
>   
>           } catch (BindException be) {
>               gotBindException = true;
> +            failed_exc = be;
>           } catch (Exception e) {
>               failed = true;
>               failed_exc = e;
> @@ -152,6 +159,7 @@
>               if (!failed) {
>                   if (gotBindException) {
>                       System.out.println("Got expected BindException - test passed!");
> +                    failed_exc.printStackTrace(System.out);
>                   } else {
>                       System.out.println("No BindException as expected - test passed!");
>                   }
> @@ -160,6 +168,7 @@
>           }
>           if (gotBindException) {
>               System.out.println("BindException unexpected - test failed!!!");
> +            failed_exc.printStackTrace(System.out);
>           } else {
>               System.out.println("No bind failure as expected - test failed!!!");
>           }
> @@ -206,6 +215,11 @@
>            */
>           InetAddress addrs[] = { ia4_this, ia6_this };
>   
> +        if (!silent) {
> +            System.out.println("Using ia4_this:" + ia4_this);
> +            System.out.println("Using ia6_this:" + ia6_this);
> +        }
> +
>           Object tests[][] = getTestCombinations();
>   
>           for (int i=0; i<tests.length; i++) {
> @@ -227,6 +241,9 @@
>           System.out.println(count + " test(s) executed. " + failures + " failure(s).");
>   
>           if (failures > 0) {
> +            System.err.println("********************************");
> +            NetworkConfiguration.printSystemConfiguration(System.err);
> +            System.out.println("********************************");
>               throw new Exception(failures + " tests(s) failed - see log");
>           }
>       }
> 
> 
> -Chris.
> 


From pavel.rappo at oracle.com  Wed Oct 10 11:46:53 2018
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 10 Oct 2018 12:46:53 +0100
Subject: RFR [12] 8212000: Verify exported symbols in java.base (libnet,
 libnio/ch)
Message-ID: <AF12EB04-3307-4F6C-AB0A-5C98A97BC183@oracle.com>

Hello,

Please review the following change:

  http://cr.openjdk.java.net/~prappo/8212000/webrev.00/8212000/

This is a clean-up kind of change. It seals unnecessarily exported functions
from libnet and libnio, and also removes an unused declaration from libnet. 
This change has been built and tested on all supported platforms.

Thanks,
-Pavel


From Alan.Bateman at oracle.com  Wed Oct 10 13:04:51 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 10 Oct 2018 14:04:51 +0100
Subject: RFR [12] 8212000: Verify exported symbols in java.base (libnet,
 libnio/ch)
In-Reply-To: <AF12EB04-3307-4F6C-AB0A-5C98A97BC183@oracle.com>
References: <AF12EB04-3307-4F6C-AB0A-5C98A97BC183@oracle.com>
Message-ID: <fe0a678d-4e2c-fc67-1bd5-431be4f8db50@oracle.com>

On 10/10/2018 12:46, Pavel Rappo wrote:
> Hello,
>
> Please review the following change:
>
>    http://cr.openjdk.java.net/~prappo/8212000/webrev.00/8212000/
>
> This is a clean-up kind of change. It seals unnecessarily exported functions
> from libnet and libnio, and also removes an unused declaration from libnet.
> This change has been built and tested on all supported platforms.
>
I suspect handleSocketError was exported at some point for SCTP but 
libsctp has its own implementation now. So I think the changes look 
okay, assuming you've built and tested all platforms.

-Alan

From vyom.tewari at oracle.com  Wed Oct 10 13:16:11 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Wed, 10 Oct 2018 18:46:11 +0530
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
Message-ID: <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>

Hi All,

Please provide your review comments on below fix.

Thanks,

Vyom


On Friday 27 October 2017 11:31 AM, vyom tewari wrote:
>
>
>
> On Thursday 26 October 2017 03:14 PM, Bernd Eckenfels wrote:
>> What is currently returned at the end of a stream? This looks like a 
>> dangerous thing to do, if a existing implementation only
> Currently it returns 0 at end of stream and? same as after change. As 
> David pointed out that ultimately it delegates on to "ioctl", i 
> checked the doc(http://man7.org/linux/man-pages/man4/tty_ioctl.4.html) 
> and did not found anything which tells about eof.
>
> What i found out, setting eof at socketinputstream there is no effect 
> on native? "ioctl" call. I set the "eof"? and 
> SocketInputStream.available() return 0.
>
> Let's wait for other people opinions.
>
> Note: you have to shutdown the SocketInputstream to set "eof", i am 
> not sure if there is any other way to set "eof" for SocketInputStream.
>
> Thanks,
> Vyom
>
>> read when something is available it might never detect that it 
>> reached EOF.
>>
>> Gruss
>> Bernd
>> -- 
>> http://bernd.eckenfels.net
>> ------------------------------------------------------------------------
>> *From:* net-dev <net-dev-bounces at openjdk.java.net> on behalf of vyom 
>> tewari <vyom.tewari at oracle.com>
>> *Sent:* Thursday, October 26, 2017 11:26:15 AM
>> *To:* OpenJDK Network Dev list
>> *Subject:* RFR: 8189366: SocketInputStream.available() should check 
>> for eof
>> Hi All,
>>
>> Please review the simple change below.
>>
>> Webrev?? : 
>> http://cr.openjdk.java.net/~vtewari/8189366/webrev0.0/index.html 
>> <http://cr.openjdk.java.net/%7Evtewari/8189366/webrev0.0/index.html>
>>
>> BugId????? : https://bugs.openjdk.java.net/browse/JDK-8189366
>>
>>
>> Currently SocketInputStream.available() does not check for "eof" and
>> simply delegate to the impl even when "eof" reached. I put a check? to
>> return 0 if "eof" is already reached.
>>
>> Thanks,
>>
>> Vyom
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181010/53223098/attachment.html>

From chris.hegarty at oracle.com  Wed Oct 10 13:20:56 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 10 Oct 2018 14:20:56 +0100
Subject: RFR [12] 8212000: Verify exported symbols in java.base (libnet,
 libnio/ch)
In-Reply-To: <AF12EB04-3307-4F6C-AB0A-5C98A97BC183@oracle.com>
References: <AF12EB04-3307-4F6C-AB0A-5C98A97BC183@oracle.com>
Message-ID: <9e7ec000-b3e9-066c-6ebb-313cf53de4b2@oracle.com>

On 10/10/18 12:46, Pavel Rappo wrote:
> Hello,
> 
> Please review the following change:
> 
>    http://cr.openjdk.java.net/~prappo/8212000/webrev.00/8212000/

This looks ok to me.

-Chris.

From chris.hegarty at oracle.com  Wed Oct 10 16:20:47 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 10 Oct 2018 17:20:47 +0100
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
 <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
Message-ID: <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>

Vyom,

On 10/10/18 14:16, vyom tewari wrote:
> Hi All,
> 
> Please provide your review comments on below fix.
> 
> Thanks,
> 
> Vyom
> 
> 
> On Friday 27 October 2017 11:31 AM, vyom tewari wrote:

Wow, is it really almost a year since this was first
discussed!

>>  ...
>>> http://cr.openjdk.java.net/~vtewari/8189366/webrev0.0/index.html 

To satisfy myself, I put together a test, ran it through
Oracle's build and test infra, both with and without your
proposed changes, and it passes ok. This should give more
confidence that there is no inadvertant behavior change
resulting from your changes.

http://cr.openjdk.java.net/~chegar/8189366.test/

Can you please include this test as part of your push?

Thanks,
-Chris.

P.S. The test amends an existing test with additional
coverage, without interfering too much with the original
test.

From vyom.tewari at oracle.com  Thu Oct 11 08:03:26 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Thu, 11 Oct 2018 13:33:26 +0530
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
 <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
 <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>
Message-ID: <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>

Hi Chris,

Thanks for review, please find the updated 
webrev(http://cr.openjdk.java.net/~vtewari/8189366/webrev0.1/index.html) 
where i included the test.

Thanks,

Vyom


On Wednesday 10 October 2018 09:50 PM, Chris Hegarty wrote:
> Vyom,
>
> On 10/10/18 14:16, vyom tewari wrote:
>> Hi All,
>>
>> Please provide your review comments on below fix.
>>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Friday 27 October 2017 11:31 AM, vyom tewari wrote:
>
> Wow, is it really almost a year since this was first
> discussed!
>
>>> ?...
>>>> http://cr.openjdk.java.net/~vtewari/8189366/webrev0.0/index.html 
>
> To satisfy myself, I put together a test, ran it through
> Oracle's build and test infra, both with and without your
> proposed changes, and it passes ok. This should give more
> confidence that there is no inadvertant behavior change
> resulting from your changes.
>
> http://cr.openjdk.java.net/~chegar/8189366.test/
>
> Can you please include this test as part of your push?
>
> Thanks,
> -Chris.
>
> P.S. The test amends an existing test with additional
> coverage, without interfering too much with the original
> test.


From xu.y.yin at oracle.com  Thu Oct 11 08:45:35 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Thu, 11 Oct 2018 16:45:35 +0800
Subject: [12] RFR 8187522: sun/net/ftp/FtpURLConnectionLeak.Java timed out
Message-ID: <93E0BD42-28C5-4702-B0C8-C445FCC4B259@oracle.com>

Please review below small change to fix test sun/net/ftp/FtpURLConnectionLeak.Java, thanks

Besides the original timeout issue, looks like the test not working as expected even the results is pass. Per test description, we expect FileNotFoundException and then verify connection closed, but look through recent test run log, it?s actually got ?sun.net.ftp.FtpLoginException: Invalid username/password? and this exception been caught in IOException block coincidentally, so the test result is pass, but it never hit FileNotFoundException. The fix change will remove IOException catch block and close server socket in close() of try-with-resouce to avoid possible invalid exception catch and connection issue, also ftp 220 response message was modified to allow FtpClient working correctly (I leave the corrupted message style as it is since looks like it will be used to test JDK-8151586)

bug: https://bugs.openjdk.java.net/browse/JDK-8187522
webrev: http://cr.openjdk.java.net/~xyin/8187522/webrev.00/

Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181011/339d007c/attachment.html>

From chris.hegarty at oracle.com  Thu Oct 11 11:00:10 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 11 Oct 2018 12:00:10 +0100
Subject: [12] RFR 8187522: sun/net/ftp/FtpURLConnectionLeak.Java timed out
In-Reply-To: <93E0BD42-28C5-4702-B0C8-C445FCC4B259@oracle.com>
References: <93E0BD42-28C5-4702-B0C8-C445FCC4B259@oracle.com>
Message-ID: <8CE52990-91B4-43DB-8F57-7AB661EC0F0F@oracle.com>

Chris Y,

> On 11 Oct 2018, at 09:45, Chris Yin <xu.y.yin at oracle.com> wrote:
> 
> Please review below small change to fix test sun/net/ftp/FtpURLConnectionLeak.Java, thanks
> 
> Besides the original timeout issue, looks like the test not working as expected even the results is pass. Per test description, we expect FileNotFoundException and then verify connection closed, but look through recent test run log, it?s actually got ?sun.net.ftp.FtpLoginException: Invalid username/password? and this exception been caught in IOException block coincidentally, so the test result is pass, but it never hit FileNotFoundException. The fix change will remove IOException catch block and close server socket in close() of try-with-resouce to avoid possible invalid exception catch and connection issue, also ftp 220 response message was modified to allow FtpClient working correctly (I leave the corrupted message style as it is since looks like it will be used to test JDK-8151586)
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8187522 <https://bugs.openjdk.java.net/browse/JDK-8187522>
> webrev: http://cr.openjdk.java.net/~xyin/8187522/webrev.00/

I think this is good.

The `dash` character in FtpCommandHandler is subtle. I kinda
regret allowing that change, rather than creating a separate
standalone test for 8151586. It just confusing and overloads
the test infra. It might ok at this point, but a comment would
be good.

-Chris. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181011/ab505fc6/attachment.html>

From vyom.tewari at oracle.com  Thu Oct 11 11:02:46 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Thu, 11 Oct 2018 16:32:46 +0530
Subject: [12] RFR 8187522: sun/net/ftp/FtpURLConnectionLeak.Java timed out
In-Reply-To: <93E0BD42-28C5-4702-B0C8-C445FCC4B259@oracle.com>
References: <93E0BD42-28C5-4702-B0C8-C445FCC4B259@oracle.com>
Message-ID: <8df34446-6555-4e8b-a8df-18c357c2bc73@oracle.com>



On Thursday 11 October 2018 02:15 PM, Chris Yin wrote:
> Please review below small change to fix test 
> sun/net/ftp/FtpURLConnectionLeak.Java, thanks
>
> Besides the original timeout issue, looks like the test not working as 
> expected even the results is pass. Per test description, we expect 
> FileNotFoundException and then verify connection closed, but look 
> through recent test run log, it?s actually got 
> ?sun.net.ftp.FtpLoginException: Invalid username/password? and this 
> exception been caught in IOException block coincidentally, so the test 
> result is pass, but it never hit?FileNotFoundException. The fix change 
> will remove IOException catch block and close server socket in close() 
> of try-with-resouce to avoid possible invalid exception catch and 
> connection issue, also ftp 220 response message was modified to allow 
> FtpClient working correctly (I leave the corrupted message style as it 
> is since looks like it will be used to test JDK-8151586)
you are right, corrupted message style is intentional. Your code changes 
looks good to me but i am not able to understand 
"FtpCommandHandler.java" changes.

 ?I can see that you inserted one "-" , is it intentional ?

Thanks,
Vyom
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8187522
> webrev:?http://cr.openjdk.java.net/~xyin/8187522/webrev.00/
>
> Regards,
> Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181011/84336451/attachment.html>

From chris.hegarty at oracle.com  Thu Oct 11 11:08:36 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 11 Oct 2018 12:08:36 +0100
Subject: [12] RFR 8187522: sun/net/ftp/FtpURLConnectionLeak.Java timed out
In-Reply-To: <8df34446-6555-4e8b-a8df-18c357c2bc73@oracle.com>
References: <93E0BD42-28C5-4702-B0C8-C445FCC4B259@oracle.com>
 <8df34446-6555-4e8b-a8df-18c357c2bc73@oracle.com>
Message-ID: <89B8819F-E65E-4703-AD22-21768CF906A9@oracle.com>



> On 11 Oct 2018, at 12:02, vyom tewari <vyom.tewari at oracle.com> wrote:
> On Thursday 11 October 2018 02:15 PM, Chris Yin wrote:
>> Please review below small change to fix test sun/net/ftp/FtpURLConnectionLeak.Java, thanks
>> 
>> Besides the original timeout issue, looks like the test not working as expected even the results is pass. Per test description, we expect FileNotFoundException and then verify connection closed, but look through recent test run log, it?s actually got ?sun.net.ftp.FtpLoginException: Invalid username/password? and this exception been caught in IOException block coincidentally, so the test result is pass, but it never hit FileNotFoundException. The fix change will remove IOException catch block and close server socket in close() of try-with-resouce to avoid possible invalid exception catch and connection issue, also ftp 220 response message was modified to allow FtpClient working correctly (I leave the corrupted message style as it is since looks like it will be used to test JDK-8151586)
> you are right, corrupted message style is intentional. Your code changes looks good to me but i am not able to understand "FtpCommandHandler.java" changes.
> 
>  I can see that you inserted one "-" , is it intentional ?

If the 4th char is a dash, then the implementation ( for
what it?s worth ) thinks that it has seen multi-line reply
`###-` sequence.

It needs a comment, or maybe revert prior to 8151586.
And a separate specific test added for 8151586.

-Chris.



> Thanks,
> Vyom
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8187522 <https://bugs.openjdk.java.net/browse/JDK-8187522>
>> webrev: http://cr.openjdk.java.net/~xyin/8187522/webrev.00/ <http://cr.openjdk.java.net/~xyin/8187522/webrev.00/>
>> 
>> Regards,
>> Chris
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181011/d2e40de0/attachment-0001.html>

From michael.x.mcmahon at oracle.com  Thu Oct 11 12:28:08 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 11 Oct 2018 13:28:08 +0100
Subject: RFR [12]: 8203850: java.net.http HTTP client should allow specifying
 Origin and Referer headers
Message-ID: <5BBF41D8.2040302@oracle.com>

Could I get the following fix reviewed please?

http://cr.openjdk.java.net/~michaelm/8203850/webrev.1/

Thanks,

Michael



From daniel.fuchs at oracle.com  Thu Oct 11 12:58:02 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 11 Oct 2018 13:58:02 +0100
Subject: RFR [12]: 8203850: java.net.http HTTP client should allow
 specifying Origin and Referer headers
In-Reply-To: <5BBF41D8.2040302@oracle.com>
References: <5BBF41D8.2040302@oracle.com>
Message-ID: <812fc5dd-ea90-ac01-011a-3f579cd6bdad@oracle.com>

Looks good to me Michael.

You should be able to easily add new test cases for Origin and
Referer to test/jdk/java/net/SpecialHeadersTest.java too.

best regards,

-- daniel

On 11/10/2018 13:28, Michael McMahon wrote:
> Could I get the following fix reviewed please?
> 
> http://cr.openjdk.java.net/~michaelm/8203850/webrev.1/
> 
> Thanks,
> 
> Michael
> 
> 


From chris.hegarty at oracle.com  Thu Oct 11 13:53:27 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 11 Oct 2018 14:53:27 +0100
Subject: RFR [12]: 8203850: java.net.http HTTP client should allow
 specifying Origin and Referer headers
In-Reply-To: <812fc5dd-ea90-ac01-011a-3f579cd6bdad@oracle.com>
References: <5BBF41D8.2040302@oracle.com>
 <812fc5dd-ea90-ac01-011a-3f579cd6bdad@oracle.com>
Message-ID: <0F738053-06E3-4AAB-AA7F-506C2F794169@oracle.com>



> On 11 Oct 2018, at 13:58, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Looks good to me Michael.
> 
> You should be able to easily add new test cases for Origin and
> Referer to test/jdk/java/net/SpecialHeadersTest.java too.

+1

-Chris.

From chris.hegarty at oracle.com  Thu Oct 11 15:42:38 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 11 Oct 2018 16:42:38 +0100
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
 <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
 <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>
 <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>
Message-ID: <ADD63D2B-6AC2-4265-8A52-B7AA00638E9A@oracle.com>


> On 11 Oct 2018, at 09:03, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi Chris,
> 
> Thanks for review, please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8189366/webrev0.1/index.html) where i included the test.

Thanks. I think this is good.

-Chris.

From michael.x.mcmahon at oracle.com  Thu Oct 11 15:56:10 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 11 Oct 2018 16:56:10 +0100
Subject: RFR [12]: 8203850: java.net.http HTTP client should allow
 specifying Origin and Referer headers
In-Reply-To: <812fc5dd-ea90-ac01-011a-3f579cd6bdad@oracle.com>
References: <5BBF41D8.2040302@oracle.com>
 <812fc5dd-ea90-ac01-011a-3f579cd6bdad@oracle.com>
Message-ID: <5BBF729A.2070609@oracle.com>

Thanks Daniel. I updated that test with some new scenarios
for end to end testing.

http://cr.openjdk.java.net/~michaelm/8203850/webrev.2/

Michael


On 11/10/2018, 13:58, Daniel Fuchs wrote:
> Looks good to me Michael.
>
> You should be able to easily add new test cases for Origin and
> Referer to test/jdk/java/net/SpecialHeadersTest.java too.
>
> best regards,
>
> -- daniel
>
> On 11/10/2018 13:28, Michael McMahon wrote:
>> Could I get the following fix reviewed please?
>>
>> http://cr.openjdk.java.net/~michaelm/8203850/webrev.1/
>>
>> Thanks,
>>
>> Michael
>>
>>
>

From daniel.fuchs at oracle.com  Thu Oct 11 16:32:54 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 11 Oct 2018 17:32:54 +0100
Subject: RFR [12]: 8203850: java.net.http HTTP client should allow
 specifying Origin and Referer headers
In-Reply-To: <5BBF729A.2070609@oracle.com>
References: <5BBF41D8.2040302@oracle.com>
 <812fc5dd-ea90-ac01-011a-3f579cd6bdad@oracle.com>
 <5BBF729A.2070609@oracle.com>
Message-ID: <9f0f350c-a807-0ca9-b62c-a3a895646ef9@oracle.com>

Hi Michael,

Why the test:

  219             if (response.statusCode() != 200)
  220                 throw new RuntimeException("illegal header was 
sent in request");

Shouldn't this always throw, regardless of the status code?

best regards,

-- daniel


On 11/10/2018 16:56, Michael McMahon wrote:
> Thanks Daniel. I updated that test with some new scenarios
> for end to end testing.
> 
> http://cr.openjdk.java.net/~michaelm/8203850/webrev.2/
> 
> Michael
> 
> 
> On 11/10/2018, 13:58, Daniel Fuchs wrote:
>> Looks good to me Michael.
>>
>> You should be able to easily add new test cases for Origin and
>> Referer to test/jdk/java/net/SpecialHeadersTest.java too.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 11/10/2018 13:28, Michael McMahon wrote:
>>> Could I get the following fix reviewed please?
>>>
>>> http://cr.openjdk.java.net/~michaelm/8203850/webrev.1/
>>>
>>> Thanks,
>>>
>>> Michael
>>>
>>>
>>


From michael.x.mcmahon at oracle.com  Thu Oct 11 16:36:22 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 11 Oct 2018 17:36:22 +0100
Subject: RFR [12]: 8203850: java.net.http HTTP client should allow
 specifying Origin and Referer headers
In-Reply-To: <9f0f350c-a807-0ca9-b62c-a3a895646ef9@oracle.com>
References: <5BBF41D8.2040302@oracle.com>
 <812fc5dd-ea90-ac01-011a-3f579cd6bdad@oracle.com>
 <5BBF729A.2070609@oracle.com>
 <9f0f350c-a807-0ca9-b62c-a3a895646ef9@oracle.com>
Message-ID: <5BBF7C06.6060607@oracle.com>

Hi Daniel,

I was allowing for the possibility that the implementation might silently
discard the header. In that case, the server would send the 500 response
after detecting the "Via" header.

- Michael.

On 11/10/2018, 17:32, Daniel Fuchs wrote:
> Hi Michael,
>
> Why the test:
>
>  219             if (response.statusCode() != 200)
>  220                 throw new RuntimeException("illegal header was 
> sent in request");
>
> Shouldn't this always throw, regardless of the status code?
>
> best regards,
>
> -- daniel
>
>
> On 11/10/2018 16:56, Michael McMahon wrote:
>> Thanks Daniel. I updated that test with some new scenarios
>> for end to end testing.
>>
>> http://cr.openjdk.java.net/~michaelm/8203850/webrev.2/
>>
>> Michael
>>
>>
>> On 11/10/2018, 13:58, Daniel Fuchs wrote:
>>> Looks good to me Michael.
>>>
>>> You should be able to easily add new test cases for Origin and
>>> Referer to test/jdk/java/net/SpecialHeadersTest.java too.
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 11/10/2018 13:28, Michael McMahon wrote:
>>>> Could I get the following fix reviewed please?
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8203850/webrev.1/
>>>>
>>>> Thanks,
>>>>
>>>> Michael
>>>>
>>>>
>>>
>

From daniel.fuchs at oracle.com  Thu Oct 11 17:05:21 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 11 Oct 2018 18:05:21 +0100
Subject: RFR [12]: 8203850: java.net.http HTTP client should allow
 specifying Origin and Referer headers
In-Reply-To: <5BBF7C06.6060607@oracle.com>
References: <5BBF41D8.2040302@oracle.com>
 <812fc5dd-ea90-ac01-011a-3f579cd6bdad@oracle.com>
 <5BBF729A.2070609@oracle.com>
 <9f0f350c-a807-0ca9-b62c-a3a895646ef9@oracle.com>
 <5BBF7C06.6060607@oracle.com>
Message-ID: <950cc3d6-8bbf-647e-ab01-247b7dfdc812@oracle.com>

Hi Michael,

On 11/10/2018 17:36, Michael McMahon wrote:
> Hi Daniel,
> 
> I was allowing for the possibility that the implementation might silently
> discard the header. In that case, the server would send the 500 response
> after detecting the "Via" header.

I would agree if that was a JCK test, but here we are testing
the OpenJDK implementation - aren't we?

cheers,

-- daniel

> 
> - Michael.
> 
> On 11/10/2018, 17:32, Daniel Fuchs wrote:
>> Hi Michael,
>>
>> Why the test:
>>
>> ?219???????????? if (response.statusCode() != 200)
>> ?220???????????????? throw new RuntimeException("illegal header was 
>> sent in request");
>>
>> Shouldn't this always throw, regardless of the status code?
>>
>> best regards,
>>
>> -- daniel
>>
>>
>> On 11/10/2018 16:56, Michael McMahon wrote:
>>> Thanks Daniel. I updated that test with some new scenarios
>>> for end to end testing.
>>>
>>> http://cr.openjdk.java.net/~michaelm/8203850/webrev.2/
>>>
>>> Michael
>>>
>>>
>>> On 11/10/2018, 13:58, Daniel Fuchs wrote:
>>>> Looks good to me Michael.
>>>>
>>>> You should be able to easily add new test cases for Origin and
>>>> Referer to test/jdk/java/net/SpecialHeadersTest.java too.
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>> On 11/10/2018 13:28, Michael McMahon wrote:
>>>>> Could I get the following fix reviewed please?
>>>>>
>>>>> http://cr.openjdk.java.net/~michaelm/8203850/webrev.1/
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>
>>


From chris.hegarty at oracle.com  Thu Oct 11 18:28:03 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 11 Oct 2018 19:28:03 +0100
Subject: RFR [12]: 8203850: java.net.http HTTP client should allow
 specifying Origin and Referer headers
In-Reply-To: <950cc3d6-8bbf-647e-ab01-247b7dfdc812@oracle.com>
References: <5BBF41D8.2040302@oracle.com>
 <812fc5dd-ea90-ac01-011a-3f579cd6bdad@oracle.com>
 <5BBF729A.2070609@oracle.com>
 <9f0f350c-a807-0ca9-b62c-a3a895646ef9@oracle.com>
 <5BBF7C06.6060607@oracle.com>
 <950cc3d6-8bbf-647e-ab01-247b7dfdc812@oracle.com>
Message-ID: <1FC2F292-44A5-44D5-A38F-AB9F3C39FD1A@oracle.com>



> On 11 Oct 2018, at 18:05, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Michael,
> 
> On 11/10/2018 17:36, Michael McMahon wrote:
>> Hi Daniel,
>> I was allowing for the possibility that the implementation might silently
>> discard the header. In that case, the server would send the 500 response
>> after detecting the "Via" header.
> 
> I would agree if that was a JCK test, but here we are testing
> the OpenJDK implementation - aren't we?


This should probably be replaced with the unconditional:
    
    Assert.fail(?Unexpected response: ? + response);

-Chris.

From openjdk at suche.org  Thu Oct 11 22:17:48 2018
From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=)
Date: Fri, 12 Oct 2018 00:17:48 +0200
Subject: RFR [12]: 8203850: java.net.http HTTP client should allow
 specifying Origin and Referer headers
In-Reply-To: <812fc5dd-ea90-ac01-011a-3f579cd6bdad@oracle.com>
References: <5BBF41D8.2040302@oracle.com>
 <812fc5dd-ea90-ac01-011a-3f579cd6bdad@oracle.com>
Message-ID: <2b8461c6-33f7-2e8e-83ea-7dcc7701cdbd@suche.org>

Hi,

i did an quick check of the change:

From:
- E-Mail-Adresse des Nutzers, der die Anfrage stellte (heute un?blich). 
RFC 2616 <https://tools.ietf.org/html/rfc2616> sagt hierzu, dass der 
|From:| /nicht/ ohne ausdr?ckliche Genehmigung des Nutzers gesendet 
werden darf.

Why this is now allowed to be sent? Is it not possible that some server 
require it for authentication in B2B scenarios?

With the other header i would agree since they are technical or like 
"Warning" not really used i think.


Gru? Thomas


On 11.10.2018 14:58:02, Daniel Fuchs wrote:
> Looks good to me Michael.
>
> You should be able to easily add new test cases for Origin and
> Referer to test/jdk/java/net/SpecialHeadersTest.java too.
>
> best regards,
>
> -- daniel
>
> On 11/10/2018 13:28, Michael McMahon wrote:
>> Could I get the following fix reviewed please?
>>
>> http://cr.openjdk.java.net/~michaelm/8203850/webrev.1/
>>
>> Thanks,
>>
>> Michael
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181012/d3c27d5a/attachment.html>

From xu.y.yin at oracle.com  Fri Oct 12 02:35:47 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Fri, 12 Oct 2018 10:35:47 +0800
Subject: [12] RFR 8187522: sun/net/ftp/FtpURLConnectionLeak.Java timed out
In-Reply-To: <8CE52990-91B4-43DB-8F57-7AB661EC0F0F@oracle.com>
References: <93E0BD42-28C5-4702-B0C8-C445FCC4B259@oracle.com>
 <8CE52990-91B4-43DB-8F57-7AB661EC0F0F@oracle.com>
Message-ID: <55094ED1-27C3-45B4-9ECC-71D97ADD846A@oracle.com>

Hi, Chris H.

Thanks for your review and comments, I just added a comment as you suggested and update new webrev as below, please have a review.

http://cr.openjdk.java.net/~xyin/8187522/webrev.01/

Thanks,
Chris Y.

> On 11 Oct 2018, at 7:00 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> Chris Y,
> 
>> On 11 Oct 2018, at 09:45, Chris Yin <xu.y.yin at oracle.com <mailto:xu.y.yin at oracle.com>> wrote:
>> 
>> Please review below small change to fix test sun/net/ftp/FtpURLConnectionLeak.Java, thanks
>> 
>> Besides the original timeout issue, looks like the test not working as expected even the results is pass. Per test description, we expect FileNotFoundException and then verify connection closed, but look through recent test run log, it?s actually got ?sun.net.ftp.FtpLoginException: Invalid username/password? and this exception been caught in IOException block coincidentally, so the test result is pass, but it never hit FileNotFoundException. The fix change will remove IOException catch block and close server socket in close() of try-with-resouce to avoid possible invalid exception catch and connection issue, also ftp 220 response message was modified to allow FtpClient working correctly (I leave the corrupted message style as it is since looks like it will be used to test JDK-8151586)
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8187522 <https://bugs.openjdk.java.net/browse/JDK-8187522>
>> webrev: http://cr.openjdk.java.net/~xyin/8187522/webrev.00/ <http://cr.openjdk.java.net/~xyin/8187522/webrev.00/>
> 
> I think this is good.
> 
> The `dash` character in FtpCommandHandler is subtle. I kinda
> regret allowing that change, rather than creating a separate
> standalone test for 8151586. It just confusing and overloads
> the test infra. It might ok at this point, but a comment would
> be good.
> 
> -Chris. 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181012/12f1e246/attachment.html>

From xu.y.yin at oracle.com  Fri Oct 12 02:46:45 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Fri, 12 Oct 2018 10:46:45 +0800
Subject: [12] RFR 8187522: sun/net/ftp/FtpURLConnectionLeak.Java timed out
In-Reply-To: <89B8819F-E65E-4703-AD22-21768CF906A9@oracle.com>
References: <93E0BD42-28C5-4702-B0C8-C445FCC4B259@oracle.com>
 <8df34446-6555-4e8b-a8df-18c357c2bc73@oracle.com>
 <89B8819F-E65E-4703-AD22-21768CF906A9@oracle.com>
Message-ID: <9195AFC1-6181-482A-9CB2-C166E03C91B3@oracle.com>

Hi, Vyom, Chris H.

> On 11 Oct 2018, at 7:08 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> 
> 
>> On 11 Oct 2018, at 12:02, vyom tewari <vyom.tewari at oracle.com <mailto:vyom.tewari at oracle.com>> wrote:
>> On Thursday 11 October 2018 02:15 PM, Chris Yin wrote:
>>> Please review below small change to fix test sun/net/ftp/FtpURLConnectionLeak.Java, thanks
>>> 
>>> Besides the original timeout issue, looks like the test not working as expected even the results is pass. Per test description, we expect FileNotFoundException and then verify connection closed, but look through recent test run log, it?s actually got ?sun.net.ftp.FtpLoginException: Invalid username/password? and this exception been caught in IOException block coincidentally, so the test result is pass, but it never hit FileNotFoundException. The fix change will remove IOException catch block and close server socket in close() of try-with-resouce to avoid possible invalid exception catch and connection issue, also ftp 220 response message was modified to allow FtpClient working correctly (I leave the corrupted message style as it is since looks like it will be used to test JDK-8151586)
>> you are right, corrupted message style is intentional. Your code changes looks good to me but i am not able to understand "FtpCommandHandler.java" changes.
>> 
>>  I can see that you inserted one "-" , is it intentional ?

Thanks for reviewing and checking this, yep, the ?-? char is intentional, as Chris H. also explained below, we need it to make sure ftp communication not been broken, otherwise tests like FtpURLConnection will fall in ?sun.net.ftp.FtpLoginException? unexpectedly

> 
> If the 4th char is a dash, then the implementation ( for
> what it?s worth ) thinks that it has seen multi-line reply
> `###-` sequence.
> 
> It needs a comment, or maybe revert prior to 8151586.
> And a separate specific test added for 8151586.

Thanks for your suggestion, currently, I just added a comment to explain the 220 response message and sent updated webrev in earlier thread, I may prefer to process in that way for now if no objection since separate specific test added for 8151586 is already out of scope of current bug :). We may have another bug/enhancement to track it if necessary. Thanks

Regards,
Chris Y.

> 
> -Chris.
> 
> 
> 
>> Thanks,
>> Vyom
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8187522 <https://bugs.openjdk.java.net/browse/JDK-8187522>
>>> webrev: http://cr.openjdk.java.net/~xyin/8187522/webrev.00/ <http://cr.openjdk.java.net/~xyin/8187522/webrev.00/>
>>> 
>>> Regards,
>>> Chris
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181012/a585ff26/attachment-0001.html>

From Alan.Bateman at oracle.com  Fri Oct 12 07:29:51 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Oct 2018 08:29:51 +0100
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
 <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
 <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>
 <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>
Message-ID: <a3da1f43-a890-f337-310c-47c13a1f9617@oracle.com>

On 11/10/2018 09:03, vyom tewari wrote:
> Hi Chris,
>
> Thanks for review, please find the updated 
> webrev(http://cr.openjdk.java.net/~vtewari/8189366/webrev0.1/index.html) 
> where i included the test.
Can you explain the behavior change for the closed socket case? Will 
this change mean that available returns 0 when it previously throw 
IOException?

-Alan

From chris.hegarty at oracle.com  Fri Oct 12 08:55:12 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 12 Oct 2018 09:55:12 +0100
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <a3da1f43-a890-f337-310c-47c13a1f9617@oracle.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
 <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
 <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>
 <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>
 <a3da1f43-a890-f337-310c-47c13a1f9617@oracle.com>
Message-ID: <6db8e143-41e0-c1e3-2106-85afab8aee7d@oracle.com>


On 12/10/18 08:29, Alan Bateman wrote:
> On 11/10/2018 09:03, vyom tewari wrote:
>> Hi Chris,
>>
>> Thanks for review, please find the updated 
>> webrev(http://cr.openjdk.java.net/~vtewari/8189366/webrev0.1/index.html) 
>> where i included the test.
> Can you explain the behavior change for the closed socket case? Will 
> this change mean that available returns 0 when it previously throw 
> IOException?

You are correct. This is not intentional, or desirable.

We should revert the change or add an additional check
for isClosedOrPending. Since this is already pushed, I
filed a new JIRA issue to track this.

   https://bugs.openjdk.java.net/browse/JDK-8212114

-Chris.


From chris.hegarty at oracle.com  Fri Oct 12 08:57:19 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 12 Oct 2018 09:57:19 +0100
Subject: [12] RFR 8187522: sun/net/ftp/FtpURLConnectionLeak.Java timed out
In-Reply-To: <9195AFC1-6181-482A-9CB2-C166E03C91B3@oracle.com>
References: <93E0BD42-28C5-4702-B0C8-C445FCC4B259@oracle.com>
 <8df34446-6555-4e8b-a8df-18c357c2bc73@oracle.com>
 <89B8819F-E65E-4703-AD22-21768CF906A9@oracle.com>
 <9195AFC1-6181-482A-9CB2-C166E03C91B3@oracle.com>
Message-ID: <647e5aca-78fb-dc4c-e728-f78a664bc0b1@oracle.com>



On 12/10/18 03:46, Chris Yin wrote:
> ...
> 
> Thanks for your suggestion, currently, I just added a comment to explain 
> the 220 response message and sent updated webrev in earlier thread, I 
> may prefer to process in that way for now if no objection since separate 
> specific test added for 8151586 is already out of scope of current bug 
> :). We may have another bug/enhancement to track it if necessary. Thanks

Agreed.

 > http://cr.openjdk.java.net/~xyin/8187522/webrev.01/

This looks good to me.

-Chris.

From daniel.fuchs at oracle.com  Fri Oct 12 10:26:23 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 Oct 2018 11:26:23 +0100
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <6db8e143-41e0-c1e3-2106-85afab8aee7d@oracle.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
 <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
 <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>
 <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>
 <a3da1f43-a890-f337-310c-47c13a1f9617@oracle.com>
 <6db8e143-41e0-c1e3-2106-85afab8aee7d@oracle.com>
Message-ID: <ae86957f-2f0d-4f59-76af-8c11ef0488c0@oracle.com>

Hi,

Maybe a more conservative implementation could have been:

    int available = impl.available();
    return eof ? 0 : available;

I almost suggested that yesterday, but I saw that
read() already had a logic similar to what Vyom was
proposing for available:

  146         // EOF already encountered
  147         if (eof) {
  148             return -1;
  149         }

which AFAICT  means that read returns -1 instead of throwing
if the socket is closed and EOF was previously reached.

best regards,

-- daniel

On 12/10/2018 09:55, Chris Hegarty wrote:
> 
> On 12/10/18 08:29, Alan Bateman wrote:
>> On 11/10/2018 09:03, vyom tewari wrote:
>>> Hi Chris,
>>>
>>> Thanks for review, please find the updated 
>>> webrev(http://cr.openjdk.java.net/~vtewari/8189366/webrev0.1/index.html) 
>>> where i included the test.
>> Can you explain the behavior change for the closed socket case? Will 
>> this change mean that available returns 0 when it previously throw 
>> IOException?
> 
> You are correct. This is not intentional, or desirable.
> 
> We should revert the change or add an additional check
> for isClosedOrPending. Since this is already pushed, I
> filed a new JIRA issue to track this.
> 
>  ? https://bugs.openjdk.java.net/browse/JDK-8212114
> 
> -Chris.
> 


From chris.hegarty at oracle.com  Fri Oct 12 11:01:25 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 12 Oct 2018 12:01:25 +0100
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <ae86957f-2f0d-4f59-76af-8c11ef0488c0@oracle.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
 <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
 <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>
 <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>
 <a3da1f43-a890-f337-310c-47c13a1f9617@oracle.com>
 <6db8e143-41e0-c1e3-2106-85afab8aee7d@oracle.com>
 <ae86957f-2f0d-4f59-76af-8c11ef0488c0@oracle.com>
Message-ID: <05d52c14-a576-ef1c-516c-bd9ea3ab8c30@oracle.com>

Daniel,

On 12/10/18 11:26, Daniel Fuchs wrote:
> Hi,
> 
> Maybe a more conservative implementation could have been:
> 
>  ?? int available = impl.available();
>  ?? return eof ? 0 : available;

That buys us little more than we had prior to this change,
since impl.available will still call into native before
checking the EOF status.

If we want to keep this, then we need:

     public int available() throws IOException {
         if (impl.isClosedOrPending()) {
             throw new SocketException("Socket closed");
         }

         if (eof) {
             return 0;
         } else {
             return impl.available();
         }
     }

> I almost suggested that yesterday, but I saw that
> read() already had a logic similar to what Vyom was
> proposing for available:
> 
>  ?146???????? // EOF already encountered
>  ?147???????? if (eof) {
>  ?148???????????? return -1;
>  ?149???????? }
> 
> which AFAICT? means that read returns -1 instead of throwing
> if the socket is closed and EOF was previously reached.

That is correct. While not intuitive, I don't propose
that we change this. ( if this were a new implementation
then I think it should throw IOE for this scenario, but
we are where we are ).

-Chris.


> best regards,
> 
> -- daniel
> 
> On 12/10/2018 09:55, Chris Hegarty wrote:
>>
>> On 12/10/18 08:29, Alan Bateman wrote:
>>> On 11/10/2018 09:03, vyom tewari wrote:
>>>> Hi Chris,
>>>>
>>>> Thanks for review, please find the updated 
>>>> webrev(http://cr.openjdk.java.net/~vtewari/8189366/webrev0.1/index.html) 
>>>> where i included the test.
>>> Can you explain the behavior change for the closed socket case? Will 
>>> this change mean that available returns 0 when it previously throw 
>>> IOException?
>>
>> You are correct. This is not intentional, or desirable.
>>
>> We should revert the change or add an additional check
>> for isClosedOrPending. Since this is already pushed, I
>> filed a new JIRA issue to track this.
>>
>> ?? https://bugs.openjdk.java.net/browse/JDK-8212114
>>
>> -Chris.
>>
> 

From vyom.tewari at oracle.com  Fri Oct 12 11:22:27 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Fri, 12 Oct 2018 16:52:27 +0530
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <05d52c14-a576-ef1c-516c-bd9ea3ab8c30@oracle.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
 <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
 <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>
 <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>
 <a3da1f43-a890-f337-310c-47c13a1f9617@oracle.com>
 <6db8e143-41e0-c1e3-2106-85afab8aee7d@oracle.com>
 <ae86957f-2f0d-4f59-76af-8c11ef0488c0@oracle.com>
 <05d52c14-a576-ef1c-516c-bd9ea3ab8c30@oracle.com>
Message-ID: <a030f1e9-72ce-e6dd-49c0-81db01718d14@oracle.com>



On Friday 12 October 2018 04:31 PM, Chris Hegarty wrote:
> Daniel,
>
> On 12/10/18 11:26, Daniel Fuchs wrote:
>> Hi,
>>
>> Maybe a more conservative implementation could have been:
>>
>> ??? int available = impl.available();
>> ??? return eof ? 0 : available;
>
> That buys us little more than we had prior to this change,
> since impl.available will still call into native before
> checking the EOF status.
>
> If we want to keep this, then we need:
>
> ??? public int available() throws IOException {
> ??????? if (impl.isClosedOrPending()) {
> ??????????? throw new SocketException("Socket closed");
> ??????? }
>
> ??????? if (eof) {
> ??????????? return 0;
> ??????? } else {
> ??????????? return impl.available();
> ??????? }
> ??? }
>
Above change is working as expected, i? modified the "CloseAvailable"? 
test little bit and with modified code, SocketInputstream.available() is 
now throwing "java.net.SocketException: Socket closed" exception if the 
underline socket is closed.

I will prepare a patch along with modified test and send it for review.

I ran our internal tests and it looks like? it was not caught there.

Thanks,
Vyom

>> I almost suggested that yesterday, but I saw that
>> read() already had a logic similar to what Vyom was
>> proposing for available:
>>
>> ??146???????? // EOF already encountered
>> ??147???????? if (eof) {
>> ??148???????????? return -1;
>> ??149???????? }
>>
>> which AFAICT? means that read returns -1 instead of throwing
>> if the socket is closed and EOF was previously reached.
>
> That is correct. While not intuitive, I don't propose
> that we change this. ( if this were a new implementation
> then I think it should throw IOE for this scenario, but
> we are where we are ).
>
> -Chris.
>
>
>> best regards,
>>
>> -- daniel
>>
>> On 12/10/2018 09:55, Chris Hegarty wrote:
>>>
>>> On 12/10/18 08:29, Alan Bateman wrote:
>>>> On 11/10/2018 09:03, vyom tewari wrote:
>>>>> Hi Chris,
>>>>>
>>>>> Thanks for review, please find the updated 
>>>>> webrev(http://cr.openjdk.java.net/~vtewari/8189366/webrev0.1/index.html) 
>>>>> where i included the test.
>>>> Can you explain the behavior change for the closed socket case? 
>>>> Will this change mean that available returns 0 when it previously 
>>>> throw IOException?
>>>
>>> You are correct. This is not intentional, or desirable.
>>>
>>> We should revert the change or add an additional check
>>> for isClosedOrPending. Since this is already pushed, I
>>> filed a new JIRA issue to track this.
>>>
>>> ?? https://bugs.openjdk.java.net/browse/JDK-8212114
>>>
>>> -Chris.
>>>
>>


From daniel.fuchs at oracle.com  Fri Oct 12 11:58:45 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 Oct 2018 12:58:45 +0100
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <05d52c14-a576-ef1c-516c-bd9ea3ab8c30@oracle.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
 <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
 <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>
 <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>
 <a3da1f43-a890-f337-310c-47c13a1f9617@oracle.com>
 <6db8e143-41e0-c1e3-2106-85afab8aee7d@oracle.com>
 <ae86957f-2f0d-4f59-76af-8c11ef0488c0@oracle.com>
 <05d52c14-a576-ef1c-516c-bd9ea3ab8c30@oracle.com>
Message-ID: <f867042b-d1b0-b46b-af13-457dce5c2642@oracle.com>

On 12/10/2018 12:01, Chris Hegarty wrote:
> That buys us little more than we had prior to this change,
> since impl.available will still call into native before
> checking the EOF status.
> 
> If we want to keep this, then we need:
> 
>  ??? public int available() throws IOException {
>  ??????? if (impl.isClosedOrPending()) {
>  ??????????? throw new SocketException("Socket closed");
>  ??????? }
> 
>  ??????? if (eof) {
>  ??????????? return 0;
>  ??????? } else {
>  ??????????? return impl.available();
>  ??????? }
>  ??? }
> 

Hmmm...

I thought impl.available() was going to throw the
exception?

If you don't want to penalize the regular case  where
eof is false, and the impl is supposed to throw the
exception, and you want to avoid to go back to the
native impl when eof has been reached, then maybe you
need:

     public int available() throws IOException {
         if (eof) {
             if (impl.isClosedOrPending()) {
                 throw new SocketException("Socket closed");
             }
             return 0;
         } else {
             return impl.available();
         }
     }

and that's assuming the that the exception that the impl would
throw is exactly new SocketException("Socket closed");

Can't help feeling that

     int available = impl.available();
     return eof ? 0 : available;

addresses the issue of available potentially returning garbage
after EOF while being much less risky...

cheers,

-- daniel

From david.lloyd at redhat.com  Fri Oct 12 13:43:34 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 12 Oct 2018 08:43:34 -0500
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <05d52c14-a576-ef1c-516c-bd9ea3ab8c30@oracle.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
 <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
 <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>
 <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>
 <a3da1f43-a890-f337-310c-47c13a1f9617@oracle.com>
 <6db8e143-41e0-c1e3-2106-85afab8aee7d@oracle.com>
 <ae86957f-2f0d-4f59-76af-8c11ef0488c0@oracle.com>
 <05d52c14-a576-ef1c-516c-bd9ea3ab8c30@oracle.com>
Message-ID: <CANghgrTmRyZ_bKQd9F6Xcb-PK6OFkqDjjyNWgSafkNxuAr29iA@mail.gmail.com>

On Fri, Oct 12, 2018 at 6:01 AM Chris Hegarty <chris.hegarty at oracle.com> wrote:
> That is correct. While not intuitive, I don't propose
> that we change this. ( if this were a new implementation
> then I think it should throw IOE for this scenario, but
> we are where we are ).

I am glad then that it is not a new implementation.  Returning an EOF
signal is a very reasonable behavior for a closed input stream or
input channel.  In most cases, it is more difficult for I/O handling
code to distinguish the two states (open+eof versus closed), and in
every case I've ever known, they are handled in the same way, or
intended to be.  There is no useful way I know of to exploit a side
effect of exception throwing in the read-on-closed case.

Also, I think it's a lot more reasonable for programs to expect that
available() will return 0 when the stream is closed than for
available() to be, in effect, an openness check.  Granted that
available() is not really useful anyway, but were one to use it,
having an extra failure state to deal with probably isn't helpful.

-- 
- DML

From Alan.Bateman at oracle.com  Fri Oct 12 14:35:05 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Oct 2018 15:35:05 +0100
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <CANghgrTmRyZ_bKQd9F6Xcb-PK6OFkqDjjyNWgSafkNxuAr29iA@mail.gmail.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
 <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
 <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>
 <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>
 <a3da1f43-a890-f337-310c-47c13a1f9617@oracle.com>
 <6db8e143-41e0-c1e3-2106-85afab8aee7d@oracle.com>
 <ae86957f-2f0d-4f59-76af-8c11ef0488c0@oracle.com>
 <05d52c14-a576-ef1c-516c-bd9ea3ab8c30@oracle.com>
 <CANghgrTmRyZ_bKQd9F6Xcb-PK6OFkqDjjyNWgSafkNxuAr29iA@mail.gmail.com>
Message-ID: <cb43c9c6-7a29-fc08-0e11-7dd16a6b8834@oracle.com>

On 12/10/2018 14:43, David Lloyd wrote:
> On Fri, Oct 12, 2018 at 6:01 AM Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> That is correct. While not intuitive, I don't propose
>> that we change this. ( if this were a new implementation
>> then I think it should throw IOE for this scenario, but
>> we are where we are ).
> I am glad then that it is not a new implementation.  Returning an EOF
> signal is a very reasonable behavior for a closed input stream or
> input channel.
It's an interesting discussion point as it will likely depend on the 
protocol as to how premature EOF is handled. Also if you asynchronously 
close the socket then it will be random as to whether a reader on the 
same socket will read -1 or throw an exception.

-Alan

From sha.jiang at oracle.com  Mon Oct 15 02:36:00 2018
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 15 Oct 2018 10:36:00 +0800
Subject: RFR[12] JDK-8211978: move
 testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network
 testlibrary
Message-ID: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com>

Hi,
This patch moves 
test/jdk/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java to 
test/lib/jdk/test/lib/net/SimpleSSLContext.java.

Webrev: http://cr.openjdk.java.net/~jjiang/8211978/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8211978

Best regards,
John Jiang


From weijun.wang at oracle.com  Mon Oct 15 02:53:58 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 15 Oct 2018 10:53:58 +0800
Subject: RFR[12] JDK-8211978: move
 testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network
 testlibrary
In-Reply-To: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com>
References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com>
Message-ID: <FF75DDB3-2706-4C69-A2C6-8162BBD89681@oracle.com>

Hi John

I see testkeys is directly referenced in AbstractSSLTubeTest.java and FlowTest.java by an inner class also named SimpleSSLContext. Is it very different from the one in SimpleSSLContext.java? Can they be combined?

If so, then we have a chance to ASCII-fy the testkeys file and directly include it inside SimpleSSLContext.java. This way we can delete one more binary file and do not need to care about file permissions. What a marvelous gain would that be!

Thanks
Max

> On Oct 15, 2018, at 10:36 AM, sha.jiang at oracle.com wrote:
> 
> Hi,
> This patch moves test/jdk/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java to test/lib/jdk/test/lib/net/SimpleSSLContext.java.
> 
> Webrev: http://cr.openjdk.java.net/~jjiang/8211978/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211978
> 
> Best regards,
> John Jiang
> 


From daniel.fuchs at oracle.com  Mon Oct 15 09:21:40 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 15 Oct 2018 10:21:40 +0100
Subject: RFR[12] JDK-8211978: move
 testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network
 testlibrary
In-Reply-To: <FF75DDB3-2706-4C69-A2C6-8162BBD89681@oracle.com>
References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com>
 <FF75DDB3-2706-4C69-A2C6-8162BBD89681@oracle.com>
Message-ID: <d49b584d-a86b-c62e-b9fa-d3196f52507d@oracle.com>

Hi Max,

These tests are whitebox tests - the tests classes are patched
into the java.net.http module, and as a consequence they can't
compile against library classes which are on the classpath.
This is the unfortunate reason for the presence of a
SimpleSSLContext clone in there.

best regards,

-- daniel

On 15/10/2018 03:53, Weijun Wang wrote:
> Hi John
> 
> I see testkeys is directly referenced in AbstractSSLTubeTest.java and FlowTest.java by an inner class also named SimpleSSLContext. Is it very different from the one in SimpleSSLContext.java? Can they be combined?
> 
> If so, then we have a chance to ASCII-fy the testkeys file and directly include it inside SimpleSSLContext.java. This way we can delete one more binary file and do not need to care about file permissions. What a marvelous gain would that be!
> 
> Thanks
> Max


From weijun.wang at oracle.com  Mon Oct 15 09:53:41 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 15 Oct 2018 17:53:41 +0800
Subject: RFR[12] JDK-8211978: move
 testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network
 testlibrary
In-Reply-To: <d49b584d-a86b-c62e-b9fa-d3196f52507d@oracle.com>
References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com>
 <FF75DDB3-2706-4C69-A2C6-8162BBD89681@oracle.com>
 <d49b584d-a86b-c62e-b9fa-d3196f52507d@oracle.com>
Message-ID: <5671C850-A87D-4721-8246-86545988BF27@oracle.com>

This is bad.

Maybe we can duplicate the ASCII-fied data. I don't have a strong opinion now.

--Max

> On Oct 15, 2018, at 5:21 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Max,
> 
> These tests are whitebox tests - the tests classes are patched
> into the java.net.http module, and as a consequence they can't
> compile against library classes which are on the classpath.
> This is the unfortunate reason for the presence of a
> SimpleSSLContext clone in there.
> 
> best regards,
> 
> -- daniel
> 
> On 15/10/2018 03:53, Weijun Wang wrote:
>> Hi John
>> I see testkeys is directly referenced in AbstractSSLTubeTest.java and FlowTest.java by an inner class also named SimpleSSLContext. Is it very different from the one in SimpleSSLContext.java? Can they be combined?
>> If so, then we have a chance to ASCII-fy the testkeys file and directly include it inside SimpleSSLContext.java. This way we can delete one more binary file and do not need to care about file permissions. What a marvelous gain would that be!
>> Thanks
>> Max
> 


From sha.jiang at oracle.com  Mon Oct 15 09:55:01 2018
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 15 Oct 2018 17:55:01 +0800
Subject: RFR[12] JDK-8211978: move
 testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network
 testlibrary
In-Reply-To: <d49b584d-a86b-c62e-b9fa-d3196f52507d@oracle.com>
References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com>
 <FF75DDB3-2706-4C69-A2C6-8162BBD89681@oracle.com>
 <d49b584d-a86b-c62e-b9fa-d3196f52507d@oracle.com>
Message-ID: <70e70b4b-9a36-fe3e-2a3f-cccc44b6f516@oracle.com>

At least, the inner SimpleSSLContext classes in AbstractSSLTubeTest.java 
and FlowTest.java could be combined.
I'm doing it.

Best regards,
John Jiang

On 2018/10/15 17:21, Daniel Fuchs wrote:
> Hi Max,
>
> These tests are whitebox tests - the tests classes are patched
> into the java.net.http module, and as a consequence they can't
> compile against library classes which are on the classpath.
> This is the unfortunate reason for the presence of a
> SimpleSSLContext clone in there.
>
> best regards,
>
> -- daniel
>
> On 15/10/2018 03:53, Weijun Wang wrote:
>> Hi John
>>
>> I see testkeys is directly referenced in AbstractSSLTubeTest.java and 
>> FlowTest.java by an inner class also named SimpleSSLContext. Is it 
>> very different from the one in SimpleSSLContext.java? Can they be 
>> combined?
>>
>> If so, then we have a chance to ASCII-fy the testkeys file and 
>> directly include it inside SimpleSSLContext.java. This way we can 
>> delete one more binary file and do not need to care about file 
>> permissions. What a marvelous gain would that be!
>>
>> Thanks
>> Max
>
>


From chris.hegarty at oracle.com  Mon Oct 15 10:01:33 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 15 Oct 2018 11:01:33 +0100
Subject: RFR[12] JDK-8211978: move
 testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network
 testlibrary
In-Reply-To: <5671C850-A87D-4721-8246-86545988BF27@oracle.com>
References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com>
 <FF75DDB3-2706-4C69-A2C6-8162BBD89681@oracle.com>
 <d49b584d-a86b-c62e-b9fa-d3196f52507d@oracle.com>
 <5671C850-A87D-4721-8246-86545988BF27@oracle.com>
Message-ID: <63b5102f-6d62-a188-f8de-83e1dfde5163@oracle.com>

On 15/10/18 10:53, Weijun Wang wrote:
> This is bad.

In the absence of better test library, module-patching,
and jtreg support, this is what we end up with. It's
not too bad.

> Maybe we can duplicate the ASCII-fied data. I don't have a strong opinion now.

Duplicating the testkeys, regardless of ASCII-ification
seems worse than the duplication of this small trivial
implementation class.

-Chris.

> --Max
> 
>> On Oct 15, 2018, at 5:21 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi Max,
>>
>> These tests are whitebox tests - the tests classes are patched
>> into the java.net.http module, and as a consequence they can't
>> compile against library classes which are on the classpath.
>> This is the unfortunate reason for the presence of a
>> SimpleSSLContext clone in there.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 15/10/2018 03:53, Weijun Wang wrote:
>>> Hi John
>>> I see testkeys is directly referenced in AbstractSSLTubeTest.java and FlowTest.java by an inner class also named SimpleSSLContext. Is it very different from the one in SimpleSSLContext.java? Can they be combined?
>>> If so, then we have a chance to ASCII-fy the testkeys file and directly include it inside SimpleSSLContext.java. This way we can delete one more binary file and do not need to care about file permissions. What a marvelous gain would that be!
>>> Thanks
>>> Max
>>
> 

From sha.jiang at oracle.com  Mon Oct 15 10:07:17 2018
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 15 Oct 2018 18:07:17 +0800
Subject: RFR[12] JDK-8211978: move
 testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network
 testlibrary
In-Reply-To: <70e70b4b-9a36-fe3e-2a3f-cccc44b6f516@oracle.com>
References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com>
 <FF75DDB3-2706-4C69-A2C6-8162BBD89681@oracle.com>
 <d49b584d-a86b-c62e-b9fa-d3196f52507d@oracle.com>
 <70e70b4b-9a36-fe3e-2a3f-cccc44b6f516@oracle.com>
Message-ID: <409bf625-5d2c-0980-ea77-3de1b94fb081@oracle.com>

Please review the updated webrev:
http://cr.openjdk.java.net/~jjiang/8211978/webrev.01/
AbstractSSLTubeTest.java and FlowTest.java now use the same 
internal.net.http.SimpleSSLContext.java

In addition, it looks the original jdk/testlibrary/SimpleSSLContext.java 
could accept an alternative keystore file,
so I don't change this logic and keep the binary testkeys.

Best regards,
John Jiang

On 2018/10/15 17:55, sha.jiang at oracle.com wrote:
> At least, the inner SimpleSSLContext classes in 
> AbstractSSLTubeTest.java and FlowTest.java could be combined.
> I'm doing it.
>
> Best regards,
> John Jiang
>
> On 2018/10/15 17:21, Daniel Fuchs wrote:
>> Hi Max,
>>
>> These tests are whitebox tests - the tests classes are patched
>> into the java.net.http module, and as a consequence they can't
>> compile against library classes which are on the classpath.
>> This is the unfortunate reason for the presence of a
>> SimpleSSLContext clone in there.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 15/10/2018 03:53, Weijun Wang wrote:
>>> Hi John
>>>
>>> I see testkeys is directly referenced in AbstractSSLTubeTest.java 
>>> and FlowTest.java by an inner class also named SimpleSSLContext. Is 
>>> it very different from the one in SimpleSSLContext.java? Can they be 
>>> combined?
>>>
>>> If so, then we have a chance to ASCII-fy the testkeys file and 
>>> directly include it inside SimpleSSLContext.java. This way we can 
>>> delete one more binary file and do not need to care about file 
>>> permissions. What a marvelous gain would that be!
>>>
>>> Thanks
>>> Max
>>
>>
>
>


From weijun.wang at oracle.com  Mon Oct 15 10:10:25 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 15 Oct 2018 18:10:25 +0800
Subject: RFR[12] JDK-8211978: move
 testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network
 testlibrary
In-Reply-To: <63b5102f-6d62-a188-f8de-83e1dfde5163@oracle.com>
References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com>
 <FF75DDB3-2706-4C69-A2C6-8162BBD89681@oracle.com>
 <d49b584d-a86b-c62e-b9fa-d3196f52507d@oracle.com>
 <5671C850-A87D-4721-8246-86545988BF27@oracle.com>
 <63b5102f-6d62-a188-f8de-83e1dfde5163@oracle.com>
Message-ID: <114E135E-9CB9-484C-B179-158AD8093D4C@oracle.com>



> On Oct 15, 2018, at 6:01 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> On 15/10/18 10:53, Weijun Wang wrote:
>> This is bad.
> 
> In the absence of better test library, module-patching,
> and jtreg support, this is what we end up with. It's
> not too bad.

I meant this is unfortunate, or this is a bad situation. No complaint to the tests themselves.

> 
>> Maybe we can duplicate the ASCII-fied data. I don't have a strong opinion now.
> 
> Duplicating the testkeys, regardless of ASCII-ification
> seems worse than the duplication of this small trivial
> implementation class.

I understand the duplication of the class is inevitable anyway now. Just thought if the data should be duplicated too. On one hand it's about ASCII-ification, also, it's about test maintaining. Every time I see "../../.." I feel scared.

Thanks
Max

> 
> -Chris.
> 
>> --Max
>>> On Oct 15, 2018, at 5:21 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>> 
>>> Hi Max,
>>> 
>>> These tests are whitebox tests - the tests classes are patched
>>> into the java.net.http module, and as a consequence they can't
>>> compile against library classes which are on the classpath.
>>> This is the unfortunate reason for the presence of a
>>> SimpleSSLContext clone in there.
>>> 
>>> best regards,
>>> 
>>> -- daniel
>>> 
>>> On 15/10/2018 03:53, Weijun Wang wrote:
>>>> Hi John
>>>> I see testkeys is directly referenced in AbstractSSLTubeTest.java and FlowTest.java by an inner class also named SimpleSSLContext. Is it very different from the one in SimpleSSLContext.java? Can they be combined?
>>>> If so, then we have a chance to ASCII-fy the testkeys file and directly include it inside SimpleSSLContext.java. This way we can delete one more binary file and do not need to care about file permissions. What a marvelous gain would that be!
>>>> Thanks
>>>> Max
>>> 


From chris.hegarty at oracle.com  Mon Oct 15 10:22:34 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 15 Oct 2018 11:22:34 +0100
Subject: RFR[12] JDK-8211978: move
 testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network
 testlibrary
In-Reply-To: <409bf625-5d2c-0980-ea77-3de1b94fb081@oracle.com>
References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com>
 <FF75DDB3-2706-4C69-A2C6-8162BBD89681@oracle.com>
 <d49b584d-a86b-c62e-b9fa-d3196f52507d@oracle.com>
 <70e70b4b-9a36-fe3e-2a3f-cccc44b6f516@oracle.com>
 <409bf625-5d2c-0980-ea77-3de1b94fb081@oracle.com>
Message-ID: <6981bc96-4e15-9a51-8054-b3a54a8fedf2@oracle.com>


On 15/10/18 11:07, sha.jiang at oracle.com wrote:
> Please review the updated webrev:
> http://cr.openjdk.java.net/~jjiang/8211978/webrev.01/
> AbstractSSLTubeTest.java and FlowTest.java now use the same 
> internal.net.http.SimpleSSLContext.java

This looks good to me. Thanks John.

Trivially, can you please fix an existing line length issue
in ManyRequests2.java and ManyRequestsLegacy.java? Where the
@summary and @run lines could be split better across a few
lines ( no need to regenerate the webrev ).

-Chris.

From michael.x.mcmahon at oracle.com  Mon Oct 15 10:54:43 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 15 Oct 2018 11:54:43 +0100
Subject: RFR [12]: java.net.http.HttpClient hangs on 204 reply without
 Content-length 0
Message-ID: <5BC471F3.6000703@oracle.com>

Could I get the following fix reviewed please.

http://cr.openjdk.java.net/~michaelm/8211437/webrev.1/index.html

Thanks,

Michael.

From daniel.fuchs at oracle.com  Mon Oct 15 11:53:12 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 15 Oct 2018 12:53:12 +0100
Subject: RFR [12]: java.net.http.HttpClient hangs on 204 reply without
 Content-length 0
In-Reply-To: <5BC471F3.6000703@oracle.com>
References: <5BC471F3.6000703@oracle.com>
Message-ID: <6586e6de-b427-bf48-4cb9-f9dc75d3f03e@oracle.com>

Hi Michael,

On 15/10/2018 11:54, Michael McMahon wrote:
> Could I get the following fix reviewed please.
> 
> http://cr.openjdk.java.net/~michaelm/8211437/webrev.1/index.html

Looks good in general.

In MultiExchange.java:

236             T nullBody = cf.get();

Though technically the body should be available by the
time we reach this line, since you completed the subscriber
just before, we can't really make any assumption on the
implementation of the subscriber.

So for the sake of robustness we should probably use
getBody().handle(...) to complete `result`
rather than calling cf.get();


Also I wonder what should happen if a body is present:

Should we simply read it instead?
Because if we don't then we should close the connection (HTTP/1.1)
or reset the stream (HTTP/2) - which probably means getting back
to the concrete  exchange implementation to make sure that
happens.

best regards,

-- daniel

> 
> Thanks,
> 
> Michael.


From michael.x.mcmahon at oracle.com  Mon Oct 15 15:07:01 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 15 Oct 2018 16:07:01 +0100
Subject: RFR [12]: java.net.http.HttpClient hangs on 204 reply without
 Content-length 0
In-Reply-To: <6586e6de-b427-bf48-4cb9-f9dc75d3f03e@oracle.com>
References: <5BC471F3.6000703@oracle.com>
 <6586e6de-b427-bf48-4cb9-f9dc75d3f03e@oracle.com>
Message-ID: <5BC4AD15.1020203@oracle.com>

Hi Daniel,

On 15/10/2018, 12:53, Daniel Fuchs wrote:
> Hi Michael,
>
> On 15/10/2018 11:54, Michael McMahon wrote:
>> Could I get the following fix reviewed please.
>>
>> http://cr.openjdk.java.net/~michaelm/8211437/webrev.1/index.html
>
> Looks good in general.
>
> In MultiExchange.java:
>
> 236             T nullBody = cf.get();
>
> Though technically the body should be available by the
> time we reach this line, since you completed the subscriber
> just before, we can't really make any assumption on the
> implementation of the subscriber.
>
> So for the sake of robustness we should probably use
> getBody().handle(...) to complete `result`
> rather than calling cf.get();
>

Yes, that would be better.

>
> Also I wonder what should happen if a body is present:
>
> Should we simply read it instead?
> Because if we don't then we should close the connection (HTTP/1.1)
> or reset the stream (HTTP/2) - which probably means getting back
> to the concrete  exchange implementation to make sure that
> happens.
>

I see that as a protocol error. So, rather than attempting to read the
body, I think we should ensure that the request fails (which it does
if a content length or transfer encoding field is present). The connection
also needs to be closed (or stream reset) which I need to check is being 
done.

Thanks,
Michael

> best regards,
>
> -- daniel
>
>>
>> Thanks,
>>
>> Michael.
>

From michael.x.mcmahon at oracle.com  Mon Oct 15 15:29:48 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 15 Oct 2018 16:29:48 +0100
Subject: RFR [12]: 8203850: java.net.http HTTP client should allow
 specifying Origin and Referer headers
In-Reply-To: <2b8461c6-33f7-2e8e-83ea-7dcc7701cdbd@suche.org>
References: <5BBF41D8.2040302@oracle.com>
 <812fc5dd-ea90-ac01-011a-3f579cd6bdad@oracle.com>
 <2b8461c6-33f7-2e8e-83ea-7dcc7701cdbd@suche.org>
Message-ID: <5BC4B26C.3040700@oracle.com>

Hi,

We haven't changed anything related to the From header. Are you 
suggesting that "From"
should be removed from the restricted list also?

- Michael

On 11/10/2018, 23:17, Thomas Lu?nig wrote:
>
> Hi,
>
> i did an quick check of the change:
>
> From:
> - E-Mail-Adresse des Nutzers, der die Anfrage stellte (heute 
> un?blich). RFC 2616 <https://tools.ietf.org/html/rfc2616> sagt hierzu, 
> dass der |From:| /nicht/ ohne ausdr?ckliche Genehmigung des Nutzers 
> gesendet werden darf.
>
> Why this is now allowed to be sent? Is it not possible that some 
> server require it for authentication in B2B scenarios?
>
> With the other header i would agree since they are technical or like 
> "Warning" not really used i think.
>
>
> Gru? Thomas
>
>
> On 11.10.2018 14:58:02, Daniel Fuchs wrote:
>> Looks good to me Michael.
>>
>> You should be able to easily add new test cases for Origin and
>> Referer to test/jdk/java/net/SpecialHeadersTest.java too.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 11/10/2018 13:28, Michael McMahon wrote:
>>> Could I get the following fix reviewed please?
>>>
>>> http://cr.openjdk.java.net/~michaelm/8203850/webrev.1/
>>>
>>> Thanks,
>>>
>>> Michael
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181015/0c197065/attachment.html>

From chris.hegarty at oracle.com  Wed Oct 17 11:01:55 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 17 Oct 2018 12:01:55 +0100
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <f867042b-d1b0-b46b-af13-457dce5c2642@oracle.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
 <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
 <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>
 <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>
 <a3da1f43-a890-f337-310c-47c13a1f9617@oracle.com>
 <6db8e143-41e0-c1e3-2106-85afab8aee7d@oracle.com>
 <ae86957f-2f0d-4f59-76af-8c11ef0488c0@oracle.com>
 <05d52c14-a576-ef1c-516c-bd9ea3ab8c30@oracle.com>
 <f867042b-d1b0-b46b-af13-457dce5c2642@oracle.com>
Message-ID: <80c1e43b-9de4-32b9-9817-ef4720bba0ee@oracle.com>

On 12/10/18 12:58, Daniel Fuchs wrote:
> ...
> 
>  ??? int available = impl.available();
>  ??? return eof ? 0 : available;
> 
> addresses the issue of available potentially returning garbage
> after EOF while being much less risky...

Agreed.

The above resolves the original reported potential bug,
without changing existing long-standing behavior.

Vyom, can you please proceed with the aboves source
change, and also update the existing CloseAvailable.java
to add additional coverage for this scenario.

Thanks,
-Chris.

From vyom.tewari at oracle.com  Wed Oct 17 13:33:14 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Wed, 17 Oct 2018 19:03:14 +0530
Subject: RFR: 8189366: SocketInputStream.available() should check for eof
In-Reply-To: <80c1e43b-9de4-32b9-9817-ef4720bba0ee@oracle.com>
References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com>
 <AM4PR08MB1219345AC6BF9536DA456DA6FF450@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ce685f3c-e037-4f86-5365-22848d83be83@oracle.com>
 <891e188b-9d00-a1df-9842-206dcda714a7@oracle.com>
 <c4e156f4-b82c-6a2d-e709-ce55cf36752e@oracle.com>
 <aceca437-f63e-f4ea-6774-84c326a68787@oracle.com>
 <a3da1f43-a890-f337-310c-47c13a1f9617@oracle.com>
 <6db8e143-41e0-c1e3-2106-85afab8aee7d@oracle.com>
 <ae86957f-2f0d-4f59-76af-8c11ef0488c0@oracle.com>
 <05d52c14-a576-ef1c-516c-bd9ea3ab8c30@oracle.com>
 <f867042b-d1b0-b46b-af13-457dce5c2642@oracle.com>
 <80c1e43b-9de4-32b9-9817-ef4720bba0ee@oracle.com>
Message-ID: <009e898c-910a-01e3-4dc3-a8191101957d@oracle.com>

sure, i will send the webrev? soon.

Vyom


On Wednesday 17 October 2018 04:31 PM, Chris Hegarty wrote:
> On 12/10/18 12:58, Daniel Fuchs wrote:
>> ...
>>
>> ???? int available = impl.available();
>> ???? return eof ? 0 : available;
>>
>> addresses the issue of available potentially returning garbage
>> after EOF while being much less risky...
>
> Agreed.
>
> The above resolves the original reported potential bug,
> without changing existing long-standing behavior.
>
> Vyom, can you please proceed with the aboves source
> change, and also update the existing CloseAvailable.java
> to add additional coverage for this scenario.
>
> Thanks,
> -Chris.


From vyom.tewari at oracle.com  Thu Oct 18 10:05:32 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Thu, 18 Oct 2018 15:35:32 +0530
Subject: RFR:8212114 Reconsider the affect on closed streams resulting from
 8189366
Message-ID: <8daa4c3f-ccf9-b498-078c-6cf3f372f6df@oracle.com>

Hi All,

Please review the below fix.

Webrev: http://cr.openjdk.java.net/~vtewari/8212114/webrev0.0/index.html

bugId: https://bugs.openjdk.java.net/browse/JDK-8212114

this change the revert the effect of JDK-8189366,? restore the 
existing(SocketInputStream:available() will throw the socketException if 
the underline socket is closed.) long-standing behavior.

Thanks,

Vyom


From michael.x.mcmahon at oracle.com  Thu Oct 18 13:58:47 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 18 Oct 2018 14:58:47 +0100
Subject: RFR [12] 8211437: java.net.http.HttpClient hangs on 204 reply
 without Content-length 0
In-Reply-To: <5BC4AD15.1020203@oracle.com>
References: <5BC471F3.6000703@oracle.com>
 <6586e6de-b427-bf48-4cb9-f9dc75d3f03e@oracle.com>
 <5BC4AD15.1020203@oracle.com>
Message-ID: <5BC89197.9090405@oracle.com>

Updated webrev for this at 
http://cr.openjdk.java.net/~michaelm/8211437/webrev.2/index.html
based on feedback below.

I also made a change to the com.sun httpserver. It changes the recent 
fix related to the same
issue such that by default the server will not send a content-length 
back, if the user explicitly
sets one, then it will be sent. This is useful for testing this fix here.

Thanks,

Michael

On 15/10/2018, 16:07, Michael McMahon wrote:
> Hi Daniel,
>
> On 15/10/2018, 12:53, Daniel Fuchs wrote:
>> Hi Michael,
>>
>> On 15/10/2018 11:54, Michael McMahon wrote:
>>> Could I get the following fix reviewed please.
>>>
>>> http://cr.openjdk.java.net/~michaelm/8211437/webrev.1/index.html
>>
>> Looks good in general.
>>
>> In MultiExchange.java:
>>
>> 236             T nullBody = cf.get();
>>
>> Though technically the body should be available by the
>> time we reach this line, since you completed the subscriber
>> just before, we can't really make any assumption on the
>> implementation of the subscriber.
>>
>> So for the sake of robustness we should probably use
>> getBody().handle(...) to complete `result`
>> rather than calling cf.get();
>>
>
> Yes, that would be better.
>
>>
>> Also I wonder what should happen if a body is present:
>>
>> Should we simply read it instead?
>> Because if we don't then we should close the connection (HTTP/1.1)
>> or reset the stream (HTTP/2) - which probably means getting back
>> to the concrete  exchange implementation to make sure that
>> happens.
>>
>
> I see that as a protocol error. So, rather than attempting to read the
> body, I think we should ensure that the request fails (which it does
> if a content length or transfer encoding field is present). The 
> connection
> also needs to be closed (or stream reset) which I need to check is 
> being done.
>
> Thanks,
> Michael
>
>> best regards,
>>
>> -- daniel
>>
>>>
>>> Thanks,
>>>
>>> Michael.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181018/303a6eed/attachment.html>

From daniel.fuchs at oracle.com  Thu Oct 18 15:01:29 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 18 Oct 2018 16:01:29 +0100
Subject: RFR [12] 8211437: java.net.http.HttpClient hangs on 204 reply
 without Content-length 0
In-Reply-To: <5BC89197.9090405@oracle.com>
References: <5BC471F3.6000703@oracle.com>
 <6586e6de-b427-bf48-4cb9-f9dc75d3f03e@oracle.com>
 <5BC4AD15.1020203@oracle.com> <5BC89197.9090405@oracle.com>
Message-ID: <1f23898c-de13-e359-b9be-0922f89ad272@oracle.com>

Hi Michael,

Thanks for taking on all the feedback!

MultiExchange.java:

  254     if (bodyIsPresent(r)) {
  255         IOException ioe = new IOException(
  256             "unexpected content length header with 204 response");
  257         exch.cancel();
  258         return MinimalFuture.failedFuture(ioe);

I believe it would be more correct to call

              exch.cancel(ioe);

at line 257 above...


In Response204.java:

   48         Logger logger = Logger.getLogger ("com.sun.net.httpserver");
   49         ConsoleHandler c = new ConsoleHandler();
   50         c.setLevel (Level.WARNING);
   51         logger.addHandler (c);
   52         logger.setLevel (Level.WARNING);


Not that it matters much, but that is strange - I'd understand
if both Logger and ConsoleHandler were set to something below
INFO - like e.g. FINE, FINER, FINEST, or ALL?

Otherwise looks good.

IIUC Response204 tests HTTP/1.1 and NoBodyTest tests
HTTP/2.

Probably not worth it to have a test that tests all 4 flavors
of HTTP/1.1, HTTPS/1.1, HTTP/2, HTTPS/2 ?

best regards,

-- daniel


On 18/10/2018 14:58, Michael McMahon wrote:
> Updated webrev for this at 
> http://cr.openjdk.java.net/~michaelm/8211437/webrev.2/index.html
> based on feedback below.
> 
> I also made a change to the com.sun httpserver. It changes the recent 
> fix related to the same
> issue such that by default the server will not send a content-length 
> back, if the user explicitly
> sets one, then it will be sent. This is useful for testing this fix here.
> 
> Thanks,
> 
> Michael
> 
> On 15/10/2018, 16:07, Michael McMahon wrote:
>> Hi Daniel,
>>
>> On 15/10/2018, 12:53, Daniel Fuchs wrote:
>>> Hi Michael,
>>>
>>> On 15/10/2018 11:54, Michael McMahon wrote:
>>>> Could I get the following fix reviewed please.
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8211437/webrev.1/index.html
>>>
>>> Looks good in general.
>>>
>>> In MultiExchange.java:
>>>
>>> 236???????????? T nullBody = cf.get();
>>>
>>> Though technically the body should be available by the
>>> time we reach this line, since you completed the subscriber
>>> just before, we can't really make any assumption on the
>>> implementation of the subscriber.
>>>
>>> So for the sake of robustness we should probably use
>>> getBody().handle(...) to complete `result`
>>> rather than calling cf.get();
>>>
>>
>> Yes, that would be better.
>>
>>>
>>> Also I wonder what should happen if a body is present:
>>>
>>> Should we simply read it instead?
>>> Because if we don't then we should close the connection (HTTP/1.1)
>>> or reset the stream (HTTP/2) - which probably means getting back
>>> to the concrete? exchange implementation to make sure that
>>> happens.
>>>
>>
>> I see that as a protocol error. So, rather than attempting to read the
>> body, I think we should ensure that the request fails (which it does
>> if a content length or transfer encoding field is present). The 
>> connection
>> also needs to be closed (or stream reset) which I need to check is 
>> being done.
>>
>> Thanks,
>> Michael
>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Michael.
>>>


From michael.x.mcmahon at oracle.com  Thu Oct 18 15:27:27 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 18 Oct 2018 16:27:27 +0100
Subject: RFR [12] 8211437: java.net.http.HttpClient hangs on 204 reply
 without Content-length 0
In-Reply-To: <1f23898c-de13-e359-b9be-0922f89ad272@oracle.com>
References: <5BC471F3.6000703@oracle.com>
 <6586e6de-b427-bf48-4cb9-f9dc75d3f03e@oracle.com>
 <5BC4AD15.1020203@oracle.com> <5BC89197.9090405@oracle.com>
 <1f23898c-de13-e359-b9be-0922f89ad272@oracle.com>
Message-ID: <5BC8A65F.50900@oracle.com>

Hi Daniel,

On 18/10/2018, 16:01, Daniel Fuchs wrote:
> Hi Michael,
>
> Thanks for taking on all the feedback!
>
> MultiExchange.java:
>
>  254     if (bodyIsPresent(r)) {
>  255         IOException ioe = new IOException(
>  256             "unexpected content length header with 204 response");
>  257         exch.cancel();
>  258         return MinimalFuture.failedFuture(ioe);
>
> I believe it would be more correct to call
>
>              exch.cancel(ioe);
>
> at line 257 above...
>
Yes, well spotted. That was what was intended there.

Thanks,

Michael

>
> In Response204.java:
>
>   48         Logger logger = Logger.getLogger ("com.sun.net.httpserver");
>   49         ConsoleHandler c = new ConsoleHandler();
>   50         c.setLevel (Level.WARNING);
>   51         logger.addHandler (c);
>   52         logger.setLevel (Level.WARNING);
>
>
> Not that it matters much, but that is strange - I'd understand
> if both Logger and ConsoleHandler were set to something below
> INFO - like e.g. FINE, FINER, FINEST, or ALL?
>
> Otherwise looks good.
>
> IIUC Response204 tests HTTP/1.1 and NoBodyTest tests
> HTTP/2.
>
> Probably not worth it to have a test that tests all 4 flavors
> of HTTP/1.1, HTTPS/1.1, HTTP/2, HTTPS/2 ?
>
> best regards,
>
> -- daniel
>
>
> On 18/10/2018 14:58, Michael McMahon wrote:
>> Updated webrev for this at 
>> http://cr.openjdk.java.net/~michaelm/8211437/webrev.2/index.html
>> based on feedback below.
>>
>> I also made a change to the com.sun httpserver. It changes the recent 
>> fix related to the same
>> issue such that by default the server will not send a content-length 
>> back, if the user explicitly
>> sets one, then it will be sent. This is useful for testing this fix 
>> here.
>>
>> Thanks,
>>
>> Michael
>>
>> On 15/10/2018, 16:07, Michael McMahon wrote:
>>> Hi Daniel,
>>>
>>> On 15/10/2018, 12:53, Daniel Fuchs wrote:
>>>> Hi Michael,
>>>>
>>>> On 15/10/2018 11:54, Michael McMahon wrote:
>>>>> Could I get the following fix reviewed please.
>>>>>
>>>>> http://cr.openjdk.java.net/~michaelm/8211437/webrev.1/index.html
>>>>
>>>> Looks good in general.
>>>>
>>>> In MultiExchange.java:
>>>>
>>>> 236             T nullBody = cf.get();
>>>>
>>>> Though technically the body should be available by the
>>>> time we reach this line, since you completed the subscriber
>>>> just before, we can't really make any assumption on the
>>>> implementation of the subscriber.
>>>>
>>>> So for the sake of robustness we should probably use
>>>> getBody().handle(...) to complete `result`
>>>> rather than calling cf.get();
>>>>
>>>
>>> Yes, that would be better.
>>>
>>>>
>>>> Also I wonder what should happen if a body is present:
>>>>
>>>> Should we simply read it instead?
>>>> Because if we don't then we should close the connection (HTTP/1.1)
>>>> or reset the stream (HTTP/2) - which probably means getting back
>>>> to the concrete  exchange implementation to make sure that
>>>> happens.
>>>>
>>>
>>> I see that as a protocol error. So, rather than attempting to read the
>>> body, I think we should ensure that the request fails (which it does
>>> if a content length or transfer encoding field is present). The 
>>> connection
>>> also needs to be closed (or stream reset) which I need to check is 
>>> being done.
>>>
>>> Thanks,
>>> Michael
>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Michael.
>>>>
>

From chris.hegarty at oracle.com  Fri Oct 19 10:22:18 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 19 Oct 2018 11:22:18 +0100
Subject: RFR:8212114 Reconsider the affect on closed streams resulting
 from 8189366
In-Reply-To: <8daa4c3f-ccf9-b498-078c-6cf3f372f6df@oracle.com>
References: <8daa4c3f-ccf9-b498-078c-6cf3f372f6df@oracle.com>
Message-ID: <46F58897-1E0E-4D4F-8F52-86E6EB232D00@oracle.com>


> On 18 Oct 2018, at 11:05, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi All,
> 
> Please review the below fix.
> 
> Webrev: http://cr.openjdk.java.net/~vtewari/8212114/webrev0.0/index.html <http://cr.openjdk.java.net/~vtewari/8212114/webrev0.0/index.html>

Looks good to me. Thanks Vyom.

-Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181019/f5f5721e/attachment.html>

From daniel.fuchs at oracle.com  Fri Oct 19 10:26:16 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 19 Oct 2018 11:26:16 +0100
Subject: RFR:8212114 Reconsider the affect on closed streams resulting
 from 8189366
In-Reply-To: <8daa4c3f-ccf9-b498-078c-6cf3f372f6df@oracle.com>
References: <8daa4c3f-ccf9-b498-078c-6cf3f372f6df@oracle.com>
Message-ID: <9f4fa8ef-2c41-ba5e-1519-5eecefdd54df@oracle.com>

Hi Vyom,

This looks good to me as well.

best regards,

-- daniel

On 18/10/2018 11:05, vyom tewari wrote:
> Hi All,
> 
> Please review the below fix.
> 
> Webrev: http://cr.openjdk.java.net/~vtewari/8212114/webrev0.0/index.html
> 
> bugId: https://bugs.openjdk.java.net/browse/JDK-8212114
> 
> this change the revert the effect of JDK-8189366,? restore the 
> existing(SocketInputStream:available() will throw the socketException if 
> the underline socket is closed.) long-standing behavior.
> 
> Thanks,
> 
> Vyom
> 


From chris.hegarty at oracle.com  Fri Oct 19 16:12:45 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 19 Oct 2018 17:12:45 +0100
Subject: RFR [12] 8212695: Add explicit timeout to several HTTP Client tests
Message-ID: <248DBC3C-E737-4CC6-A04A-C5791B144D95@oracle.com>

There has been a recent change to Oracle's internal test environment
that now causes a couple of HTTP Client tests to timeout before they
have had a chance to complete their execution, resulting in what
( incorrectly ) appears as a test failure / error. The solution is for
these tests to specify an explicit relatively long timeout, so that they
are allow enough time to run on extremely slow systems. 

The tests in question are:
  test/jdk/java/net/httpclient/DigestEchoClientSSL.java 
  test/jdk/java/net/httpclient/ProxyAuthDisabledSchemesSSL.java 

Webrev:
  http://cr.openjdk.java.net/~chegar/8212695/

-Chris.

From michael.x.mcmahon at oracle.com  Fri Oct 19 16:23:59 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 19 Oct 2018 17:23:59 +0100
Subject: RFR [12] 8212695: Add explicit timeout to several HTTP Client
 tests
In-Reply-To: <248DBC3C-E737-4CC6-A04A-C5791B144D95@oracle.com>
References: <248DBC3C-E737-4CC6-A04A-C5791B144D95@oracle.com>
Message-ID: <5BCA051F.3030304@oracle.com>

Looks fine Chris.

- Michael

On 19/10/2018, 17:12, Chris Hegarty wrote:
> There has been a recent change to Oracle's internal test environment
> that now causes a couple of HTTP Client tests to timeout before they
> have had a chance to complete their execution, resulting in what
> ( incorrectly ) appears as a test failure / error. The solution is for
> these tests to specify an explicit relatively long timeout, so that they
> are allow enough time to run on extremely slow systems.
>
> The tests in question are:
>    test/jdk/java/net/httpclient/DigestEchoClientSSL.java
>    test/jdk/java/net/httpclient/ProxyAuthDisabledSchemesSSL.java
>
> Webrev:
>    http://cr.openjdk.java.net/~chegar/8212695/
>
> -Chris.

From daniel.fuchs at oracle.com  Fri Oct 19 16:32:50 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 19 Oct 2018 17:32:50 +0100
Subject: RFR [12] 8212695: Add explicit timeout to several HTTP Client
 tests
In-Reply-To: <248DBC3C-E737-4CC6-A04A-C5791B144D95@oracle.com>
References: <248DBC3C-E737-4CC6-A04A-C5791B144D95@oracle.com>
Message-ID: <6e769193-9da6-20a7-2d2a-fbfa512eaa35@oracle.com>

Hi Chris,

Looks good to me.

best regards,

-- daniel

On 19/10/2018 17:12, Chris Hegarty wrote:
> There has been a recent change to Oracle's internal test environment
> that now causes a couple of HTTP Client tests to timeout before they
> have had a chance to complete their execution, resulting in what
> ( incorrectly ) appears as a test failure / error. The solution is for
> these tests to specify an explicit relatively long timeout, so that they
> are allow enough time to run on extremely slow systems.
> 
> The tests in question are:
>    test/jdk/java/net/httpclient/DigestEchoClientSSL.java
>    test/jdk/java/net/httpclient/ProxyAuthDisabledSchemesSSL.java
> 
> Webrev:
>    http://cr.openjdk.java.net/~chegar/8212695/
> 
> -Chris.
> 


From michael.x.mcmahon at oracle.com  Thu Oct 25 09:27:46 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 25 Oct 2018 10:27:46 +0100
Subject: RFR: 8212926  HttpClient does not retrieve files with large sizes
 over HTTP/1.1
Message-ID: <5BD18C92.8010803@oracle.com>

Hi,

Could I get the following change reviewed please?

http://cr.openjdk.java.net/~michaelm/8212926/webrev.1/index.html

We would like to backport it to jdk11u also.

Thanks,
Michael

From chris.hegarty at oracle.com  Thu Oct 25 10:05:17 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 25 Oct 2018 11:05:17 +0100
Subject: RFR: 8212926 HttpClient does not retrieve files with large sizes
 over HTTP/1.1
In-Reply-To: <5BD18C92.8010803@oracle.com>
References: <5BD18C92.8010803@oracle.com>
Message-ID: <8C476E6D-B6D1-435E-A952-EC8A5FAB1ABE@oracle.com>



> On 25 Oct 2018, at 10:27, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> 
> Hi,
> 
> Could I get the following change reviewed please?
> 
> http://cr.openjdk.java.net/~michaelm/8212926/webrev.1/index.html <http://cr.openjdk.java.net/~michaelm/8212926/webrev.1/index.html>

I think this is good. Thanks Michael.

-Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181025/16c9065d/attachment.html>

From daniel.fuchs at oracle.com  Thu Oct 25 10:13:09 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 25 Oct 2018 11:13:09 +0100
Subject: RFR: 8212926 HttpClient does not retrieve files with large sizes
 over HTTP/1.1
In-Reply-To: <8C476E6D-B6D1-435E-A952-EC8A5FAB1ABE@oracle.com>
References: <5BD18C92.8010803@oracle.com>
 <8C476E6D-B6D1-435E-A952-EC8A5FAB1ABE@oracle.com>
Message-ID: <f058ea9e-f301-8e8f-072a-8512e7da9454@oracle.com>

On 25/10/2018 11:05, Chris Hegarty wrote:
>> Could I get the following change reviewed please?
>>
>> http://cr.openjdk.java.net/~michaelm/8212926/webrev.1/index.html 
>> <http://cr.openjdk.java.net/%7Emichaelm/8212926/webrev.1/index.html>
> 
> I think this is good. Thanks Michael.

+1

-- daniel


From xuelei.fan at oracle.com  Tue Oct 30 20:55:10 2018
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 30 Oct 2018 13:55:10 -0700
Subject: A new proposal to add methods to HttpsURLConnection to access
 SSLSession
Message-ID: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com>

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 
negotiated TLS protocol version.

Please let me know if you have concerns to add a new method 
HttpsURLConnection.getSSLSession() and deprecate the duplicated methods, 
by the end of Nov. 2, 2018.

Here is the proposal:
     https://bugs.openjdk.java.net/browse/JDK-8213161

Thanks,
Xuelei




From chris.hegarty at oracle.com  Wed Oct 31 15:52:29 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 31 Oct 2018 15:52:29 +0000
Subject: A new proposal to add methods to HttpsURLConnection to access
 SSLSession
In-Reply-To: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com>
References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com>
Message-ID: <e1999df5-5b14-dd4e-4644-ceaa3254e216@oracle.com>

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 
> negotiated TLS protocol version.
> 
> Please let me know if you have concerns to add a new method 
> HttpsURLConnection.getSSLSession() and deprecate the duplicated methods, 
> by the end of Nov. 2, 2018.
> 
> Here is the proposal:
>  ??? https://bugs.openjdk.java.net/browse/JDK-8213161
> 
> Thanks,
> Xuelei

The new method looks fine.

On the deprecation, minimally the annotation should contain
the "since" element, which will have a value of `12`.

Also, I wonder, now that I see the spec, whether or not it is
actually a good idea to deprecate these methods. The reason
I ask this is that the new method, getSSLSession, can throw
UOE, which effectively makes it an optional method. Access
to the specific security parameters provided by the existing
methods is non-optional. This is a clear difference, and
possibly a reason, for folk not interested in the "new"
parameters, to continue to use the existing methods.

-Chris

From anders at featureshock.com  Wed Oct 31 16:31:16 2018
From: anders at featureshock.com (=?UTF-8?Q?Anders_Wisch?=)
Date: Wed, 31 Oct 2018 16:31:16 +0000
Subject: Date header and Java 11 HTTP client
References: <E32210F9-16CB-4938-BAB5-8F286110F087@featureshock.com>
Message-ID: <01010166caf6ffe1-86a10e37-976f-40be-8013-9c324ee578e4-000000@us-west-2.amazonses.com>

Hi all,

Why does the new Java 11 HTTP client disallow sending the date header (https://tools.ietf.org/html/rfc7231#section-7.1.1.2) with a request? I was excited to convert a bunch of code to use the new built-in HTTP client, and by chance, the first use case I picked was this:

String date = Http.toHttpDate(Instant.now());
String sessionToken = credentials.sessionToken();
String signature = signRequest(uri, date, sessionToken, credentials.secretAccessKey());
return httpClient.send(HttpRequest.newBuilder(uri).GET()
? ? ? ? .header("Date", date)
? ? ? ? .header("Authorization", "AWS " + credentials.accessKeyId() + ':' + signature)
? ? ? ? .header("x-amz-security-token", sessionToken)
? ? ? ? .build(), HttpResponse.BodyHandlers.ofByteArray());

This snippet is following AWS?s instructions here -?https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#UsingTemporarySecurityCredentials?- on how to use temporary credentials to sign a request to S3. Since the date header is part of what we?re signing, we need to either define or obtain its value (though the new client doesn?t send it). I found only one person on the net-dev mailing list discussing the date header (specifically why he thought it shouldn?t be restricted):?http://mail.openjdk.java.net/pipermail/net-dev/2016-March/009608.html <http://mail.openjdk.java.net/pipermail/net-dev/2016-March/009608.html> 

Thanks,
Anders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181031/b6838b17/attachment.html>

From openjdk at suche.org  Wed Oct 31 17:46:08 2018
From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=)
Date: Wed, 31 Oct 2018 18:46:08 +0100
Subject: Date header and Java 11 HTTP client
In-Reply-To: <01010166caf6ffe1-86a10e37-976f-40be-8013-9c324ee578e4-000000@us-west-2.amazonses.com>
References: <E32210F9-16CB-4938-BAB5-8F286110F087@featureshock.com>
 <01010166caf6ffe1-86a10e37-976f-40be-8013-9c324ee578e4-000000@us-west-2.amazonses.com>
Message-ID: <12d5889b-cde0-950c-2f33-ad8ab4c23315@suche.org>

Hi all,

from the count of problems that are upcomming with these limits.
I think there should be an switch to allowing all header. Because why 
limit them?
Anyone who wan't to misuse them can to it via plain "Socket" or 
SslSocket without limit.
I think there are more samples why these limit is bad. So simply remove 
that check at all.
And allow any header.

Gru? Thomas

On 31.10.2018 17:31:16, Anders Wisch wrote:
> Hi all,
>
> Why does the new Java 11 HTTP client disallow sending the date header 
> (https://tools.ietf.org/html/rfc7231#section-7.1.1.2) with a request? 
> I was excited to convert a bunch of code to use the new built-in HTTP 
> client, and by chance, the first use case I picked was this:
>
>     String date = Http.toHttpDate(Instant.now());
>     String sessionToken = credentials.sessionToken();
>     String signature = signRequest(uri, date, sessionToken,
>     credentials.secretAccessKey());
>     return httpClient.send(HttpRequest.newBuilder(uri).GET()
>     .header("Date", date)
>     .header("Authorization", "AWS " + credentials.accessKeyId() + ':'
>     + signature)
>     .header("x-amz-security-token", sessionToken)
>     .build(), HttpResponse.BodyHandlers.ofByteArray());
>
>
> This snippet is following AWS?s instructions here - 
> https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#UsingTemporarySecurityCredentials?- 
> on how to use temporary credentials to sign a request to S3. Since the 
> date header is part of what we?re signing, we need to either define or 
> obtain its value (though the new client doesn?t send it). I found only 
> one person on the net-dev mailing list discussing the date header 
> (specifically why he thought it shouldn?t be restricted): 
> http://mail.openjdk.java.net/pipermail/net-dev/2016-March/009608.html
>
> Thanks,
> Anders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181031/cccd8dc6/attachment.html>

From michael.x.mcmahon at oracle.com  Wed Oct 31 17:49:49 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 31 Oct 2018 17:49:49 +0000
Subject: Date header and Java 11 HTTP client
In-Reply-To: <12d5889b-cde0-950c-2f33-ad8ab4c23315@suche.org>
References: <E32210F9-16CB-4938-BAB5-8F286110F087@featureshock.com>
 <01010166caf6ffe1-86a10e37-976f-40be-8013-9c324ee578e4-000000@us-west-2.amazonses.com>
 <12d5889b-cde0-950c-2f33-ad8ab4c23315@suche.org>
Message-ID: <5BD9EB3D.8070600@oracle.com>

We have filed

https://bugs.openjdk.java.net/browse/JDK-8213189
"Make restricted headers in HTTP Client configurable and remove Date by 
default"

which should deal with this finally.

- Michael


On 31/10/2018, 17:46, Thomas Lu?nig wrote:
>
> Hi all,
>
> from the count of problems that are upcomming with these limits.
> I think there should be an switch to allowing all header. Because why 
> limit them?
> Anyone who wan't to misuse them can to it via plain "Socket" or 
> SslSocket without limit.
> I think there are more samples why these limit is bad. So simply 
> remove that check at all.
> And allow any header.
>
> Gru? Thomas
>
> On 31.10.2018 17:31:16, Anders Wisch wrote:
>> Hi all,
>>
>> Why does the new Java 11 HTTP client disallow sending the date header 
>> (https://tools.ietf.org/html/rfc7231#section-7.1.1.2) with a request? 
>> I was excited to convert a bunch of code to use the new built-in HTTP 
>> client, and by chance, the first use case I picked was this:
>>
>>     String date = Http.toHttpDate(Instant.now());
>>     String sessionToken = credentials.sessionToken();
>>     String signature = signRequest(uri, date, sessionToken,
>>     credentials.secretAccessKey());
>>     return httpClient.send(HttpRequest.newBuilder(uri).GET()
>>             .header("Date", date)
>>             .header("Authorization", "AWS " +
>>     credentials.accessKeyId() + ':' + signature)
>>             .header("x-amz-security-token", sessionToken)
>>             .build(), HttpResponse.BodyHandlers.ofByteArray());
>>
>>
>> This snippet is following AWS?s instructions here - 
>> https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#UsingTemporarySecurityCredentials - 
>> on how to use temporary credentials to sign a request to S3. Since 
>> the date header is part of what we?re signing, we need to either 
>> define or obtain its value (though the new client doesn?t send it). I 
>> found only one person on the net-dev mailing list discussing the date 
>> header (specifically why he thought it shouldn?t be restricted): 
>> http://mail.openjdk.java.net/pipermail/net-dev/2016-March/009608.html
>>
>> Thanks,
>> Anders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181031/7cb7d395/attachment-0001.html>

From brian.burkhalter at oracle.com  Wed Oct 31 19:13:12 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 31 Oct 2018 12:13:12 -0700
Subject: 8213210: Change ServerSocket(SocketImpl impl) constructor to
 protected access
Message-ID: <135B35F7-4EE0-410D-BD80-0FC1D94B37D9@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8213210

Please see diff included below. CSR to follow.

Thanks,

Brian

--- a/src/java.base/share/classes/java/net/ServerSocket.java
+++ b/src/java.base/share/classes/java/net/ServerSocket.java
@@ -76,10 +76,13 @@
     private boolean oldImpl = false;
 
     /**
-     * Package-private constructor to create a ServerSocket associated with
-     * the given SocketImpl.
+     * Creates a server socket with a user-specified {@code SocketImpl}.
+     *
+     * @param      impl an instance of a SocketImpl the subclass
+     *             wishes to use on the ServerSocket.
+     * @since 12
      */
-    ServerSocket(SocketImpl impl) {
+    protected ServerSocket(SocketImpl impl) {
         this.impl = impl;
         impl.setServerSocket(this);
     }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181031/2d05f2d4/attachment.html>

From Alan.Bateman at oracle.com  Wed Oct 31 19:16:06 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 Oct 2018 19:16:06 +0000
Subject: 8213210: Change ServerSocket(SocketImpl impl) constructor to
 protected access
In-Reply-To: <135B35F7-4EE0-410D-BD80-0FC1D94B37D9@oracle.com>
References: <135B35F7-4EE0-410D-BD80-0FC1D94B37D9@oracle.com>
Message-ID: <f006f783-9c55-5df8-eae0-422e955208af@oracle.com>

On 31/10/2018 19:13, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8213210
>
> Please see diff included below. CSR to follow.
One thing to check is whether ServerSocket specifies null handling 
anywhere. I don't think it does so you might have to add an @throws NPE.

-Alan

From brian.burkhalter at oracle.com  Wed Oct 31 19:20:49 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 31 Oct 2018 12:20:49 -0700
Subject: 8213210: Change ServerSocket(SocketImpl impl) constructor to
 protected access
In-Reply-To: <f006f783-9c55-5df8-eae0-422e955208af@oracle.com>
References: <135B35F7-4EE0-410D-BD80-0FC1D94B37D9@oracle.com>
 <f006f783-9c55-5df8-eae0-422e955208af@oracle.com>
Message-ID: <384A19A6-EAB2-4F54-8D2C-E3823B2D324E@oracle.com>


> On Oct 31, 2018, at 12:16 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 31/10/2018 19:13, Brian Burkhalter wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8213210 <https://bugs.openjdk.java.net/browse/JDK-8213210>
>> 
>> Please see diff included below. CSR to follow.
> One thing to check is whether ServerSocket specifies null handling anywhere. I don't think it does so you might have to add an @throws NPE.

SocketImpl.serServerSocket() cannot throw NPE so I don?t see that the updated ctor can throw it either:

    void setServerSocket(ServerSocket soc) {
        this.serverSocket = soc;
    }

-    ServerSocket(SocketImpl impl) {
+    protected ServerSocket(SocketImpl impl) {
         this.impl = impl;
         impl.setServerSocket(this);
     }

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181031/c3175fa2/attachment.html>

From brian.burkhalter at oracle.com  Wed Oct 31 19:26:41 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 31 Oct 2018 12:26:41 -0700
Subject: 8213210: Change ServerSocket(SocketImpl impl) constructor to
 protected access
In-Reply-To: <384A19A6-EAB2-4F54-8D2C-E3823B2D324E@oracle.com>
References: <135B35F7-4EE0-410D-BD80-0FC1D94B37D9@oracle.com>
 <f006f783-9c55-5df8-eae0-422e955208af@oracle.com>
 <384A19A6-EAB2-4F54-8D2C-E3823B2D324E@oracle.com>
Message-ID: <9D8F9DE2-6573-4850-8E32-3A41C69BE3DC@oracle.com>


> On Oct 31, 2018, at 12:20 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> -    ServerSocket(SocketImpl impl) {
> +    protected ServerSocket(SocketImpl impl) {
>          this.impl = impl;
>          impl.setServerSocket(this); // <- NPE if impl == null
>      }

Oops, it can throw null as indicated above. Revised patch below.

Brian

--- a/src/java.base/share/classes/java/net/ServerSocket.java
+++ b/src/java.base/share/classes/java/net/ServerSocket.java
@@ -76,10 +76,16 @@
     private boolean oldImpl = false;
 
     /**
-     * Package-private constructor to create a ServerSocket associated with
-     * the given SocketImpl.
+     * Creates a server socket with a user-specified {@code SocketImpl}.
+     *
+     * @param      impl an instance of a SocketImpl the subclass
+     *             wishes to use on the ServerSocket.
+     *
+     * @throws     NullPointerException if impl is {@code null}
+     *
+     * @since 12
      */
-    ServerSocket(SocketImpl impl) {
+    protected ServerSocket(SocketImpl impl) {
         this.impl = impl;
         impl.setServerSocket(this);
     }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181031/5eb725f3/attachment-0001.html>

From Alan.Bateman at oracle.com  Wed Oct 31 19:32:45 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 Oct 2018 19:32:45 +0000
Subject: 8213210: Change ServerSocket(SocketImpl impl) constructor to
 protected access
In-Reply-To: <9D8F9DE2-6573-4850-8E32-3A41C69BE3DC@oracle.com>
References: <135B35F7-4EE0-410D-BD80-0FC1D94B37D9@oracle.com>
 <f006f783-9c55-5df8-eae0-422e955208af@oracle.com>
 <384A19A6-EAB2-4F54-8D2C-E3823B2D324E@oracle.com>
 <9D8F9DE2-6573-4850-8E32-3A41C69BE3DC@oracle.com>
Message-ID: <90c92368-b533-7a27-00c0-82457e8b943e@oracle.com>

On 31/10/2018 19:26, Brian Burkhalter wrote:
>
>> On Oct 31, 2018, at 12:20 PM, Brian Burkhalter 
>> <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>>
>> - ? ServerSocket(SocketImpl impl) {
>> + ? protected ServerSocket(SocketImpl impl) {
>> ? ? ? this.impl = impl;
>> ? ? ? impl.setServerSocket(this); // <- NPE if impl == null
>> ? }
>
> Oops, it can throw null as indicated above. Revised patch below.
>
Good, I think looks okay.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181031/0392aebd/attachment.html>

From xuelei.fan at oracle.com  Wed Oct 31 20:03:05 2018
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 31 Oct 2018 13:03:05 -0700
Subject: A new proposal to add methods to HttpsURLConnection to access
 SSLSession
In-Reply-To: <e1999df5-5b14-dd4e-4644-ceaa3254e216@oracle.com>
References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com>
 <e1999df5-5b14-dd4e-4644-ceaa3254e216@oracle.com>
Message-ID: <55db048d-b47e-deec-839d-ae25e2c70982@oracle.com>

On 10/31/2018 8: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 
>> negotiated TLS protocol version.
>>
>> Please let me know if you have concerns to add a new method 
>> HttpsURLConnection.getSSLSession() and deprecate the duplicated 
>> methods, by the end of Nov. 2, 2018.
>>
>> Here is the proposal:
>> ???? https://bugs.openjdk.java.net/browse/JDK-8213161
>>
>> Thanks,
>> Xuelei
> 
> The new method looks fine.
> 
> On the deprecation, minimally the annotation should contain
> the "since" element, which will have a value of `12`.
> 
Hm, it looks better now if using the "since" element.  Thanks!

> Also, I wonder, now that I see the spec, whether or not it is
> actually a good idea to deprecate these methods. The reason
> I ask this is that the new method, getSSLSession, can throw
> UOE, which effectively makes it an optional method. Access
> to the specific security parameters provided by the existing
> methods is non-optional. This is a clear difference, and
> possibly a reason, for folk not interested in the "new"
> parameters, to continue to use the existing methods.
> 
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 example to access 
the negotiated TLS version, this operation is essential to it. 
Unfortunately, because of compatibility impact, we cannot force all 
implementation supports this new added operation.  It is a potential 
problem to those applications that need it.

It would be nice if an implementation can support this operation as soon 
as possible.  If we just add the operation, providers may not aware 
there is a need to update their implementation.  Unfortunately. there is 
not much we can do to notify the provider.

If we deprecated the duplicated methods, it is easier for providers to 
catch up with this new added operation, and move forward to support it. 
As the deprecating will show up building warnings, or even error if run 
in strict building mode.

To make it more clear, I added a implNote in the getSSLSession() method, 
and recommend to support it in all implementations.

I prefer to deprecate these methods a little bit more, but not very 
strong.  If there is a strong preference, I can live with it.

BTW, I also updated the java.net.SecureCacheResponse accordingly.  I'm 
not sure if SecureCacheResponse is really used in practice.  I did not 
find the implementation of it in JDK.

Here is the webrev if you want to look at the implementation details:
     http://cr.openjdk.java.net/~xuelei/8212261/webrev.00/

Thanks,
Xuelei

From chris.hegarty at oracle.com  Wed Oct 31 20:47:36 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 31 Oct 2018 20:47:36 +0000
Subject: Date header and Java 11 HTTP client
In-Reply-To: <5BD9EB3D.8070600@oracle.com>
References: <E32210F9-16CB-4938-BAB5-8F286110F087@featureshock.com>
 <01010166caf6ffe1-86a10e37-976f-40be-8013-9c324ee578e4-000000@us-west-2.amazonses.com>
 <12d5889b-cde0-950c-2f33-ad8ab4c23315@suche.org>
 <5BD9EB3D.8070600@oracle.com>
Message-ID: <8B543076-8D03-4A1F-B42B-4049ED503CA2@oracle.com>



> On 31 Oct 2018, at 17:49, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> 
> We have filed 
> 
> https://bugs.openjdk.java.net/browse/JDK-8213189 <https://bugs.openjdk.java.net/browse/JDK-8213189>
> "Make restricted headers in HTTP Client configurable and remove Date by default"
> 
> which should deal with this finally.

Additionally ...

Until the above issue can be resolved, it is possible to
use `x-amz-date` as an alternative to the `Date` header,
for the purposes of signing and authenticating REST
requests with Amazon Sx.

-Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181031/cd20ceb3/attachment.html>

From chris.hegarty at oracle.com  Wed Oct 31 20:53:02 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 31 Oct 2018 20:53:02 +0000
Subject: 8213210: Change ServerSocket(SocketImpl impl) constructor to
 protected access
In-Reply-To: <9D8F9DE2-6573-4850-8E32-3A41C69BE3DC@oracle.com>
References: <135B35F7-4EE0-410D-BD80-0FC1D94B37D9@oracle.com>
 <f006f783-9c55-5df8-eae0-422e955208af@oracle.com>
 <384A19A6-EAB2-4F54-8D2C-E3823B2D324E@oracle.com>
 <9D8F9DE2-6573-4850-8E32-3A41C69BE3DC@oracle.com>
Message-ID: <19C329FA-DC2A-4D58-A336-5839F317EB79@oracle.com>



> On 31 Oct 2018, at 19:26, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> ...
> 
> --- a/src/java.base/share/classes/java/net/ServerSocket.java
> +++ b/src/java.base/share/classes/java/net/ServerSocket.java
> @@ -76,10 +76,16 @@
>      private boolean oldImpl = false;
>  
>      /**
> -     * Package-private constructor to create a ServerSocket associated with
> -     * the given SocketImpl.
> +     * Creates a server socket with a user-specified {@code SocketImpl}.
> +     *
> +     * @param      impl an instance of a SocketImpl the subclass
> +     *             wishes to use on the ServerSocket.
> +     *
> +     * @throws     NullPointerException if impl is {@code null}
> +     *
> +     * @since 12
>       */
> -    ServerSocket(SocketImpl impl) {
> +    protected ServerSocket(SocketImpl impl) {
>          this.impl = impl;
>          impl.setServerSocket(this);
>      }

I think this is good. I added myself as reviewer on the CSR too.

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20181031/a1b1cdc0/attachment-0001.html>