Re: HTTP/2 Support in com.sun.net.httpserver?

> On 4 Dec 2019, at 18:18, Pavel Rappo wrote: > > Forwarding to a more relevant mailing list. When answering, > please remove jdk-dev from the list of recipients. > > Thanks. > >> Begin forwarded message: >> >> From: Chris Mason >> Subject: HTTP/2 Support in com.sun.net.httpserver? >> Date

Re: RFR 8235413: com.sun.net.httpserver.BasicAuthenticator.charset is protected field

> On 5 Dec 2019, at 15:44, Michael McMahon wrote: > > Hi, > > Could I get the following trivial fix reviewed please. It is included in diff > form below. > > The problem was that a field "charset" was added as part of JDK-8199849, but > it was > made protected by mistake instead of private

Re: RFR[8233191]: MulticastSocket joinGroup/leaveGroup do not specify their behavior when the outgoing interface has not been set

> On 5 Dec 2019, at 15:50, Patrick Concannon > wrote: > > Hi, > > > Could some please review my fix for issue JDK-8233191 'MulticastSocket > joinGroup/leaveGroup do not specify their behavior when the outgoing > interface has not been set'? > > This javadoc fix clarifies the behaviour of

Re: RFR 8234871: deprecate SocketFlow (SO_FLOW_SLA) and related APIs for removal

> On 9 Dec 2019, at 18:03, Michael McMahon wrote: > > Hi, > > Could I get the following webrev reviewed please? The deprecation arises from > the general deprecation of the Solaris port and the fact this is a Solaris > only feature. > > http://cr.openjdk.java.net/~michaelm/8234871/webrev.1/

Re: Why are com.sun.net.HttpExchange attributes shared between instances?

> On 11 Dec 2019, at 17:35, Julien Royer wrote: > > Hi, > >> On 11 Dec 2019, at 10:48, Michael McMahon >> wrote: >> Go ahead and file a bug and we can take it from there. >> > Thank you Michael. > > > Bug Report Submission Complete > > Thank you for taking the time to provide us with your

Re: (test-only) RFR: 8235925: java/net/Socket/HttpProxy.java fails on IPv4 only hosts and other small cleanups

Daniel, > On 13 Dec 2019, at 18:53, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > 8235925: java/net/Socket/HttpProxy.java fails on IPv4 only hosts > and other small cleanups > https://bugs.openjdk.java.net/browse/JDK-8235925 > > webrev: > http://cr.openjdk.java.net/

Re: RFR [15] 5064980: URI compareTo inconsistent with equals for mixed-case escape sequences

Kiran, > On 13 Dec 2019, at 18:28, Kiran Ravikumar > wrote: > > Hi Guys, > > > > Could someone please review my fix to URI.java class were URI.compareTo(URI) > behavior was different to URI.equals(URI). URI.compareTo(URI) does not > consider two URI's to be equal when they differ only in t

Re: RFR [15] 5064980: URI compareTo inconsistent with equals for mixed-case escape sequences

> On 16 Dec 2019, at 15:54, Kiran Ravikumar > wrote: > > Thanks Daniel and Chris, > > Here is my updated webrev with the mentioned corrections. > > http://cr.openjdk.java.net/~kravikumar/5064980/webrev.01/ > LGTM. -Chris.

Re: RFR [14] 8235976: Directives in WWW-Authenticate should be comma separated

> On 16 Dec 2019, at 15:48, Michael McMahon > wrote: > > Could I get the following small fix reviewed please? > > It is a followup to 8199849 which is already in 14. > The fix did not include the required comma separator between parameters > in HTTP response authentication headers. > > http

Re: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors

The changes to the SCTP code seem ok. -Chris. > On 17 Dec 2019, at 03:00, Patrick Zhang OS > wrote: > > Thanks Martin. > > Hi net-dev, and/or security-dev Reviewers, > > Please help review and sponsor this patch if acceptable. > It does not tend to bring any functionality changes, instead to

Re: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException

> On 18 Dec 2019, at 11:09, Alan Bateman wrote: > > On 18/12/2019 10:55, Daniel Fuchs wrote: >> We already have two implementations of DatagramSocket: one is the plain >> DatagramSocket, the other is the DatagramSocket adapter created by >> DatagramChannel::socket. >> >> Even without preparin

Re: Anyone maintaining or know of a custom DatagramSocketImpl ?

