Re: Public API to get the search list that is used on the system

Norman, > On 26 Sep 2018, at 12:45, Norman Maurer wrote: > > BTW I am happy to open an enhancement request for this with more details . > Just wanted to check in first here :) I searched the bug database to ensure that this request had not come up before, and found nothing. I took the liberty

Re: RFR [12] 8211092: test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java fails intermittently when cleaning up

should not return until all of its worker threads have completed. This validates the assertions in the tests, as well as not putting jtreg under pressure to do cleanup. http://cr.openjdk.java.net/~chegar/8211092.01/ -Chris. > On 25 Sep 2018, at 14:49, Chris Hegarty wrote: > > Than

Re: Public API to get the search list that is used on the system

>> wrote: >> >> Thanks a lot. >> >> That would provide exactly what we need in netty. >> >> Bye >> Norman >> >> >>> On 27. Sep 2018, at 12:09, Chris Hegarty wrote: >>> >>> Norman, >>> >>>>

Re: RFR [12] 8211092: test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java fails intermittently when cleaning up

On 27/09/18 14:28, Daniel Fuchs wrote: Hi Chris, Good finding! I agree with the principle, but I think that strictly speaking it would be more correct if the server's workers ArrayList was changed into a ConcurrentLinkedQueue. The main could then poll the queue & join until it's empty (or al

RFR [12] 8209454: [error-prone] TypeParameterUnusedInFormals in jdk.net

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

RFR [12] 8211325: test/jdk/java/net/Socket/LingerTest.java fails with cleaning up

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 t

Re: RFR [12] 8211325: test/jdk/java/net/Socket/LingerTest.java fails with cleaning up

> On 1 Oct 2018, at 16:42, Daniel Fuchs 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

Re: RFR [12] 8209454: [error-prone] TypeParameterUnusedInFormals in jdk.net

> On 1 Oct 2018, at 16:38, Daniel Fuchs 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 checkValueType(Object value, Class) { } Good suggestion. So the full diff is: --- a/src/jdk.net/sha

Re: RFR [12] 8211349: Bad HTML in {@link} for HttpResponse.BodyHandlers.ofPublisher

> On 2 Oct 2018, at 11:48, Daniel Fuchs 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/webre

Re: RFR: 8211420: com.sun.net.httpserver.HttpServer returns Content-length header for 204 response code

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

RFR [12] 8211902: broken link in java.net.http.WebSocket.Builder

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 @@ * {@link SecurityException} - * if a sec

Re: RFR [12] 8211902: broken link in java.net.http.WebSocket.Builder

> On 9 Oct 2018, at 12:37, Daniel Fuchs 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.

RFR [12] 8211927: Add additional diagnostic information to java/net/BindException/Test.java

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

Re: RFR [12] 8212000: Verify exported symbols in java.base (libnet, libnio/ch)

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.

Re: RFR: 8189366: SocketInputStream.available() should check for eof

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/webr

Re: [12] RFR 8187522: sun/net/ftp/FtpURLConnectionLeak.Java timed out

Chris Y, > On 11 Oct 2018, at 09:45, 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 expec

Re: [12] RFR 8187522: sun/net/ftp/FtpURLConnectionLeak.Java timed out

> On 11 Oct 2018, at 12:02, vyom tewari 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 eve

Re: RFR [12]: 8203850: java.net.http HTTP client should allow specifying Origin and Referer headers

> On 11 Oct 2018, at 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. +1 -Chris.

Re: RFR: 8189366: SocketInputStream.available() should check for eof

> On 11 Oct 2018, at 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. Thanks. I think this is good. -Chris.

Re: RFR [12]: 8203850: java.net.http HTTP client should allow specifying Origin and Referer headers

> On 11 Oct 2018, at 18:05, Daniel Fuchs 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 detec

Re: RFR: 8189366: SocketInputStream.available() should check for eof

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 c

Re: [12] RFR 8187522: sun/net/ftp/FtpURLConnectionLeak.Java timed out

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

Re: RFR: 8189366: SocketInputStream.available() should check for eof

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

Re: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary

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

Re: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary

On 15/10/18 11:07, sha.ji...@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 p

Re: RFR: 8189366: SocketInputStream.available() should check for eof

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 c

Re: RFR:8212114 Reconsider the affect on closed streams resulting from 8189366

> On 18 Oct 2018, at 11:05, vyom tewari wrote: > > Hi All, > > Please review the below fix. > > Webrev: http://cr.openjdk.java.net/~vtewari/8212114/webrev0.0/index.html > Looks good to me. Thanks Vyom. -Chris.

RFR [12] 8212695: Add explicit timeout to several HTTP Client tests

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

Re: RFR: 8212926 HttpClient does not retrieve files with large sizes over HTTP/1.1

> On 25 Oct 2018, at 10:27, Michael McMahon > wrote: > > Hi, > > Could I get the following change reviewed please? > > http://cr.openjdk.java.net/~michaelm/8212926/webrev.1/index.html > I think this is good. Thanks Michael.

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

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

Re: Date header and Java 11 HTTP client

> On 31 Oct 2018, at 17:49, Michael McMahon > wrote: > > 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

Re: 8213210: Change ServerSocket(SocketImpl impl) constructor to protected access

> On 31 Oct 2018, at 19:26, Brian Burkhalter > 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

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

> On 31 Oct 2018, at 20:03, Xuelei Fan wrote: >> ... > Yes. I had the same concern about the optional operation. However, I came > to a different conclusion if I'm from viewpoint of these users that need to > use this new operation. > > If an application have to use this new operation, for e

Re: Option to supply custom hostname verifier to HTTP client

In order to evaluate this request, can you please provide use-cases for such. What “secure” server are you trying to connect to that is unwilling to identify itself in its certificate. -Chris. > On 1 Nov 2018, at 17:48, Anders Wisch wrote: > > Hi all, > > I think it should be possible to suppl

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

Thanks for the updates Xuelei, some minor comments inline.. > On 1 Nov 2018, at 23:42, Xuelei Fan wrote: > > On 11/1/2018 11:24 AM, Sean Mullan wrote: >> On 10/31/18 11:52 AM, Chris Hegarty wrote: >>> Xuelei, >>> >>> On 30/10/18 20:55, Xuelei Fan

RFR [12] 8213296: Fix legal headers in test/jdk/java/net

Following Jon’s lead in the langtools area, here is a change to remove the "Classpath exception” from several test in the networking area. http://cr.openjdk.java.net/~chegar/8213296/webrev/ -Chris.

Re: Option to supply custom hostname verifier to HTTP client

Thanks for the additional information, we will review it. For tracking purposes I filed the follow JIRA. It should not be confused with a commitment to add such an API point, its resolution may indeed be ‘will not fix’, but it will contain a summary and record of the discussion and ultimate conclu

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

> On 5 Nov 2018, at 18:52, Xuelei Fan wrote: > > Hi Chris and Sean, > > There are a few feedback for the CSR approval. I updated to use > Optional for the returned value. For more details, please refer > to: > https://bugs.openjdk.java.net/browse/JDK-8213161 > http://cr.openjdk.java.net/

RFR [12] 8213418: Socket/ServerSocket supportedOptions does not work with custom SocketImpl

Socket and ServerSocket supportedOptions() caches the supported options in a static field on the assumption that all implementations support the same set of options. This assumption is incorrect. The cache can be on a per-socket basis ( which has been implemented in the webrev ), or maybe even re

Re: RFR [12] 8210493: Bind to node- or linklocal ipv6 multicast address fails

On 07/11/18 14:12, Pavel Rappo wrote: Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8210493/webrev.00 Thanks for doing this Pavel. The changes in the webrev look good to me. -Chris.

Re: RFR [12] 8213418: Socket/ServerSocket supportedOptions does not work with custom SocketImpl

On 08/11/18 08:22, Alan Bateman wrote: ... Right, the caching, if any, has to be per instance in order to work with different SocketImpl implementations. The change drops the synchronization and so brings up the question as to whether this method is thread safe or not. One simple approach (a

Re: JDK-7014531

Gerd, On 07/11/18 15:24, MUELLER-SCHRAMM Gerd wrote: Hi, I’ve got a question regarding JDK-7014531 . This bug is still open and after checking it against Java 11 still valid. Will it ever be fixed? > I’ve took a look at the source code and t

Re: RFR:8046500 GetIpAddrTable function failed on Pure Ipv6 environment

Hi Vyom, On 08/11/18 09:22, vyom tewari wrote: Hi, Please review the below code change. Webrev: http://cr.openjdk.java.net/~vtewari/8046500/webrev0.0/index.html enumInterfaces may return -1 for error conditions other than IP Helper Library GetIfTable function failed. I wonder if this specifi

Re: RFR [12] 8213418: Socket/ServerSocket supportedOptions does not work with custom SocketImpl

On 08/11/18 11:53, Chris Hegarty wrote: ... Received some offline comments about the use of VarHandle. Removed the superfluous use of VarHandle, we now implicitly trust the socket impl ( even more ). http://cr.openjdk.java.net/~chegar/8213418/webrev.02/ -Chris.

Re: RFR [12] 8210493: Bind to node- or linklocal ipv6 multicast address fails

On 09/11/18 14:33, Pavel Rappo wrote: Alan, Chris, Thanks for reviewing this change. However, before the push I tested it again and found out that there is a small number of Linux machines on which both tests fail. The only thing I found to be in common between these machines was the version of

Re: RFR 8213616 URLPermission with query or fragment behaves incorrectly

Michael, On 09/11/18 15:48, Michael McMahon wrote: Could i get the following small change reviewed please? http://cr.openjdk.java.net/~michaelm/8213616/webrev.1/ The change looks ok to me. Just a few comments: 1) The specification already mentions that "any query or fragment components of

Re: RFR [12] 8213490: Networking area nano cleanup

> On 13 Nov 2018, at 02:45, Pavel Rappo wrote: > ... > http://cr.openjdk.java.net/~prappo/8213490/webrev.02/ Looks fine. -Chris.

Re: RFR:8046500 GetIpAddrTable function failed on Pure Ipv6 environment

Vyom, > On 13 Nov 2018, at 12:35, vyom tewari wrote: > > Hi Chris, > > Thanks for review, please find the latest > webrev(http://cr.openjdk.java.net/~vtewari/8046500/webrev0.1/index.html) > where i incorporated your suggestion. Now i am returning the different error > code(-2) if IP Helper L

Re: RFR: 8213942:URLStreamHandler initialization race

Sean, > On 20 Nov 2018, at 17:55, Seán Coffey wrote: > > A race condition recently reported by the WLS team. Access to the handlers > Hashtable and the factory should be made while holding the streamHandlerLock > lock. > > WLS team also made efforts to create a reproducer. I've modified to jt

Re: RFR:8046500 GetIpAddrTable function failed on Pure Ipv6 environment

On 21/11/18 09:38, vyom tewari wrote: Hi Chris, thanks for review, you are right, we should clear the pending exception if -2 is return. Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8046500/webrev0.2/index.html). Thank you. I think this is good. -Chris.

Re: RFR: 8213942:URLStreamHandler initialization race

On 21/11/18 13:04, Seán Coffey wrote: Thanks to all for the feedback. It makes sense to reduce the scope of the lock where possible. I've updated the webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213942.v2/webrev/ Thanks Sean, this looks good. -Chris.

Re: RFR: 8213942:URLStreamHandler initialization race

Pavel, On 21/11/18 15:33, Pavel Rappo wrote: This fix assumes handlers returned from defaultFactory are interchangeable The default factory will always return a handler instance of the same type, when the requesting protocol is the same. and that defaultFactory is thread-safe. It is. -Chr

Re: RFR: 8214295: Populate handlers while holding streamHandlerLock

On 26/11/2018 12:12, Seán Coffey wrote: JDK-8213942 synchronization fix can be improved. Details in bug report. https://bugs.openjdk.java.net/browse/JDK-8214295 http://cr.openjdk.java.net/~coffeys/webrev.8214295/webrev/ LGTM. -Chris.

Re: JDK 12 RFR of JDK-8213911: Use example.com in java.net and other examples

Looks ok to me. -Chris. On 26/11/2018 21:38, joe darcy wrote: Hello, Please review a simple doc-only change to address:     JDK-8213911: Use example.com in java.net and other examples     http://cr.openjdk.java.net/~darcy/8213911.0/ Patch below. Thanks, -Joe --- old/src/java.base/share

Re: RFR: 8211842 IPv6_supported wrongly returns false when unix domain socket is bound to fd 0

> On 28 Nov 2018, at 15:50, Michael McMahon > wrote: > > Could I get the following fix reviewed please? > The fix is pretty simple, but the test a bit more involved > since the issue occurs when the JVM is launched in unusual circumstances > where its stdin,out,err are connected to a UNIX domai

Re: RFR: 8210107: vmTestbase/nsk/stress/network tests fail with Cannot assign requested address (Bind failed)

On 04/12/2018 21:36, Leonid Mesnik wrote: Hi Could you please review following fix which removes vmTestbase/nsk/stress/network tests. These tests  are pretty old stress networking tests and are don't seem to be useful for hotspot. I was not able to find any product bugs related with these tes

Re: RFR 8215008: Clear confusion between URL/URI paths and file system paths

> On 7 Dec 2018, at 16:16, Daniel Fuchs wrote: > > Thanks for the feedback Alan! > > I have updated the webrev accordingly: > > http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.01/ Looks good. Maybe userinfo. -Chris.

Re: RFR [12] 8215292: Back out changes for node- and link- local ipv6 multicast address

The backout looks correct, and I agree with the approach. -Chris. On 12/12/2018 16:09, Pavel Rappo wrote: Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8215292/webrev.00 That change backs out the fix for "Bind to node- or linklocal ipv6 multicast address fai

Re: 8207404: MulticastSocket tests failing on Aix

Steve, On 05/12/2018 10:50, Steve Groeger wrote: Posting this to net-dev as well as ppc-aix-port-dev as this may be a more appropriate mailing list to get responses about networking. I have performed the test Volker mentioned in an earlier post (on xLinux machine, remove the ipv6 address from

Re: [13] RFR: 8216498: Confusing and unneeded wrapping of SSLHandshakeException

> On 10 Jan 2019, at 18:23, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > 8216498: Confusing and unneeded wrapping of SSLHandshakeException > https://bugs.openjdk.java.net/browse/JDK-8216498 > > Webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8216498/webrev.00/ This look

Re: [13] RFR: 8216498: Confusing and unneeded wrapping of SSLHandshakeException

On 11/01/2019 11:20, Daniel Fuchs wrote: Thanks Chris. More extensive test campaign revealed that I missed another wrapping point in HttpClientImpl::sendAsync. New webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8216498/webrev.01 Good catch. The updated webrev looks good. -Chris.

Re: 8207404: MulticastSocket tests failing on Aix

On 09/01/2019 15:20, Steve Groeger wrote: ... I think I have an Linux system setup with a simarly configured interface (system has IPv6 configured but interface has no IPv6/INET6 address configured) but the test works fine when run on that system. This is what I observe too. Confirmed by l

Re: 8207404: MulticastSocket tests failing on Aix

set_if_by_if_v6(env, this, fd, value); >} else { >mcast_set_if_by_if_v4(env, this, fd, value); >} > #endif /* __linux__ */ > > We should probably follow the Linux way for AIX as well. I agree. -Chris. >> On Fri, Jan 11, 2019 at 5:29 PM Chris Hegarty >> wrote: &

Re: [13] RFR: 8216478: Cleanup HttpResponseImpl back reference to HttpConnection

> On 11 Jan 2019, at 17:37, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > 8216478: Cleanup HttpResponseImpl back reference to HttpConnection > https://bugs.openjdk.java.net/browse/JDK-8216478 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8216478/webrev.00/ This

Re: [13] RFR - 8216974: HttpConnection not returned to the pool after 204 response

> On 14 Jan 2019, at 12:28, Daniel Fuchs wrote: > > Hi, > > Please find below a patch for: > > 8216974: HttpConnection not returned to the pool after 204 response > https://bugs.openjdk.java.net/browse/JDK-8216974 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8216974/webrev.00/ > <

Re: [13] RFR: 8217094: HttpClient SSL race if a socket IOException is raised before ALPN is available

On 15/01/2019 16:52, Daniel Fuchs wrote: Hi, Please find below a fix for: 8217094: HttpClient SSL race if a socket IOException is raised before ALPN is available https://bugs.openjdk.java.net/browse/JDK-8217094 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8217094/webrev.00/

Re: RFR(XS): 8217311: Improve Exception thrown when MulticastSocket.setInterface fails on AIX(Unix)

> On 17 Jan 2019, at 09:54, Langer, Christoph wrote: > > Hi, > > please help to review a tiny fix. > > While working on the issue with the AIX multicast tests > (https://bugs.openjdk.java.net/browse/JDK-8207404 > ), I found a place where a

Re: RFR: 8207404: MulticastSocket tests failing on AIX

> On 17 Jan 2019, at 10:55, Langer, Christoph wrote: > > Hi, > > here is a fix for the MulticastSocket tests failing on AIX (in certain > sceanrios): > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8207404.0/ > Why remove th

Re: RFR: 8207404: MulticastSocket tests failing on AIX

On 18/01/2019 08:54, Langer, Christoph wrote: Hi, here is the updated webrev with modifications to the problem list and reverting the static imports: _http://cr.openjdk.java.net/~clanger/webrevs/8207404.1/__ I think this is ok. -Chris.

Re: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted

On 18/01/2019 14:24, Daniel Fuchs wrote: Hi Andrej, On 18/01/2019 14:03, Andrej Golovnin wrote: Is creating new Optionals a real problem? And before you answer please remember what Donald Knuth said: The real problem is that programmers have spent far too much time worrying about efficiency in

Re: 8217451: ExtendedSocketOptions should encapsulate support for SO_FLOW_SLA

On 21/01/2019 17:41, Alan Bateman wrote: ExtendSocketOptions is the supporting class that the socket implementations use for JDK-specific socket options. Vyom improved it last year to select options based on the socket type but more is needed to handle socket options that are specific to conn

Re: RFR: 8217264: HttpClient: Blocking operations in mapper function do not work as documented

Daniel, On 23/01/2019 11:10, Daniel Fuchs wrote: Hi, Please find below a fix for: 8217264: HttpClient: Blocking operations in mapper function do not work as documented [1] https://bugs.openjdk.java.net/browse/JDK-8217264 webrev: [2] http://cr.openjdk.java.net/~dfuchs/webrev_8217264/

RFR [13] 8217429: WebSocket over authenticating proxy fails to send Upgrade headers

When tunneling WebSocket over a proxy requiring authentication, the implementation must ensure that the appropriate Upgrade headers are not lost after the tunnel has been established. The source changes are quite straight forward, the remaining bulk of the changes are to address a deficiency in the

Re: [13] RFR (doc): 8217627: HttpClient: The API documentation of BodySubscribers::mapping promotes bad behavior

> On 25 Jan 2019, at 14:10, Daniel Fuchs wrote: > > Hi, > > Please find below a doc clarification change for: > > 8217627: HttpClient: The API documentation of BodySubscribers::mapping > promotes bad behavior > https://bugs.openjdk.java.net/browse/JDK-8217627 > > webrev: > http://cr

Re: RFR [13] 8217429: WebSocket over authenticating proxy fails to send Upgrade headers

Pavel, > On 25 Jan 2019, at 15:16, Pavel Rappo wrote: > > Chris, thanks for doing this! I have two questions on this change. > > 1. After this change has been applied, there will be a circular dependency > between HttpRequestImpl and OpeningHandshake. If this code is used by these > two > clas

Re: RFR [13] 8217429: WebSocket over authenticating proxy fails to send Upgrade headers

Daniel, > On 25 Jan 2019, at 15:34, Daniel Fuchs wrote: > > Hi Chris, > > Looks good. > I had the same question than Pavel about server.close(). Answered already in reply to Pavel’s question. > No test for both proxy + server authorization with > -Djdk.http.auth.tunneling.disabledSchemes ? N

Re: RFR (testbug): 8210130: java/net/httpclient/UnknownBodyLengthTest.java failed

On 28/01/2019 12:03, Daniel Fuchs wrote: Hi, Please find below a test for: 8210130: java/net/httpclient/UnknownBodyLengthTest.java failed https://bugs.openjdk.java.net/browse/JDK-8210130 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8210130/webrev.00/ Looks good Daniel. -Chris.

Re: RFR: (testbug) 8217903: java/net/httpclient/Response204.java fails with 404

On 28/01/2019 17:57, Daniel Fuchs wrote: Hi, Please find below a test for: 8217903: java/net/httpclient/Response204.java fails with 404 https://bugs.openjdk.java.net/browse/JDK-8217903 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8217903/webrev.00/ Ship it! -Chris.

RFR [13] 8217976: test/jdk/java/net/httpclient/websocket/WebSocketProxyTest.java fails intermittently

WebSocketProxyTest is a new test that was added recently. It fails once in every few hundred runs. The test uses a preexisting test-only proxy server. There is a race when closing the server; the close method iterates over all connections while another thread may be adding a new connection. The sol

Re: RFR [13] 8217976: test/jdk/java/net/httpclient/websocket/WebSocketProxyTest.java fails intermittently

> On 29 Jan 2019, at 12:31, Daniel Fuchs wrote: > > ... > The best would be to use CopyOnWriteArrayList instead > of synchronizedList(). Otherwise you'd still need to copy the list > within a synchronize(connections) { } block to prevent CME. Agreed. Should be good enough for test cleanup. ht

Re: RFR (testbug): 8216562: UnknownBodyLength sometimes fails due to "Connection reset by peer"

On 29/01/2019 17:31, Daniel Fuchs wrote: Hi, Please find below a fix for: 8216562: UnknownBodyLength sometimes fails due to "Connection reset by peer" https://bugs.openjdk.java.net/browse/JDK-8216562 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8216562/webrev.00/ Looks ok,

Re: RFR (testbug) 8218133: sun/net/www/protocol/http/ProtocolRedirect.java failed with "java.net.ConnectException"

On 31/01/2019 19:23, Daniel Fuchs wrote: 8218133: sun/net/www/protocol/http/ProtocolRedirect.java failed with "java.net.ConnectException" https://bugs.openjdk.java.net/browse/JDK-8218133 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8218133/webrev.00/ Looks good Daniel. -Chr

RFR [12] 8218546 : Unable to connect to https://google.com using java.net.HttpClient

This is a code review request for a late fix for JDK 12, to address a potentially serious regression. Post 8213189 [1] the HTTP Client now adds both the `:authority:` pseudo-header and the `Host` header to outbound HTTP/2 requests. The HTTP/2 RFC does not seem to rule out this behavior, but it doe

Re: RFR [12] 8218546 : Unable to connect to https://google.com using java.net.HttpClient

rade case? Or is > it simply too difficult to figure out whether the connection > actually started with HTTP/1.1 and was upgraded? > > > best regards, > > -- daniel > > On 07/02/2019 12:48, Chris Hegarty wrote: >> This is a code review request for a late fix f

RFR [12] 8218662: Allow 204 responses with Content-Length:0

This is a code review request for a late fix for JDK 12, to address a what could be perceived as a potential regression. Post 8211437 [1] the HTTP Client now disallows 204 responses with a response body. It appears that this change may have been a little too strict, by disallowing any response wit

Re: [13] RFR: 8218554: HttpServer: allow custom handlers to request that the connection be closed after the exchange.

Daniel, > On 7 Feb 2019, at 13:36, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for an HttpServer RFE: > > 8218554: HttpServer: allow custom handlers to request that the > connection be closed after the exchange. > https://bugs.openjdk.java.net/browse/JDK-8218554 > > webrev

Re: 8218882: NET_Writev is declared, NET_WriteV is defined

On 13/02/2019 01:31, Brian Burkhalter wrote: ... [1] http://cr.openjdk.java.net/~bpb/8218882/webrev.00/ Look ok Brian. -Chris.

Re: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl

> On 26 Feb 2019, at 03:53, Xuelei Fan wrote: > > > > It makes sense to me to leave the AbstractDelegateHttpsURLConnection methods > as public. We may need to re-org the code later, but it is out of the scope > of this update. > > Here is the new webrev (only AbstractDelegateHttpsURLConne

Re: [JDK 13] RFR 8219802: Problem list java/net/MulticastSocket/SetGetNetworkInterfaceTest.java

+1 -Chris. On 27/02/2019 09:31, Langer, Christoph wrote: Hi Amy, seems reasonable to me. +1 Best regards Christoph -Original Message- From: core-libs-dev On Behalf Of Amy Lu Sent: Mittwoch, 27. Februar 2019 02:41 To: OpenJDK Dev list ; Core-Libs-Dev Subject: [JDK 13] RFR 8219802:

RFR 8184315: Typo in java.net.JarURLConnection.getCertificates() method documentation

Trivial typo fixes to: 1) use the simple present tense of the verb, and 2) correctly pluralize the return value. Similar to that of JarEntry::getCertificates. --- a/src/java.base/share/classes/java/net/JarURLConnection.java +++ b/src/java.base/share/classes/java/net/JarURLConnection.java @@ -279,

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

Arthur, On 11/03/2019 16:55, Arthur Eubanks wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8220083 webrev: http://cr.openjdk.java.net/~aeubanks/8220083/webrev.00/ In principle, I think this is good. I want to run some tests with your patch, and do a detailed review. Will reply with resul

RFR 8220480: Typo in java.net.http.HttpResponse.BodySubscriber documentation

Minor typo in the link target, should be BodySubscribers ( plural ). --- a/src/java.net.http/share/classes/java/net/http/HttpResponse.java +++ b/src/java.net.http/share/classes/java/net/http/HttpResponse.java @@ -1,7 +1,7 @@ /* - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All right

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

Hi Arthur, > On 11 Mar 2019, at 18:14, Arthur Eubanks > wrote: > > Updated copyright years (I asked around, it should be fine), updated commit > message. > http://cr.openjdk.java.net/~aeubanks/8220083/webrev.01 >

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

Arthur, > On 12 Mar 2019, at 16:59, Arthur Eubanks wrote: > > Thanks for creating the umbrella bug. > > Split long line. > Added the HTTPTestServer.java and UrgentDataTest.java changes in Chris's > suggestions. Thanks. > The other 2 involve URI/URLs, and there are a lot of those changes, wil

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

Arthur, > On 12 Mar 2019, at 17:54, Arthur Eubanks wrote: > > Thanks! > > Just curious, what tests did you run and under what environment? I ran all java/net, sun/net, com/sun/net/, and some nio. I'm have a bit of a hacky environment: a JDK build with IPV6_V6ONLY set to 1, and preferIPv6Addre

RFR 8220475: Malformed copyright header in LinuxSocketOptions.java, MacOSXSocketOptions.java and MacOSXSocketOptions.c

Trivially, there should be a comma after the year. Just add it. diff --git a/src/jdk.net/linux/classes/jdk/net/LinuxSocketOptions.java b/src/jdk.net/linux/classes/jdk/net/LinuxSocketOptions.java --- a/src/jdk.net/linux/classes/jdk/net/LinuxSocketOptions.java +++ b/src/jdk.net/linux/classes/jdk/ne

RFR 8220598: Malformed copyright year range in a few files in java.base

Trivially, there should be a comma after the year. Just add it. $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java --- a/src/ja

Re: RFR: 8220585: Incorrect code in MulticastSocket sample code

Arthur, On 13/03/2019 16:32, Arthur Eubanks wrote: Hi, A fix for some sample code in MulticastSocket, which assumed that String.length() == String.getBytes().length, which is not true for non-ASCII Strings. http://cr.openjdk.java.net/~aeubanks/8220585/webrev.00 Looks good. Thanks. -Chris

Regarding 8220575: Correctly format test URI's that contain a retrieved IPv6 address

I filed the 8220575 [1] that tracks "Correctly format test URI's that contain a retrieved IPv6 address" Regarding fixing tests that incorrectly use IPv6 addresses in URL's or URI's, without enclosing the address within '[' and ']' ( square brackets ). These IPv6 addresses typically come from eith

Re: Regarding 8220575: Correctly format test URI's that contain a retrieved IPv6 address

Daniel, On 13/03/2019 18:22, Daniel Fuchs wrote: Hi Chris, On 13/03/2019 17:32, Chris Hegarty wrote: I think that is most cases it should be possible to just replace the use of `getHostAddress` with `getHostName`. This defers the actual lookup to the system configured name service ( rather

<    4   5   6   7   8   9   10   11   12   13   >