> On 18 Dec 2019, at 13:14, Alan Bateman wrote: > > > … because MulticastSocket can't work with a DatagramSocketImpl that hasn't > been upgraded. Specifically on this point, the two-arg variants of `joinGroup` and `leaveGroup` throw an UnsupportedOperationException if invoked on a Multicast

RFR [14] 8236441: Bound MulticastSocket fails when setting outbound interface on Windows

The MulticastSocket implementation on Windows uses the two stacks implementation. The two stacks implementation creates a socket on the IPv4 stack and another on the IPv6 stack. Operations are then performed on both sockets as appropriate. If the socket is bound to a specific address, then the IP v

Re: RFR [14] 8236441: Bound MulticastSocket fails when setting outbound interface on Windows

> On 20 Dec 2019, at 20:17, Alan Bateman wrote: > >> ... > This looks okay to me. There are a few inconsistencies in this code in that > some places it checks if fd1 >= 0, others != -1 but I don't think there are > correctness issues. You probably don't need to check ipv6_supported as fd1 >

Re: RFR [14] 8236441: Bound MulticastSocket fails when setting outbound interface on Windows

> On 21 Dec 2019, at 08:23, Alan Bateman wrote: > > On 20/12/2019 22:34, Chris Hegarty wrote: >> >> Thanks Alan, >> >> 1) I updated the file descriptor check from ` > 0` to ` >= 0` >> 2) Removed the pre-existing incorrect comment, and >>

Re: [PATCH] 7006496: Use modern Windows API to retrieve OS DNS servers

> On 24 Dec 2019, at 10:12, Aleks Efimov wrote: > > Hi Anuraag, > > We need additional approval from openjdk reviewer. After that I will sponsor > your change. > > Merry Christmas and a Happy New Year, > Aleksei > > On 18/12/2019 06:08, Anuraag Agrawal wrote: >> ... >> http://cr.openjdk.ja

Re: [PATCH] 7006496: Use modern Windows API to retrieve OS DNS servers

> On 27 Dec 2019, at 08:44, Anuraag Agrawal wrote: > > ... > On Tue, Dec 24, 2019 at 11:57 PM Chris Hegarty <mailto:chris.hega...@oracle.com>> wrote: > > ... > I think that this mainly looks good. A few small comments: > > 1) If getAdapters returns an

Re: Reading from a closed socket: different behavior between Linux and other operating systems

I agree with David, this is an expected difference between the socket layers on different operating systems. The different behaviours are acceptable implementations on said operating systems. Unfortunately, this results in different behaviour of the Java socket (and TCP socket channel) APIs, when r

Re: [PATCH] 7006496: Use modern Windows API to retrieve OS DNS servers

> On 8 Jan 2020, at 05:12, Anuraag Agrawal wrote: > > Hi Chris, > > Happy new year - sorry for the long delay. I have made an updated patch > fixing the comment (missing comma), bumping MAX_STR_LEN, and tweaking the > exception behavior. > > Basically, as you pointed out loadDNSConfig itself

Re: [PATCH] 7006496: Use modern Windows API to retrieve OS DNS servers

I’m happy with the latest iteration of this code. It has my Review. -Chris. > On 9 Jan 2020, at 00:54, Aleks Efimov wrote: > > Got the testing results: the CI is happy with the last patch - no JNDI test > failures observed > > Kind Regards, > Aleksei > > On 08/01/2020 18:23, Aleks Efimov wro

Re: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException

Patrick. > On 10 Jan 2020, at 15:26, Patrick Concannon > wrote: > > Hi Alan, > > Thanks for the feedback. > > I've incorporated your comments into the webrev below. > > http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.01/ Mostly looks good. A few small comments: 1) "If this **

Re: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException

> On 10 Jan 2020, at 16:29, Patrick Concannon > wrote: > > Hi Chris, > > Well spotted. > > I've made those changes and updated the webrev. > > http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.02/ LGTM. -Chris.

Re: @since tag missing from DatagramSocket and MulticastSocket methods

LGTM. Surprising that we haven’t noticed this before, because the @since tags are used, in part, to derive the symbol tables for --release ( maybe such old version information is not useful these days ) -Chris. > On 14 Jan 2020, at 11:49, Patrick Concannon > wrote: > > Hi, > > Could someon

Re: RFR: 8236859: WebSocket over authenticating proxy fails with NPE

Daniel, > On 13 Jan 2020, at 13:06, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > 8236859: WebSocket over authenticating proxy fails with NPE > https://bugs.openjdk.java.net/browse/JDK-8236859 > > > http://cr.openjdk.java.net/~dfuchs/webrev_8236859/webrev.00/ There is a lot

Re: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket

> On 14 Jan 2020, at 19:23, Alan Bateman wrote: > > ... > Here's the updated webrev that changes oldImpl to be final. >http://cr.openjdk.java.net/~alanb/8236925/2/webrev/ Generally, I agree with updating the socket adapter to support multicast. It will certainly help with future work in t

Re: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket

> On 16 Jan 2020, at 12:10, Alan Bateman wrote: > > On 16/01/2020 11:45, Chris Hegarty wrote: >> : >> Generally, I agree with updating the socket adapter to support >> multicast. It will certainly help with future work in this area. >> >> The instance

Re: RFR[8236105]: Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent

Patrick, > On 13 Jan 2020, at 16:30, Patrick Concannon > wrote: > > Hi, > > Could someone please review my fix and CSR for issue JDK-8236105 'Behaviors > of DatagramSocket/DatagramChannel::socket send methods are not always > consistent' ? > > The behaviour of the send methods for DatagramS

Re: RFR[8236105]: Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent

> On 17 Jan 2020, at 12:50, Patrick Concannon > wrote: > > Hi Chris, > > > > Thanks for your feedback. I've created a related bug for the points you've > raised and I will take a look at them once this issue has been fixed. > > The new issue be found here: https://bugs.openjdk.java.net/b

Re: 回复： RFR (XS) 8237806: Convert TIMEOUT of sun.net.dns.ResolverConfigurationImpl into property

Just to be clear. The code change that you are proposing affects the JDNI DNS provider, so may impact DNS lookups performed by JNDI, regardless of the removed-in-9 InetAddress name service provider mechanism. The CSR should be clear about this. Given this, the obvious question is whether this

Re: RFR[7021373]: DatagramPacket exception conditions are not clear

Patrick, On 24/01/2020 11:14, Patrick Concannon wrote: Hi, Could someone please review my fix and CSR for issue JDK-7021373 'DatagramPacket exception conditions are not clear' ? This fix updates the spec concerning the exceptions thrown by the constructors of the DatagramPacket class, and s

Re: 8236596: HttpClient leaves HTTP/2 sockets in CLOSE_WAIT, when using proxy tunnel

On 23/01/2020 17:31, Daniel Fuchs wrote: Hi, Please find below a fix for: 8236596: HttpClient leaves HTTP/2 sockets in CLOSE_WAIT, when using proxy tunnel https://bugs.openjdk.java.net/browse/JDK-8236596 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8236596/webrev.00/ LGTM.

Re: RFR[7021373]: DatagramPacket exception conditions are not clear

On 24/01/2020 12:07, Chris Hegarty wrote: Patrick, On 24/01/2020 11:14, Patrick Concannon wrote: Hi, Could someone please review my fix and CSR for issue JDK-7021373 'DatagramPacket exception conditions are not clear' ? This fix updates the spec concerning the exceptions thr

Re: RFR[7021373]: DatagramPacket exception conditions are not clear

Maybe we can retain existing behaviour, while implicitly specifying the IAE? @@ -311,16 +312,21 @@ setAddress(addr.getAddress()); setPort(addr.getPort()); } /** * Gets the SocketAddress (usually IP address + port number) of the remote * host that this pac

Re: RFR: JDK-8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10

Patrick, > On 7 Feb 2020, at 08:44, Patrick Zhang OS > wrote: > > Ping.. Pong ;-) > Regards > Patrick > > -Original Message- > From: net-dev On Behalf Of Patrick Zhang OS > Sent: Wednesday, February 5, 2020 8:19 PM > To: Chris Hegarty ; net-dev &

Re: RFR: JDK-8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10

> On 7 Feb 2020, at 14:08, Patrick Zhang OS > wrote: > > Agree, I was wondering where to place them, SctpNet.c or SctpChannelImpl.c. > Here is the update: http://cr.openjdk.java.net/~qpzhang/8238386/webrev.02/ > (smoke tested the build only) > And, thanks for your double-check with the modif

Re: RFR: JDK-8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10

> On 7 Feb 2020, at 14:20, Chris Hegarty wrote: > > >> On 7 Feb 2020, at 14:08, Patrick Zhang OS >> wrote: >> >> Agree, I was wondering where to place them, SctpNet.c or SctpChannelImpl.c. >> Here is the update: http://cr.openjdk.java.net/~qpzhang/8

Re: RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with proxy

Hi Ravi, > On 5 Feb 2020, at 12:43, Ravi Reddy wrote: > > Hello All, > > Could you please review this patch. This patch fixes the RFC unconformity of > HttpURLConnection with proxy issue. > > 1.Change in HttpURLConnection.java is to make sure we do retry with proxy as > mentioned in RFC >

Re: RFR[8234812]: 'Add micros for DatagramChannel send/receive'

> On 13 Feb 2020, at 14:27, Patrick Concannon > wrote: > > Hi, > > > Could someone please review my webrev for JDK-8234812 'Add micros for > DatagramChannel send/receive' ? > > This test adds some benchmarks for the DatagramChannel's send, receive, read > and write methods. > > > bug:

Re: RFR[15] JDK-8239025: ProblemList java/net/httpclient/HandshakeFailureTest.java due to JDK-8238990

LGTM. -Chris > On 13 Feb 2020, at 23:06, sha.ji...@oracle.com wrote: > > Hi, > java/net/httpclient/HandshakeFailureTest.java should be in the problem list > until JDK-8238990 is resolved. > > diff -r 87651cb03ebc test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txtThu Feb 13 13:43:09

Re: RFR[8237480]: Add micros for DatagramSocket send/receive

> On 14 Feb 2020, at 11:57, Patrick Concannon > wrote: > > Hi, > > With further discussion on this benchmark test with Claes off-list, I've > updated the code to use more descriptive names. The updated webrev can be > found below. > > http://cr.openjdk.java.net/~pconcannon/8237480/webrevs/

Re: 8238990: java/net/httpclient/HandshakeFailureTest.java failed against TLSv1.3 on Windows

> On 19 Feb 2020, at 19:26, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > 8238990: java/net/httpclient/HandshakeFailureTest.java failed > against TLSv1.3 on Windows > https://bugs.openjdk.java.net/browse/JDK-8238990 > > webrev: > http://cr.openjdk.java.net/~dfuchs/we

Re: 8239052: java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java failed with BufferUnderflowException against TLSv1.3

> On 21 Feb 2020, at 17:41, Daniel Fuchs wrote: > > Thanks John! > > I have verified that indeed TLSv1.3 is selected by default, > and updated the fix as per your suggestion: > > http://cr.openjdk.java.net/~dfuchs/webrev_8239052/webrev.01/ Good sleuthing Daniel. Your changes look good, just

Re: 8239052: java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java failed with BufferUnderflowException against TLSv1.3

> On 24 Feb 2020, at 15:14, Daniel Fuchs wrote: > > Thanks Chris! > > I was going to answer that this was not possible as it requires > multiple return values but I found a way: > > http://cr.openjdk.java.net/~dfuchs/webrev_8239052/webrev.02/ LGTM. -Chris.

Re: RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with proxy

Ravi, > On 2 Mar 2020, at 15:01, Ravi Reddy wrote: > > Hi Daniel, > > As suggested by you I have added a test case for retry connection with proxy > case . Please review the latest webrev and let me know your comments. > > With the latest changes , the HttpURLConWithProxy test fails without t

Re: 8240754: Instrument FlowTest.java to provide more debug traces.

Daniel, > On 9 Mar 2020, at 16:53, Daniel Fuchs wrote: > > Hi, > > Please find below a changeset that adds some more debugging > output to FlowTest.java for better test failure diagnosis. > > 8240754: Instrument FlowTest.java to provide more debug traces. > https://bugs.openjdk.java.net/browse

Re: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the default file system

Julia, > On 5 Mar 2020, at 13:50, Julia Boes wrote: > > Hi, > > Please see this fix that adds support for non-default file systems to the > HttpClient. More specifically, the change is in > RequestPublishers.FilePublisher where an UnsupportedOperationException is > thrown if a java.io.File c

Re: RFR: JDK-8241138: http.nonProxyHosts=* causes StringIndexOutOfBoundsException in DefaultProxySelector

> On 18 Mar 2020, at 11:18, Jaikiran Pai wrote: > ... > > [2] https://cr.openjdk.java.net/~jpai/webrev/8241138/1/webrev/ LGTM. -Chris.

Re: RFR JDK-8240921: Minor correction to HttpResponse.BodySubscribers example

Rahul, > On 19 Mar 2020, at 10:29, rahul.r.ya...@oracle.com wrote: > > Hello, > > Can I please have my fix reviewed for issue JDK-8240921 - Minor correction > to HttpResponse.BodySubscribers example? > > The fix updates the incorrect example of the usage of the class > java.net.http.HttpRe

Re: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the default file system

> On 24 Mar 2020, at 15:01, Julia Boes wrote: > ... > > Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8235459/webrev.03/ LGTM. -Chris.

Re: 8241674 (XS): Fix incorrect jtreg option in FilePublisherPermsTest

LGTM. -Chris > On 26 Mar 2020, at 14:32, Julia Boes wrote: > > Hi, > > Could someone please review this small fix of a recently pushed test? The > option to extend the policy file has to be 'java.security.policy' instead of > 'policy' - this was discussed on this mailing list but then mira

Re: 8241336: Some java.net tests failed with NoRouteToHostException on MacOS with special network configuration

> On 27 Mar 2020, at 09:30, Daniel Fuchs wrote: > > Hi Alan, > > On 27/03/2020 09:06, Alan Bateman wrote: >>> http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.02/ >> This mostly looks good except that I'd prefer if the the code in >> assertNotSame be moved into testSendNoReceive (it w

Re: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

Xuelei, Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property. Is there a specification or other documentation describing `jdk.tls.client.protocols` ? It is

Re: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

Thank you Xuelei, this very helpful. Sorry, but I am going to ask just a few more clarifying questions to make sure that we’re on the same page. > On 27 Mar 2020, at 16:23, Xuelei Fan wrote: > > On 3/27/2020 5:52 AM, Chris Hegarty wrote: >> Xuelei, >> Before comm

Re: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

Thank you for these clarifications. We will now consider how these affect, if at all, the HTTP Client. -Chris. > On 27 Mar 2020, at 17:47, Xuelei Fan wrote: > > On 3/27/2020 10:36 AM, Chris Hegarty wrote: >> Thank you Xuelei, this very helpful. >> Sorry, but I am going t

Re: Java 14 - Change in InetSocketAddress.toString() behaviour seems to be causing issues

Hi Jaikiran, Thank you for posting this message to net-dev. TL;DR seems like the specific issue raised against Quarkus has been resolved ( by upgrading to a more recent version of ZooKeeper ). > On 28 Mar 2020, at 06:43, Jaikiran Pai wrote: > > There's an issue raised in Quarkus repo[1], whe

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

Patrick, > On 31 Mar 2020, at 15:08, Daniel Fuchs wrote: > >> .. >> bug: https://bugs.openjdk.java.net/browse/JDK-8240533 >> webrev: http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.00/ Look good Patrick. The check is deliberately performed after the security manager checks, right

Re: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

> On 30 Mar 2020, at 19:27, Patrick Concannon > wrote: > ... > > http://cr.openjdk.java.net/~pconcannon/8241072/webrevs/webrev.01/ This looks very good, a testament to all the prior cleanup work that has already been done. Just a few comments: - DatagramSocket::getChannel now stands out a

Re: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

> On 31 Mar 2020, at 18:46, Alan Bateman wrote: > > On 31/03/2020 18:27, Chris Hegarty wrote: >> : >> - In DatagramSocket::createDelegate, "enable broadcast if possible” - >> Possibly due to refactoring, but I cannot reconcile this with the old >> impleme

Re: Java 14 - Change in InetSocketAddress.toString() behaviour seems to be causing issues

> On 1 Apr 2020, at 13:48, Jaikiran Pai wrote: ... >>> Now that you explained it to me, I see what you mean and what that javadoc >>> means. I hadn't paid attention to the "This String is constructed by >>> calling toString() on the InetAddress and concatenating the port number >>> (with

RFR [15] 8241988 DatagramSocket incorrectly caches the first set of socket options

DatagramSocket incorrectly caches the first set of socket options that it encounters (through an invocation of supportedOptions()), subsequently returning that set of options regardless of what the particular datagram socket impl actually supports. Webrev: https://cr.openjdk.java.net/~chegar/824

Re: RFR [15] 8241988 DatagramSocket incorrectly caches the first set of socket options

> On 1 Apr 2020, at 15:12, mark sheppard wrote: > > Hi Chris, > just looking at the supportedOptions method in the two classes > DatagramSocket and MulticastSocket, if I haven't misread them, are > they not the same? > As such MulticastSocket could inherit that method from DatagramSocket ?

Re: RFR [15] 8241988 DatagramSocket incorrectly caches the first set of socket options

> On 1 Apr 2020, at 17:51, Alan Bateman wrote: > > On 01/04/2020 16:04, Chris Hegarty wrote: >> : >> >> Updated webrev: >> https://cr.openjdk.java.net/~chegar/8241988/webrev.01/ >> > Looks good although I can't immediately see why options is pac

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

Daniel, > On 1 Apr 2020, at 18:42, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests > fail due to "SocketException: No buffer space available" > https://bugs.openjdk.java.net/browse/JDK-8241786 Good work. A r

RFR [15] 8242044: Add basic HTTP/1.1 support to the HTTP/2 Test Server

To more easily write HTTP Client test scenarios for different protocol versions and different TLS versions, it would be very convenient if the HTTP/2 server, that is part of the JDK regression test suite, was able to issue basic HTTP/1.1 responses. This enhance adds minimal support, which effectiv

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

Daniel, > On 2 Apr 2020, at 10:33, Daniel Fuchs wrote: > > Hi Chris, > > On 02/04/2020 09:40, Chris Hegarty wrote: >> This is a functional change that affects the product build. Maybe that >> would be a little clearer from a different bug synopsis. Suggest >

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

Hi Patrick, > On 3 Apr 2020, at 14:47, Patrick Concannon > wrote: > > ... > > Chris - I put in an extra check in the tests to ensure that the new code > doesn’t interfere with the Security Manager checks already present in the > source. Thank you Patrick. > The new webrev can be found here

8241995: Clarify InetSocketAddress::toString specification

As noted in a recent thread [1], the wording of InetSocketAddress::toString could be improved a little, to avoid any potential confusion about how and when "" is displayed. It was also suggested that a link to getHostString could be added. Below is an initial suggestion. It does not change the spe

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

> On 04/04/2020 16:26, Patrick Concannon wrote: >> Hi Chris and Daniel, >> Well spotted, Chris. Thanks for that! >> Thanks too Daniel, that's a good idea. I've made those changes and included >> them in a new webrev, which you can find below. >> http://cr.openjdk.java.net/~pconcannon/8240533/we

Re: RFR: 8242186: Reduce allocations in URLStreamHandler.parseURL for some cases (Was: Re: [NEW BUG] Small optimization in URLStreamHandler.parseURL)

> On 6 Apr 2020, at 11:29, Claes Redestad wrote: > > Hi, > > (including net-dev@.. since this is in java.net) > > I intend to sponsor this trivial patch provided by Christoph: > > diff -r 65b345254ca3 > src/java.base/share/classes/java/net/URLStreamHandler.java > --- a/src/java.base/share/

Re: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

> On 8 Apr 2020, at 10:13, Rahul wrote: > > Updated patch after considering the impact of returning default parameters on > the http client. > TLS versions earlier limited to 1.2 and above by client, now will support all > versions(wrt the scenarios for this bug). > >Issue: https://bugs

Re: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set'

> On 15 Apr 2020, at 16:40, Patrick Concannon > wrote: > > ... > > webrev: http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.01/ > I added myself as reviewer on the CSR. The changes mainly look good. Can you please add, or amend an existing, test for the newly specified defaul

Re: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

Daniel, > On 14 Apr 2020, at 16:37, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > 8238270: java.net HTTP/2 client does not decrease stream count > when receives 204 response > https://bugs.openjdk.java.net/browse/JDK-8238270 > > webrev: > http://cr.openjdk.java.net/

Re: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

> On 15 Apr 2020, at 18:17, Daniel Fuchs wrote: > > Hi Chris, > > On 15/04/2020 17:40, Chris Hegarty wrote: >> It is allowable for a HEADERS frame to carry an END_STREAM, >> but not an END_HEADERS. If this happens, then CONTINUATION >> frames must fol

Re: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set'

> On 16 Apr 2020, at 14:39, Patrick Concannon > wrote: > > ... > > http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.02/ LGTM. -Chris.

Re: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

> On 16 Apr 2020, at 19:10, Daniel Fuchs wrote: > > ... so I have logged https://bugs.openjdk.java.net/browse/JDK-8242999 > to follow up on this. > ... > > New webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8238270/webrev.01/ > This fixes the issue at-hand and is a a good incremental imp

Re: RFR 15 8243099: Adding ADQ support to JDK

Vladimir, > On 18 Apr 2020, at 00:13, Ivanov, Vladimir A > wrote: > > Hello everyone, > I would like to add support for the Application Device Queue (ADQ) technology > to the JDK. > > The JBS entry and webrev were created for this improvement: > JBS: https://bugs.openjdk.java.net/browse/JDK-8

Re: 8243246: HTTP Client sometimes gets java.io.IOException -> Invalid chunk header byte 32

> On 23 Apr 2020, at 15:39, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > 8243246: HTTP Client sometimes gets java.io.IOException -> Invalid > chunk header byte 32 > https://bugs.openjdk.java.net/browse/JDK-8243246 > > webrev: > http://cr.openjdk.java.net/~dfuchs/

Re: RFR[8243488]: 'Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'

> On 23 Apr 2020, at 16:46, Patrick Concannon > wrote: > > Hi, > > Could someone please review my fix for JDK-8243488 'Add tests for set/get > SendBufferSize and getReceiveBufferSize in DatagramSocket'? > > This fix adds tests for the methods: setSendBufferSize(int), > getSendBufferSize(),

Re: 8243246: HTTP Client sometimes gets java.io.IOException -> Invalid chunk header byte 32

> On 24 Apr 2020, at 16:14, Daniel Fuchs wrote: > > Hi Chris, > > On 23/04/2020 19:36, Chris Hegarty wrote: >> How do you feel about adding a byte-at-a-time final scenario? >> static final List REQ5_RESPONSE_BODY = List.of( >> "B", "

Re: RFR 8242999: http/2 client may not handle continuation frames correctly

Rahul, > On 24 Apr 2020, at 15:58, Rahul wrote: > > Hello, > > Request to have my fix reviewed for the issue: > JDK-8242999 : http/2 client may not handle continuation frames correctly. > > The fix updates jdk.internal.net.http.Stream.incoming(Http2Frame frame) to > handle > the

Re: RFR 8242999: http/2 client may not handle continuation frames correctly

Rahul, > On 27 Apr 2020, at 14:04, Rahul wrote: > > Thanks for the review comments. > I have updated the webrev : > http://cr.openjdk.java.net/~pconcannon/rayayada/8242999/webrevs/webrev.01/ Seems you took my suggestion too literally ;-) I capitalised some of the text to clearly demarcate it

Re: RFR[8243488]: 'Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'

> On 30 Apr 2020, at 11:40, Patrick Concannon > wrote: > > Hi, > > After some discussion offline, it was decided that a try-with-resources was > preferred to a @BeforeTest @AfterTest for creating and closing sockets. I’ve > updated the webrev to reflect this, and the new patch can be found

Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support

> On 30 Apr 2020, at 22:20, Ivanov, Vladimir A > wrote: > > One more update at > http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.05/ > The @apiNote section was updated a little bit to concentrate on > SO_INCOMING_NAPI_ID. I have not seen much discussion relating to possible

Re: RFR[8243488]: 'Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'

>> >> .. >> http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.03/ Ship it! -Chris.

Re: 8244283: test/jdk/sun/net/idn/TestStringPrep.java fails with --illegal-access=deny

> On 2 May 2020, at 15:37, Alan Bateman wrote: > > I need a reviewer for a small update to > test/jdk/sun/net/idn/TestStringPrep.java The test locates > sun/net/idn/uidna.spp in the java.base module so it needs sun.net.idn opened > for this to work when illegal reflective access is denied

Re: 8244205: HTTP/2 tunnel connections through proxy may be reused regardless of which proxy is selected

> On 1 May 2020, at 15:38, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > 8244205: HTTP/2 tunnel connections through proxy may be > reused regardless of which proxy is selected > https://bugs.openjdk.java.net/browse/JDK-8244205 > > webrev: > http://cr.openjdk.java.net

Re: RFR 8240666: Websocket client’s OpeningHandshake discards the HTTP response body

> On 6 May 2020, at 16:16, Daniel Fuchs wrote: > > Hi Rahul, > > LGTM. +1 -Chris.

Re: 8244031: HttpClient should have more tests for HEAD requests

> On 8 May 2020, at 16:46, Daniel Fuchs wrote: > > Hi, > > Please find a fix for: > > 8244031: HttpClient should have more tests for HEAD requests > https://bugs.openjdk.java.net/browse/JDK-8244031 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8244031/webrev.00/ Seems like a compr

Re: RFR [15] 8241378: j.net.URLConnection::getHeaderFieldKey(int) behavior does not reliably conform to its specification

LGTM. -Chris. > On 22 May 2020, at 09:53, Daniel Fuchs wrote: > > Hi Michael, > > This looks good to me. > > best regards, > > -- daniel > > On 22/05/2020 09:36, Michael McMahon wrote: >> Hi, >> Could I get the following small spec clarification reviewed please? >> Bug: https://bugs.openjdk

Re: 8235761: (httpclient) Investigate support for multipart/form-data in BodyPublishers

Thanks for posting here Moataz, I am busy with other work at the moment, but just to say that providing some level of support for multipart has come up a number of times (it is very useful). The built-in body publishers and subscribers are deliberately minimal, but it does seem that, at least,

Re: RFR[8244582]: 'Remove terminally deprecated Solaris-specific SO_FLOW_SLA socket option'

Patrick, > On 27 May 2020, at 16:41, Patrick Concannon > wrote: > > ... > bug: https://bugs.openjdk.java.net/browse/JDK-8244582 > csr: https://bugs.openjdk.java.net/browse/JDK-8245984 > webrev: http://cr.openjdk.java.net/~pconcannon/8245828/webrevs/webrev.00/ LGTM. -Chris.

Re: RFR: 8237470: HttpResponse.BodySubscriber::ofFile throws UOE with non-default file systems

Julia, > On 27 May 2020, at 10:00, Julia Boes wrote: > > .. > CSR (draft): https://bugs.openjdk.java.net/browse/JDK-8245770 I added myself as reviewer. > Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8237470/webrev.00/ Looks v. good to me Julia. Thanks, -Chris.

Re: RFR: 8246431: java/net/httpclient/PathSubscriber tests fail due to missing FilePermission

Julia, > On 4 Jun 2020, at 17:24, Julia Boes wrote: > > Hi, > > The tests in java/net/httpclient/PathSubscriber don't grant certain file > permissions to test library classes. The tests succeed by chance when the > compiled library classes are placed under ${test.classes}, but occasionally >

Re: RFR: 8246431: java/net/httpclient/PathSubscriber tests fail due to missing FilePermission

> On 8 Jun 2020, at 11:23, Julia Boes wrote: > > .. > > Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8246431/webrev.01/ LGTM. -Chris.

Re: RFR 8245307 : Update ExchangeImpl to use thread safe DateTimeFormatter

> On 12 Jun 2020, at 17:55, Rahul Yadav wrote: > > ... > > http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html > This looks v. good Rahul. A few, mostly pedantic, comments on the test: 1) In recent times, we’ve been bi

Re: RFR 8245307 : Update ExchangeImpl to use thread safe DateTimeFormatter

> On 15 Jun 2020, at 11:41, Rahul Yadav wrote: > > Hi Chris, Daniel > > Thank you for the comments. > I have included the feedback and updated webrev. > > http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html > > LGTM. Sh

Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found

Hi Alex, Mark, While I think that change for this issue is good, I would like to request that we please put it on hold temporarily. I will experiment with possible solutions for 8246714 - the URLClassLoader issue. It may result in no overlap with this issue, 8132359, but it seems prudent to al

Re: RFR 8247675 : Update DateFormatterTest Copyright

> On 16 Jun 2020, at 11:37, Rahul Yadav wrote: > > Hello, > > Request to have my fix reviewed for issue: > > JDK-8247675 : Update DateFormatterTest Copyright > > The fix updates the test DateFormatterTest, adds the missing > comma(,) to the copyright year. > > Issue:https://bugs.openj

Re: RFR 8245245 : WebSocket can loose the URL encoding of URI query parameters

> On 26 Jun 2020, at 15:10, Pavel Rappo wrote: > > Chris, > > Currently (i.e. before the proposed change has been applied) the fragment is > NOT retained. This is because of the requirement of the mentioned RFC > section. The proposed change seems to overlook that detail. Hence, my > quest

Re: RFR 8245245 : WebSocket can loose the URL encoding of URI query parameters

> On 26 Jun 2020, at 14:38, Pavel Rappo wrote: > > Rahul, > > Won't that start retaining the URL fragment? From > https://tools.ietf.org/html/rfc6455#section-3 > > Fragment identifiers are meaningless in the context of WebSocket URIs > and MUST NOT be used on these URIs. As with any UR

<    7   8   9   10   11   12   13   14   15   16   >