From mark.sheppard at oracle.com Wed Mar 4 21:53:32 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 04 Mar 2015 21:53:32 +0000 Subject: RFR: JDK-8065078 - NetworkInterface.getNetworkInterfaces() triggers intermittent test failures Message-ID: <54F77EDC.3020205@oracle.com> Hi please oblige and review the following small change http://cr.openjdk.java.net/~msheppar/8065078/webrev/ to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8065078 the getAdapters and getAdpater functions were amended in to add additional diagnostic of the error code, in the event of a failure, following the second invocation of GetAdpatersAddresses in the call flows. This has shown that the ERROR_BUFFER_OVERFLOW (i.e. 111) can occur even though the buffer, to hold the addresses, has been realloced to the size as per that returned in the variable len from the initial GetAdapatersAddresses. Thus, it is possible to have a "race condition" where configuration changes are taking place simultaneously to the NetworkInterface.getNetworkInterfaces() call The proposed change increases the initial size of the addresses buffer to 4096, and in the event of a failure increases the returned buffer size by this amount again. Additionally, the update of the static variable bufsize, after the realloc, was seen as potentially problematic and has thread safe implications, so these updates have been removed. The shared variable is not protected by a mutex during read and write of variable. regards Mark From weijun.wang at oracle.com Thu Mar 5 03:14:48 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 Mar 2015 11:14:48 +0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: <54F756AF.7060906@oracle.com> References: <54F756AF.7060906@oracle.com> Message-ID: Hi Jason I noticed several "@SuppressWarnings("deprecation")" in some sun.* or com.sun.* classes and it makes me feel uncomfortable. The usage of this annotation, if I understand correctly, means we know we should not use it but we have to use it because we are lazy or there are no better alternatives. I highly doubt if any is the case here. So, we should investigate how those methods are used. If they are strictly internal (not jdk.exported) and not used inside JDK, remove them since they will be inaccessible anymore in jdk9. If they are still used somewhere, consider rewriting them (maybe in another fix). If they are jdk.exported, rewrite if the deprecated interfaces is not shown in the API itself (type or argument or return), otherwise, @deprecate them also. Thanks Max > On Mar 5, 2015, at 03:02, Jason Uh wrote: > > webrev: http://cr.openjdk.java.net/~juh/8073430/00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8073430 > > Please review this change, which deprecates the classes in java.security.acl and javax.security.cert. These packages have been superseded by replacements for a long time. > > For java.security.acl, there have been replacement APIs available since JDK 1.2 in java.security.Policy and related classes. For javax.security.cert, replacements have existed in java.security.cert since JDK 1.4. These replacements have been noted in the javadocs, so applications using these old APIs have had plenty of time to migrate. > > Two methods > > HandshakeCompletedEvent.getPeerCertificateChain > SSLSession.getPeerCertificateChain > > that return the javax.security.cert.X509Certificate type will also be deprecated. > > The change also includes deprecation warning suppression in a few areas, including sun.net.www.protocol.https. > > Thanks, > Jason From chris.hegarty at oracle.com Thu Mar 5 14:09:24 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 5 Mar 2015 14:09:24 +0000 Subject: RFR: JDK-8065078 - NetworkInterface.getNetworkInterfaces() triggers intermittent test failures In-Reply-To: <54F77EDC.3020205@oracle.com> References: <54F77EDC.3020205@oracle.com> Message-ID: <70BA4E9C-34EC-485F-A884-CCA84D9BD119@oracle.com> On 4 Mar 2015, at 21:53, Mark Sheppard wrote: > Hi > please oblige and review the following small change > http://cr.openjdk.java.net/~msheppar/8065078/webrev/ I agree with the increased buffer size, and the strategy you have employed. I think you just need to remove a few comments, otherwise looks fine to me. -Chris. > to address the issue raised in > https://bugs.openjdk.java.net/browse/JDK-8065078 > > the getAdapters and getAdpater functions were amended in > to add additional diagnostic of the error code, in the event of a > failure, following the second invocation of GetAdpatersAddresses in the call flows. > This has shown that the ERROR_BUFFER_OVERFLOW (i.e. 111) > can occur even though the buffer, to hold the addresses, has been realloced > to the size as per that returned in the variable len > from the initial GetAdapatersAddresses. Thus, it is possible to have a "race condition" where > configuration changes are taking place simultaneously to > the NetworkInterface.getNetworkInterfaces() call > > The proposed change increases the initial size of the addresses buffer to 4096, > and in the event of a failure increases the returned buffer size by this amount again. > > Additionally, the update of the static variable bufsize, after the realloc, was seen as potentially problematic > and has thread safe implications, so these updates have been removed. The shared variable is not protected > by a mutex during read and write of variable. > > regards > Mark From mark.sheppard at oracle.com Thu Mar 5 15:48:43 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 05 Mar 2015 15:48:43 +0000 Subject: RFR: JDK-8065078 - NetworkInterface.getNetworkInterfaces() triggers intermittent test failures In-Reply-To: <70BA4E9C-34EC-485F-A884-CCA84D9BD119@oracle.com> References: <54F77EDC.3020205@oracle.com> <70BA4E9C-34EC-485F-A884-CCA84D9BD119@oracle.com> Message-ID: <54F87ADB.2010608@oracle.com> thanks for the review Chris regards Mark On 05/03/2015 14:09, Chris Hegarty wrote: > On 4 Mar 2015, at 21:53, Mark Sheppard wrote: > >> Hi >> please oblige and review the following small change >> http://cr.openjdk.java.net/~msheppar/8065078/webrev/ > I agree with the increased buffer size, and the strategy you have employed. I think you just need to remove a few comments, otherwise looks fine to me. > > -Chris. > >> to address the issue raised in >> https://bugs.openjdk.java.net/browse/JDK-8065078 >> >> the getAdapters and getAdpater functions were amended in >> to add additional diagnostic of the error code, in the event of a >> failure, following the second invocation of GetAdpatersAddresses in the call flows. >> This has shown that the ERROR_BUFFER_OVERFLOW (i.e. 111) >> can occur even though the buffer, to hold the addresses, has been realloced >> to the size as per that returned in the variable len >> from the initial GetAdapatersAddresses. Thus, it is possible to have a "race condition" where >> configuration changes are taking place simultaneously to >> the NetworkInterface.getNetworkInterfaces() call >> >> The proposed change increases the initial size of the addresses buffer to 4096, >> and in the event of a failure increases the returned buffer size by this amount again. >> >> Additionally, the update of the static variable bufsize, after the realloc, was seen as potentially problematic >> and has thread safe implications, so these updates have been removed. The shared variable is not protected >> by a mutex during read and write of variable. >> >> regards >> Mark From jason.uh at oracle.com Wed Mar 4 19:02:07 2015 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 04 Mar 2015 11:02:07 -0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded Message-ID: <54F756AF.7060906@oracle.com> webrev: http://cr.openjdk.java.net/~juh/8073430/00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8073430 Please review this change, which deprecates the classes in java.security.acl and javax.security.cert. These packages have been superseded by replacements for a long time. For java.security.acl, there have been replacement APIs available since JDK 1.2 in java.security.Policy and related classes. For javax.security.cert, replacements have existed in java.security.cert since JDK 1.4. These replacements have been noted in the javadocs, so applications using these old APIs have had plenty of time to migrate. Two methods HandshakeCompletedEvent.getPeerCertificateChain SSLSession.getPeerCertificateChain that return the javax.security.cert.X509Certificate type will also be deprecated. The change also includes deprecation warning suppression in a few areas, including sun.net.www.protocol.https. Thanks, Jason From sean.mullan at oracle.com Thu Mar 5 21:35:04 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 05 Mar 2015 16:35:04 -0500 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: <54F756AF.7060906@oracle.com> References: <54F756AF.7060906@oracle.com> Message-ID: <54F8CC08.6070406@oracle.com> Looks good, Jason, just a couple of comments: - Add an @Deprecated annotation to the package-info.java files since the entire package is deprecated. Put {@code} around the package/class names. - add a noreg label to the bug --Sean On 03/04/2015 02:02 PM, Jason Uh wrote: > webrev: http://cr.openjdk.java.net/~juh/8073430/00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8073430 > > Please review this change, which deprecates the classes in > java.security.acl and javax.security.cert. These packages have been > superseded by replacements for a long time. > > For java.security.acl, there have been replacement APIs available since > JDK 1.2 in java.security.Policy and related classes. For > javax.security.cert, replacements have existed in java.security.cert > since JDK 1.4. These replacements have been noted in the javadocs, so > applications using these old APIs have had plenty of time to migrate. > > Two methods > > HandshakeCompletedEvent.getPeerCertificateChain > SSLSession.getPeerCertificateChain > > that return the javax.security.cert.X509Certificate type will also be > deprecated. > > The change also includes deprecation warning suppression in a few areas, > including sun.net.www.protocol.https. > > Thanks, > Jason From jason.uh at oracle.com Fri Mar 6 04:01:20 2015 From: jason.uh at oracle.com (Jason Uh) Date: Thu, 05 Mar 2015 20:01:20 -0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: References: <54F756AF.7060906@oracle.com> Message-ID: <54F92690.2070301@oracle.com> Hi Max, A couple of these, we probably won't be able to remove in JDK 9. I'm deprecating getPeerCertificateChain() in the javax.net.ssl.SSLSession interface in this change, so the implementation in sun.security.ssl.SSLSessionImpl will have to be suppressed. Also, X509V1CertImpl will probably have to be marked with @SupressWarnings in JDK 9 and then hopefully it can be removed altogether in JDK 10 along with javax.security.cert. As for some of the other methods causing warnings, I think they can actually be removed, but I'd like to track that change in a different issue. I'm not sure yet, but there might have to be some minor test changes to accommodate the changes, too. I filed an issue to track it: https://bugs.openjdk.java.net/browse/JDK-8074531 For now, here are my changes again with Sean's suggested changes to the package-info.java files. http://cr.openjdk.java.net/~juh/8073430/01/ Thanks, Jason On 03/04/2015 07:14 PM, Wang Weijun wrote: > Hi Jason > > I noticed several "@SuppressWarnings("deprecation")" in some sun.* or com.sun.* classes and it makes me feel uncomfortable. The usage of this annotation, if I understand correctly, means we know we should not use it but we have to use it because we are lazy or there are no better alternatives. I highly doubt if any is the case here. > > So, we should investigate how those methods are used. If they are strictly internal (not jdk.exported) and not used inside JDK, remove them since they will be inaccessible anymore in jdk9. If they are still used somewhere, consider rewriting them (maybe in another fix). If they are jdk.exported, rewrite if the deprecated interfaces is not shown in the API itself (type or argument or return), otherwise, @deprecate them also. > > Thanks > Max > >> On Mar 5, 2015, at 03:02, Jason Uh wrote: >> >> webrev: http://cr.openjdk.java.net/~juh/8073430/00/ >> jbs: https://bugs.openjdk.java.net/browse/JDK-8073430 >> >> Please review this change, which deprecates the classes in java.security.acl and javax.security.cert. These packages have been superseded by replacements for a long time. >> >> For java.security.acl, there have been replacement APIs available since JDK 1.2 in java.security.Policy and related classes. For javax.security.cert, replacements have existed in java.security.cert since JDK 1.4. These replacements have been noted in the javadocs, so applications using these old APIs have had plenty of time to migrate. >> >> Two methods >> >> HandshakeCompletedEvent.getPeerCertificateChain >> SSLSession.getPeerCertificateChain >> >> that return the javax.security.cert.X509Certificate type will also be deprecated. >> >> The change also includes deprecation warning suppression in a few areas, including sun.net.www.protocol.https. >> >> Thanks, >> Jason > From weijun.wang at oracle.com Fri Mar 6 05:30:54 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 6 Mar 2015 13:30:54 +0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: <54F92690.2070301@oracle.com> References: <54F756AF.7060906@oracle.com> <54F92690.2070301@oracle.com> Message-ID: <5BE06A5F-D58D-4950-9DE2-444E5C2808A1@oracle.com> Instead of adding @SupressWarnings to a method, can we add @Deprecated to it? If I understand correctly, there should be no warning if a deprecated method calls another deprecated method. And by deprecating the caller we will get warnings if they are called by more methods and we can evaluate if they can be further deprecated or modified. This way we would reveal everything that is related with the deprecated APIs. Hopefully they are actually useless inside JDK. --Max > On Mar 6, 2015, at 12:01, Jason Uh wrote: > > Hi Max, > > A couple of these, we probably won't be able to remove in JDK 9. I'm deprecating getPeerCertificateChain() in the javax.net.ssl.SSLSession interface in this change, so the implementation in sun.security.ssl.SSLSessionImpl will have to be suppressed. Also, X509V1CertImpl will probably have to be marked with @SupressWarnings in JDK 9 and then hopefully it can be removed altogether in JDK 10 along with javax.security.cert. > > As for some of the other methods causing warnings, I think they can actually be removed, but I'd like to track that change in a different issue. I'm not sure yet, but there might have to be some minor test changes to accommodate the changes, too. I filed an issue to track it: > https://bugs.openjdk.java.net/browse/JDK-8074531 > > For now, here are my changes again with Sean's suggested changes to the package-info.java files. > http://cr.openjdk.java.net/~juh/8073430/01/ > > Thanks, > Jason From weijun.wang at oracle.com Fri Mar 6 05:32:16 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 6 Mar 2015 13:32:16 +0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: <5BE06A5F-D58D-4950-9DE2-444E5C2808A1@oracle.com> References: <54F756AF.7060906@oracle.com> <54F92690.2070301@oracle.com> <5BE06A5F-D58D-4950-9DE2-444E5C2808A1@oracle.com> Message-ID: <1C7683D4-B6DA-487E-BB10-800B01ABEC74@oracle.com> What is the policy for deprecating a non-public-API method? > On Mar 6, 2015, at 13:30, Wang Weijun wrote: > > Instead of adding @SupressWarnings to a method, can we add @Deprecated to it? From jason.uh at oracle.com Sat Mar 7 05:05:03 2015 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 06 Mar 2015 21:05:03 -0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: <1C7683D4-B6DA-487E-BB10-800B01ABEC74@oracle.com> References: <54F756AF.7060906@oracle.com> <54F92690.2070301@oracle.com> <5BE06A5F-D58D-4950-9DE2-444E5C2808A1@oracle.com> <1C7683D4-B6DA-487E-BB10-800B01ABEC74@oracle.com> Message-ID: <54FA86FF.60201@oracle.com> While these methods are going to be removed soon anyway, @Deprecated actually seems like the more appropriate choice because we do want to discourage use of these methods, even if they are non-public APIs. Here it is with that change; please take a look: http://cr.openjdk.java.net/~juh/8073430/02/ Thanks, Jason On 03/05/2015 09:32 PM, Wang Weijun wrote: > What is the policy for deprecating a non-public-API method? > >> On Mar 6, 2015, at 13:30, Wang Weijun wrote: >> >> Instead of adding @SupressWarnings to a method, can we add @Deprecated to it? > From weijun.wang at oracle.com Mon Mar 9 07:05:53 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 9 Mar 2015 15:05:53 +0800 Subject: [9] RFR: 8073430: Deprecate security APIs that have been superseded In-Reply-To: <54FA86FF.60201@oracle.com> References: <54F756AF.7060906@oracle.com> <54F92690.2070301@oracle.com> <5BE06A5F-D58D-4950-9DE2-444E5C2808A1@oracle.com> <1C7683D4-B6DA-487E-BB10-800B01ABEC74@oracle.com> <54FA86FF.60201@oracle.com> Message-ID: <2AE37A92-7263-48AF-86AB-357D8D345483@oracle.com> Code change looks fine. Thanks Max > On Mar 7, 2015, at 13:05, Jason Uh wrote: > > While these methods are going to be removed soon anyway, @Deprecated actually seems like the more appropriate choice because we do want to discourage use of these methods, even if they are non-public APIs. > > Here it is with that change; please take a look: > http://cr.openjdk.java.net/~juh/8073430/02/ > > Thanks, > Jason > > On 03/05/2015 09:32 PM, Wang Weijun wrote: >> What is the policy for deprecating a non-public-API method? >> >>> On Mar 6, 2015, at 13:30, Wang Weijun wrote: >>> >>> Instead of adding @SupressWarnings to a method, can we add @Deprecated to it? >> From michael.x.mcmahon at oracle.com Mon Mar 9 16:27:33 2015 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 09 Mar 2015 16:27:33 +0000 Subject: HTTP 2 client API Message-ID: <54FDC9F5.7010705@oracle.com> Hi, JEP 110 HTTP 2 client in JDK 9, is defining and implementing a new API for HTTP which also supports the new HTTP version 2 that has recently been working its way through the IETF. The work also includes support for websockets (RFC 6455). In fact, the majority of the API is agnostic about the HTTP protocol version, with only minor configuration settings, and support for multiple responses (Http server push) having any direct impact. The HTTP API is defined around three main types (HttpClient, which is the central point for configuration of SSL, executor service cookie management etc), HttpRequest and HttpResponse (which should be self explanatory). Requests are sent/received either synchronously (blocking) or in a non-blocking (asynchronous) mode using java.util.future.CompletableFuture which is a powerful new framework for asynchronous execution introduced in JDK 8. The API docs can be seen at the link below: http://cr.openjdk.java.net/~michaelm/httpclient/01/ All new classes and interfaces belong to the java.net package. A prototype implementation of this API supporting HTTP/1.1 only, is available and will be uploaded into the JDK 9 sandbox forest in the coming day or two. Comments welcome! Thanks, Michael. From doychin at dsoft-bg.com Wed Mar 11 07:02:14 2015 From: doychin at dsoft-bg.com (Doychin Bondzhev) Date: Wed, 11 Mar 2015 09:02:14 +0200 Subject: Patch for NetworkInterface.c to fix incorrect returned values for broadcast address and net mask on Linux In-Reply-To: References: Message-ID: <54FFE876.6000109@dsoft-bg.com> Hi, Anyone who wants to review this patch? Thanks in advance On 20.1.2015 ?. 22:20 ?., Doychin Bondzhev wrote: > Hi, > > Please review this patch > http://dmitryalexandrov.net/~bgjug/network-interface/webrev.00/ > > It fixes the problem described in this thread > > http://mail.openjdk.java.net/pipermail/net-dev/2014-December/008806.html > > Also in order to setup dummy interface with test values you can use > these commands: > > ip link add dummy0 type dummy > > ip addr add 10.5.5.1/28 brd 10.5.5.15 dev dummy0 > ip addr add 10.6.0.1/23 brd 10.6.1.255 dev dummy0 > ip addr add 10.7.0.1/25 brd 10.7.0.127 dev dummy0 > > The output from NetworkInterface test > test/java/net/NetworkInterface/NetParamsTest.java for this interface is: > > dummy0 : > Status: DOWN > Hardware Address: 56:ffffffd4:fffffffd:ffffffc2:ffffffec:ffffff82: > Loopback: false > Point to Point: false > Virtual: false > Multicast: false > MTU: 1500 > Bindings: > /10.7.0.1/25 [/10.7.0.127 ] > /10.6.0.1/23 [/10.6.1.255 ] > /10.5.5.1/28 [/10.5.5.15 ] > > This is the output from Java 1.8.0_25. Same output is produced with > existing version of NetworkInterface.c in JDK 9 > > dummy0 : > Status: DOWN > Hardware Address: 56:ffffffd4:fffffffd:ffffffc2:ffffffec:ffffff82: > Loopback: false > Point to Point: false > Virtual: false > Multicast: false > MTU: 1500 > Bindings: > /10.7.0.1/28 [/10.5.5.15 ] > /10.6.0.1/28 [/10.5.5.15 ] > /10.5.5.1/28 [/10.5.5.15 ] > > -- Doychin Bondzhev dSoft-Bulgaria Ltd. PowerPro - billing & provisioning solution for Service providers PowerStor - Warehouse & POS http://www.dsoft-bg.com/ Mobile: +359888243116 -------------- next part -------------- A non-text attachment was scrubbed... Name: doychin.vcf Type: text/x-vcard Size: 268 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5924 bytes Desc: S/MIME Cryptographic Signature URL: From jason.uh at oracle.com Wed Mar 18 21:52:44 2015 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 18 Mar 2015 14:52:44 -0700 Subject: [9] RFR: 8074531: Remove javax.security.cert.X509Certificate usage in internal networking packages Message-ID: <5509F3AC.4030809@oracle.com> Please review this change, which removes methods in internal net packages that use the deprecated javax.security.cert.X509Certificate type. webrev: http://cr.openjdk.java.net/~juh/8074531/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8074531 Thanks, Jason From rob.mckenna at oracle.com Wed Mar 18 23:27:00 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 18 Mar 2015 23:27:00 +0000 Subject: RFR: 8075039: (sctp) com/sun/nio/sctp/SctpMultiChannel/SendFailed.java fails on Solaris only Message-ID: <550A09C4.5050208@oracle.com> Hi folks, Mistakenly neglected to exclude Solaris from testing: http://cr.openjdk.java.net/~robm/8075039/webrev.01/ -Rob From rob.mckenna at oracle.com Wed Mar 18 23:28:06 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 18 Mar 2015 23:28:06 +0000 Subject: RFR: 8075039: (sctp) com/sun/nio/sctp/SctpMultiChannel/SendFailed.java fails on Solaris only In-Reply-To: <550A09C4.5050208@oracle.com> References: <550A09C4.5050208@oracle.com> Message-ID: <550A0A06.407@oracle.com> Pressed send a little too early. This test was added by: 8067846: (sctp) InternalError when receiving SendFailedNotification http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b10dc4dc6903 -Rob On 18/03/15 23:27, Rob McKenna wrote: > Hi folks, > > Mistakenly neglected to exclude Solaris from testing: > > http://cr.openjdk.java.net/~robm/8075039/webrev.01/ > > -Rob From brian.burkhalter at oracle.com Thu Mar 19 14:30:05 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 19 Mar 2015 07:30:05 -0700 Subject: [9] RFR of 8074937: ServerSocket.accept() API Descriptions should include past tense Message-ID: Please review at your convenience. This a doc-only change. Issue: https://bugs.openjdk.java.net/browse/JDK-8074937 Patch: http://cr.openjdk.java.net/~bpb/8074937/webrev.00/ This is in effect an amplification of extant javadoc suggested as an enhancement by an external user. I performed some testing to verify the accuracy of the suggested documentation change prior to crafting the verbiage, and the criticism does seem to be well-founded in the behavior of the APIs in question. It would be good however if someone with a more profound knowledge of this area were to review the proposed documentation update for accuracy, especially as it is not unlikely that there might be platform-specific behavior with which these statements conflict. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Mar 19 14:47:39 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Mar 2015 14:47:39 +0000 Subject: [9] RFR of 8074937: ServerSocket.accept() API Descriptions should include past tense In-Reply-To: References: Message-ID: <550AE18B.1040708@oracle.com> On 19/03/2015 14:30, Brian Burkhalter wrote: > Please review at your convenience. This a doc-only change. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8074937 > Patch:http://cr.openjdk.java.net/~bpb/8074937/webrev.00/ > > > This is in effect an amplification of extant javadoc suggested as an > enhancement by an external user. I performed some testing to verify > the accuracy of the suggested documentation change prior to crafting > the verbiage, and the criticism does seem to be well-founded in the > behavior of the APIs in question. > > It would be good however if someone with a more profound knowledge of > this area were to review the proposed documentation update for > accuracy, especially as it is not unlikely that there might be > platform-specific behavior with which these statements conflict. listen is documented on many platforms to be the maximum length of the queue of pending connections so not clear to me that you really want to change that. In ServerSocketChannel.bind then it is documented as: *

The {@code backlog} parameter is the maximum number of pending * connections on the socket. Its exact semantics are implementation specific. * In particular, an implementation may impose a maximum length or may choose * to ignore the parameter altogether. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Mar 19 15:23:54 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 19 Mar 2015 15:23:54 +0000 Subject: [9] RFR of 8074937: ServerSocket.accept() API Descriptions should include past tense In-Reply-To: <550AE18B.1040708@oracle.com> References: <550AE18B.1040708@oracle.com> Message-ID: <550AEA0A.3080901@oracle.com> I would personally close this as 'not a bug'. I see no value in trying add additional clarification around something that has never, to the best of my knowledge, been the source of confusion. The description in JIRA seems overly pedantic. -Chris. On 19/03/15 14:47, Alan Bateman wrote: > On 19/03/2015 14:30, Brian Burkhalter wrote: >> Please review at your convenience. This a doc-only change. >> >> Issue:https://bugs.openjdk.java.net/browse/JDK-8074937 >> Patch:http://cr.openjdk.java.net/~bpb/8074937/webrev.00/ >> >> >> This is in effect an amplification of extant javadoc suggested as an >> enhancement by an external user. I performed some testing to verify >> the accuracy of the suggested documentation change prior to crafting >> the verbiage, and the criticism does seem to be well-founded in the >> behavior of the APIs in question. >> >> It would be good however if someone with a more profound knowledge of >> this area were to review the proposed documentation update for >> accuracy, especially as it is not unlikely that there might be >> platform-specific behavior with which these statements conflict. > listen is documented on many platforms to be the maximum length of the > queue of pending connections so not clear to me that you really want to > change that. > > In ServerSocketChannel.bind then it is documented as: > > *

The {@code backlog} parameter is the maximum number of pending > * connections on the socket. Its exact semantics are > implementation specific. > * In particular, an implementation may impose a maximum length or > may choose > * to ignore the parameter altogether. > > -Alan. From chris.hegarty at oracle.com Thu Mar 19 15:26:52 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 19 Mar 2015 15:26:52 +0000 Subject: RFR: 8075039: (sctp) com/sun/nio/sctp/SctpMultiChannel/SendFailed.java fails on Solaris only In-Reply-To: <550A0A06.407@oracle.com> References: <550A09C4.5050208@oracle.com> <550A0A06.407@oracle.com> Message-ID: <550AEABC.3000703@oracle.com> Looks ok to me Rob. -Chris. On 18/03/15 23:28, Rob McKenna wrote: > Pressed send a little too early. This test was added by: > > 8067846: (sctp) InternalError when receiving SendFailedNotification > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b10dc4dc6903 > > -Rob > > On 18/03/15 23:27, Rob McKenna wrote: >> Hi folks, >> >> Mistakenly neglected to exclude Solaris from testing: >> >> http://cr.openjdk.java.net/~robm/8075039/webrev.01/ >> >> -Rob > From brian.burkhalter at oracle.com Thu Mar 19 16:52:34 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 19 Mar 2015 09:52:34 -0700 Subject: [9] RFR of 8074937: ServerSocket.accept() API Descriptions should include past tense In-Reply-To: <550AEA0A.3080901@oracle.com> References: <550AE18B.1040708@oracle.com> <550AEA0A.3080901@oracle.com> Message-ID: <3F17E30F-B2E3-4DD8-BCBC-62742FDD2F0A@oracle.com> Chris, Fine with me. I concur about the verbiage in the description. Alan, Thanks for the background and pointer to other clarifications. Brian On Mar 19, 2015, at 8:23 AM, Chris Hegarty wrote: > I would personally close this as 'not a bug'. > > I see no value in trying add additional clarification around something that has never, to the best of my knowledge, been the source of confusion. The description in JIRA seems overly pedantic. > > -Chris. > > On 19/03/15 14:47, Alan Bateman wrote: >> On 19/03/2015 14:30, Brian Burkhalter wrote: >>> Please review at your convenience. This a doc-only change. >>> >>> Issue:https://bugs.openjdk.java.net/browse/JDK-8074937 >>> Patch:http://cr.openjdk.java.net/~bpb/8074937/webrev.00/ >>> >>> >>> This is in effect an amplification of extant javadoc suggested as an >>> enhancement by an external user. I performed some testing to verify >>> the accuracy of the suggested documentation change prior to crafting >>> the verbiage, and the criticism does seem to be well-founded in the >>> behavior of the APIs in question. >>> >>> It would be good however if someone with a more profound knowledge of >>> this area were to review the proposed documentation update for >>> accuracy, especially as it is not unlikely that there might be >>> platform-specific behavior with which these statements conflict. >> listen is documented on many platforms to be the maximum length of the >> queue of pending connections so not clear to me that you really want to >> change that. >> >> In ServerSocketChannel.bind then it is documented as: >> >> *

The {@code backlog} parameter is the maximum number of pending >> * connections on the socket. Its exact semantics are >> implementation specific. >> * In particular, an implementation may impose a maximum length or >> may choose >> * to ignore the parameter altogether. >> >> -Alan. From brian.burkhalter at oracle.com Thu Mar 19 18:08:36 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 19 Mar 2015 11:08:36 -0700 Subject: [9] RFR of 8074937: ServerSocket.accept() API Descriptions should include past tense In-Reply-To: <550AE18B.1040708@oracle.com> References: <550AE18B.1040708@oracle.com> Message-ID: Identical verbiage is in fact also present in http://docs.oracle.com/javase/8/docs/api/java/net/ServerSocket.html#ServerSocket-int-int- and http://docs.oracle.com/javase/8/docs/api/java/net/ServerSocket.html#ServerSocket-int-int-java.net.InetAddress- To wit: "The backlog argument is the requested maximum number of pending connections on the socket. Its exact semantics are implementation specific. In particular, an implementation may impose a maximum length or may choose to ignore the parameter altogther. The value provided should be greater than 0. If it is less than or equal to 0, then an implementation specific default will be used." Brian On Mar 19, 2015, at 7:47 AM, Alan Bateman wrote: > In ServerSocketChannel.bind then it is documented as: > > *

The {@code backlog} parameter is the maximum number of pending > * connections on the socket. Its exact semantics are implementation specific. > * In particular, an implementation may impose a maximum length or may choose > * to ignore the parameter altogether. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.vanelverdinghe at gmail.com Sat Mar 21 10:44:46 2015 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Sat, 21 Mar 2015 11:44:46 +0100 Subject: HTTP 2 client API In-Reply-To: <54FDC9F5.7010705@oracle.com> References: <54FDC9F5.7010705@oracle.com> Message-ID: <550D4B9E.3040903@gmail.com> Hi Michael Please find my feedback on the current API docs below. It's divided in 3 parts: API (mostly questions), documentation (mostly suggestions for clarifications) and spelling. Thanks in advance for your consideration. Kind regards, Anthony === API === * will there be support for HTTP 2.0 stream prioritization? For example by providing a method requestHttp2(int priority) in HttpClient.Builder/HttpRequest.Builder? This way one could create 2 clients with a different priority: a low-priority one for background downloads of documents/large files, and a high-priority one for status updates. Then the 2 clients would use the same TCP connection, but different streams with different priorities. * which convenience methods will be added to existing classes, if any? I'm particularly thinking of URL, which already has openConnection/openStream convenience methods for the old API. * how is compression (the Accept-Encoding/Content-Encoding/Transfer-Encoding headers) handled? Is this handled transparently by the HttpClient? For example, if I request a text document, will the client automatically send a header "Accept-Encoding: gzip, deflate" (this is the current default in Firefox)? And once I receive the response, transparently decompress it, so I can just do "response.body(asString())"? * how is caching handled? Is there anything analog to "useCaches" in java.net.URLConnection? * HttpClient.Builder: concerning "followRedirects", I feel there are 2 more options that ought to be possible to be set: "same-protocol" (i.e. the current java.net.HttpURLConnection behavior) and "secure" (all redirects are allowed, except for redirects from https to http). A possible solution might be to introduce a "RedirectPolicy" enum with 4 constants: NEVER, ALWAYS, SAME_PROTOCOL, SECURE. Then the method would become "followRedirects(RedirectPolicy policy)". * HttpClient.Builder: the documentation for "requestHttp2" says: "If that fails, then following requests will not attempt to upgrade again." How is it determined that the upgrade to HTTP/2 fails? For example, is the client able to distinguish "the upgrade to HTTP/2 failed" from "some error occured which caused the request to fail" (e.g. the server is down)? And how can I force to attempt to upgrade again, for a specific origin and/or all origins? For example in the case of application servers, having to restart the JVM just to have the HTTP/2 upgrade to be attempted again, seems rather harsh. * HttpHeaders: why is the method "firstValueAsInt" and not "firstValueAsLong"? If I want to download e.g. the .iso file of Oracle Linux, the value of Content-Length will be too big and a NumberFormatException will be thrown. * HttpHeaders: why is there only a special case for "firstValueAsInt"? Personally, I would like some more methods to be added: ** java.time.OffsetDateTime firstValueAsDate(String name, Supplier defaultValue) which parses headers such as Expired & Last-Modified, using the datetime format recommended by RFC 7231 (i.e. the format defined in RFC 5322) ** javax.activation.MimeType firstValueAsMimeType(String name, Supplier defaultValue) which parses headers such as Content-Type & Accept-Patch ** List allCookies() which returns a list of all cookies * HttpHeaders: for the proposed first*() methods, please also consider the signature: Optional firstValueAsT(String name). This way, the application developer can decide whether to use a default value or to throw an exception (or anything else) when the header is absent. * HttpRequest/HttpResponse: why weren't the static methods added to the interfaces (HttpRequestBodyProcessor/HttpResponseBodyProcessor/MultiResponseProcessor) instead? In my opinion, this would be more logical, and would simplify the API of HttpRequest/HttpResponse. * HttpRequest.Builder: add validation to header/method/setHeader (according to the rules in RFC 7230) & throw an IllegalArgumentException if validation fails * HttpRequest.Builder: for "method", how is the parameter handled? Since method is case-sensitive ( cf. https://tools.ietf.org/html/rfc7230#section-3.1.1 ), creating a request with "delete" may fail, simply because it should be "DELETE". I think it would be good to at least add a Javadoc note about the case-sensitivity, and that the standardized methods ( http://tools.ietf.org/html/rfc7231#section-4.1 ) are defined as all-uppercase. * HttpRequest: I'd propose to rename fromByteArray(Iterator) to fromByteArrays * HttpRequest::fromString and HttpResponse::asString should take a java.nio.charset.Charset as parameter * HttpResponse: in my opinion, "asFile" should take a Path as parameter & the parameter name should be "file", instead of "filename" * HttpResponse: concerning the "asString" methods: they refer to "the character set specified in the Content-encoding response header". However, this should be "the character set specified in the charset parameter of the Content-type response header". * WebSocket: the documentation says "Once the WebSocket is available, WebSocketMessages can be created and sent either blocking or asynchronously.". What does it mean to create a message asynchronously? And how can I send a message asynchronously (without manually creating a CompletableFuture), as there isn't a "sendAsync" method in WebSocket? * WebSocket: in "Asynchronous example", I believe "sockets" should be defined as "new CopyOnWriteArrayList<>()", since LinkedList is not thread-safe? Also, I personally would declare "futures" as "new ArrayList<>()" (unless there's a compelling reason to use LinkedList of which I'm unaware?). * please consider adding a HttpResponseBodyProcessor implementation "asDefined()", which uses the same mechanism as java.net.URLConnection::getContent (i.e. using the Content-Type header & ContentHandlers) to determine the object to return. This would allow for easy migration from the old API to the new API. (the "defined" in the method name refers to the fact that the value of the Content-Type header is used) * please consider adding a HttpResponseBodyProcessor implementation "asFileDownload(Path downloadDirectory, OpenOption... openOptions)". This would determine the filename automatically, exactly as browsers do by inspecting e.g. the Content-Disposition header. === documentation === * as I'm sure you are aware, the package Javadoc should be updated to document the new API. I also think it would be good to clarify its relation to the old API, JAX-RS and Java API for WebSocket (the latter 2 of which will, I assume, in future versions use this API as the basis for their Client API implementations). * HttpClient: "Request builders are then created by calling request(URI) if associated with an application created client." rephrase as "Request builders that are associated with an application-created client, are created by calling request(URI)." * HttpClient.Builder: "If set, the first request to an origin server using "http" URLs will attempt to upgrade to HTTP version 2. If that fails, then following requests will not attempt to upgrade again." ** make "origin server" a hyperlink to https://tools.ietf.org/html/rfc6454#section-4 ** explicitly state "following requests to the same origin server" * HttpRequest: "A request's uri, headers and body can be set." change "uri" to "URI" & link it to java.net.URI * HttpRequest: currently, all examples specify ".body(noBody())". This gives the impression it's actually required. I propose to remove this from all examples of GET requests (especially the one in the "Two simple, example HTTP interactions" at the top). * HttpRequest::fromString and HttpResponse::asString: replace "ISO8859_1" with ISO-8859-1 and link to java.nio.charset.StandardCharsets.ISO_8859_1 * HttpResponse: "such as String, byte arrays, Files." change "Files" to "files", since "Files" suggests that it returns java.io.File, when instead it's java.nio.file.Path * HttpResponseBodyProcessor: "write responses to String, byte[], File, Consumer" change "File" to "file", since "File" suggests that it returns java.io.File, when instead it's java.nio.file.Path * HttpResponseBodyProcessor: "If an exact content length was provided in onRequestStart(), then that number of bytes must be provided." explicitly add "before returning null" at the end, so: "If an exact content length was provided in onRequestStart(), then that number of bytes must be provided before returning null." * WebSocket: add a note that using a WebSocket in a try-with-resources statement will cause the close to be done by closing the underlying TCP connection & what the possible implications are. === spelling === * HttpHeaders: "read only" should be "read-only" * HttpRequest: "any type as body," either has missing text after the comma, or the comma should be a point * HttpRequest: "client initiated" should be "client-initiated" * HttpRequest: "The response body can then be received (either synchronous or asynchronously)" should be "The response body can then be received (either synchronously or asynchronously)." * HttpRequest: "Path body = r2.body(asFile("/tmp/response.txt));" should be "Path body = r2.body(asFile("/tmp/response.txt"));" * HttpRequest: "All of above examples" should be "All of the above examples" * HttpRequest: "CompletableFuture; last =" should be "CompletableFuture last =" * HttpRequest: "Returns the HttpClient.requestHttp2() setting for this request." should note that this setting may have been overridden using HttpRequest.Builder.requestHttp2(), and therefore is not always equal to HttpClient.requestHttp2() * HttpRequest.Builder: "A builder of HttpRequests" should be "A builder of HttpRequests." (if you look at the package overview, all classes except this one have a point at the end) * HttpResponseBodyProcessor: "return null and the body" has missing text after body * MultiResponseProcessor: "provides the" should be "Provides the" * WebSocketMessage: "A WebSocketMessages (Binary or Text)" should be "A WebSocketMessage (Binary or Text)" On 9/03/2015 17:27, Michael McMahon wrote: > Hi, > > JEP 110 HTTP 2 client > > in JDK 9, is defining and implementing a new API for HTTP which also > supports > the new HTTP version 2 that has recently been working its way through > the IETF. > The work also includes support for websockets (RFC 6455). > > In fact, the majority of the API is agnostic about the HTTP protocol > version, with only minor > configuration settings, and support for multiple responses (Http > server push) having any direct impact. > > The HTTP API is defined around three main types (HttpClient, which is > the central > point for configuration of SSL, executor service cookie management > etc), HttpRequest > and HttpResponse (which should be self explanatory). > > Requests are sent/received either synchronously (blocking) or in a > non-blocking (asynchronous) > mode using java.util.future.CompletableFuture which is a powerful new > framework for > asynchronous execution introduced in JDK 8. > > The API docs can be seen at the link below: > > http://cr.openjdk.java.net/~michaelm/httpclient/01/ > > All new classes and interfaces belong to the java.net package. > > A prototype implementation of this API supporting HTTP/1.1 only, is > available and will > be uploaded into the JDK 9 sandbox forest in the coming day or two. > > Comments welcome! > > Thanks, > Michael. > From sean.mullan at oracle.com Mon Mar 23 18:57:14 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 23 Mar 2015 14:57:14 -0400 Subject: [9] RFR: 8074531: Remove javax.security.cert.X509Certificate usage in internal networking packages In-Reply-To: <5509F3AC.4030809@oracle.com> References: <5509F3AC.4030809@oracle.com> Message-ID: <5510620A.4040209@oracle.com> Hi Jason, * HttpsURLConnection.java, HttpsURLConnectionOldImpl.java This looks fine but as a next-step, we may be able to completely remove these classes, which have been deprecated for a long time and are implementation-specific. Can you check with Brad/Xuelei and open a separate issue to remove them if so? Otherwise, looks good. --Sean On 03/18/2015 05:52 PM, Jason Uh wrote: > Please review this change, which removes methods in internal net > packages that use the deprecated javax.security.cert.X509Certificate type. > > webrev: http://cr.openjdk.java.net/~juh/8074531/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8074531 > > Thanks, > Jason From sean.coffey at oracle.com Wed Mar 25 17:21:39 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 25 Mar 2015 17:21:39 +0000 Subject: RFR : 8072384 : Setting IP_TOS on java.net sockets not working on unix In-Reply-To: <54F05700.90402@oracle.com> References: <54F05700.90402@oracle.com> Message-ID: <5512EEA3.8020400@oracle.com> I didn't see any review on this request yet. I've modified the OptionsTest to test for IP_TOS on ServerSockets. The -Djava.net.preferIPv4Stack=true addition also allows the code to test both stacks where applicable. http://cr.openjdk.java.net/~coffeys/webrev.8072384.jdk9.v2/webrev/ regards, Sean. On 27/02/15 11:37, Se?n Coffey wrote: > It looks like setting and getting the IP_TOS values on the java.net > Sockets is currently broken for some scenarios. It's not possible to > set the value on a ServerSocket via the jdk.net.Sockets.setOption API. > See below for a webrev I'm proposing. It basically makes best efforts > to set the IP_TOS value by mapping it to the IPV6_TCLASS option in an > IPV6 enabled environment. NIO follows a similar approach. > > Some of the comments in NET_SetSockOpt seem to be legacy and I've > removed the no-op that was in place for IP_TOS. A corner case of > setting of IP_TOS was found on Solaris. It doesn't seem to support > setting the value once the socket is connected. I've handled this via > catching of exception and we should be ok with this since the spec > doesn't make any promises in this area if the socket is connected. > > I've been testing various fixes across IPv4/v6 sockets on Solaris, > Linux and macosx. So far, the proposed changes seem to work and > wireshark traces help to confirm that TOS/TCLASS values are being set. > > I still need to see if I can improve the getOpt logic for IP_TOS. At > the moment, it can return a cached value which may not represent the > true value in place at kernel socket level. I'll also improve test > coverage in this area. > > bug report : https://bugs.openjdk.java.net/browse/JDK-8072384 > webrev : > http://cr.openjdk.java.net/~coffeys/webrev.8072384.jdk9.v1/webrev/ > > regards, > Sean. > > From michael.x.mcmahon at oracle.com Wed Mar 25 17:33:04 2015 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 25 Mar 2015 17:33:04 +0000 Subject: HTTP 2 client API In-Reply-To: <550D4B9E.3040903@gmail.com> References: <54FDC9F5.7010705@oracle.com> <550D4B9E.3040903@gmail.com> Message-ID: <5512F150.70901@oracle.com> Hi Anthony, Comments/answers below On 21/03/15 10:44, Anthony Vanelverdinghe wrote: > Hi Michael > > Please find my feedback on the current API docs below. It's divided in > 3 parts: API (mostly questions), documentation (mostly suggestions for > clarifications) and spelling. > Thanks in advance for your consideration. > > Kind regards, Anthony > > === API === > * will there be support for HTTP 2.0 stream prioritization? For > example by providing a method requestHttp2(int priority) in > HttpClient.Builder/HttpRequest.Builder? This way one could create 2 > clients with a different priority: a low-priority one for background > downloads of documents/large files, and a high-priority one for status > updates. Then the 2 clients would use the same TCP connection, but > different streams with different priorities. > I think setting a default priority could be a useful first step in that direction, so long as we don't preclude full support of stream priority in the future, which includes per-request priority and inter-request dependencies. I think these would be settable per-request only, but the default would be on the client. > * which convenience methods will be added to existing classes, if any? > I'm particularly thinking of URL, which already has > openConnection/openStream convenience methods for the old API. > I hadn't planned adding any convenience methods to other classes. > * how is compression (the > Accept-Encoding/Content-Encoding/Transfer-Encoding headers) handled? > Is this handled transparently by the HttpClient? For example, if I > request a text document, will the client automatically send a header > "Accept-Encoding: gzip, deflate" (this is the current default in > Firefox)? And once I receive the response, transparently decompress > it, so I can just do "response.body(asString())"? > It wouldn't be transparent as such. But, it should be possible to implement it using HttpRequestBodyProcessor and HttpResponseBodyProcessor, but I wasn't planning to do it as part of this work initially. Someone could define a class like: class Deflator implements HttpResponseBodyProcessor { public Deflator(HttpResponseBodyProcessor p) {..} : } So Deflator takes another response processor and you might use it as: String body = response.body(new Deflator(asString())); or something similar. > * how is caching handled? Is there anything analog to "useCaches" in > java.net.URLConnection? > That is an omission in the current API. We need to add setting/getting of a java.net.ResponseCache to HttpClient(builder) > * HttpClient.Builder: concerning "followRedirects", I feel there are 2 > more options that ought to be possible to be set: "same-protocol" > (i.e. the current java.net.HttpURLConnection behavior) and "secure" > (all redirects are allowed, except for redirects from https to http). > A possible solution might be to introduce a "RedirectPolicy" enum with > 4 constants: NEVER, ALWAYS, SAME_PROTOCOL, SECURE. Then the method > would become "followRedirects(RedirectPolicy policy)". > That seems useful and exploits something the old API couldn;t support given that HttpsURLConnection was a subtype of HttpURLConnection > * HttpClient.Builder: the documentation for "requestHttp2" says: "If > that fails, then following requests will not attempt to upgrade > again." How is it determined that the upgrade to HTTP/2 fails? For > example, is the client able to distinguish "the upgrade to HTTP/2 > failed" from "some error occured which caused the request to fail" > (e.g. the server is down)? And how can I force to attempt to upgrade > again, for a specific origin and/or all origins? For example in the > case of application servers, having to restart the JVM just to have > the HTTP/2 upgrade to be attempted again, seems rather harsh. > There is some vagueness there, which I hoped to clarify after implementation starts. The upgrade "failing" just meant either the ALPN negotiation failing or in the case of h2c, that the server responds with a regualr HTTP/1.1 response (rather than a 101 Switching Protocols response). These mechanisms seem to be quite well defined in the spec and have nothing to do with other server errors (such as transient network errors) I think the upgrade should be attempted once per HttpClient instance. If it fails once, it's not likely to succeed soon again. But a new HttpClient instance can be created to retry if desired. > * HttpHeaders: why is the method "firstValueAsInt" and not > "firstValueAsLong"? If I want to download e.g. the .iso file of Oracle > Linux, the value of Content-Length will be too big and a > NumberFormatException will be thrown. > Good point. > * HttpHeaders: why is there only a special case for "firstValueAsInt"? > Personally, I would like some more methods to be added: > ** java.time.OffsetDateTime firstValueAsDate(String name, > Supplier defaultValue) which parses headers such as > Expired & Last-Modified, using the datetime format recommended by RFC > 7231 (i.e. the format defined in RFC 5322) > ** javax.activation.MimeType firstValueAsMimeType(String name, > Supplier defaultValue) which parses headers such as > Content-Type & Accept-Patch > ** List allCookies() which returns a list of all > cookies > Again, we're limited here in what we can do for the first version. Also, considering the modularity work for JDK 9 we are limited in the range of types we can reference from the "base" module, where this API will reside. > * HttpHeaders: for the proposed first*() methods, please also consider > the signature: Optional firstValueAsT(String name). This way, the > application developer can decide whether to use a default value or to > throw an exception (or anything else) when the header is absent. > How would that be implemented without knowing the type ? > * HttpRequest/HttpResponse: why weren't the static methods added to > the interfaces > (HttpRequestBodyProcessor/HttpResponseBodyProcessor/MultiResponseProcessor) > instead? In my opinion, this would be more logical, and would simplify > the API of HttpRequest/HttpResponse. > I'll consider that. > * HttpRequest.Builder: add validation to header/method/setHeader > (according to the rules in RFC 7230) & throw an > IllegalArgumentException if validation fails > I was intending to only apply the generic parsing rules. > * HttpRequest.Builder: for "method", how is the parameter handled? > Since method is case-sensitive ( cf. > https://tools.ietf.org/html/rfc7230#section-3.1.1 ), creating a > request with "delete" may fail, simply because it should be "DELETE". > I think it would be good to at least add a Javadoc note about the > case-sensitivity, and that the standardized methods ( > http://tools.ietf.org/html/rfc7231#section-4.1 ) are defined as > all-uppercase. > agreed. > * HttpRequest: I'd propose to rename fromByteArray(Iterator) > to fromByteArrays > agreed > * HttpRequest::fromString and HttpResponse::asString should take a > java.nio.charset.Charset as parameter > instead of the String name of the Charset? Will consider. > * HttpResponse: in my opinion, "asFile" should take a Path as > parameter & the parameter name should be "file", instead of "filename" > same as above > * HttpResponse: concerning the "asString" methods: they refer to "the > character set specified in the Content-encoding response header". > However, this should be "the character set specified in the charset > parameter of the Content-type response header". > Right. Good point. > * WebSocket: the documentation says "Once the WebSocket is available, > WebSocketMessages can be created and sent either blocking or > asynchronously.". What does it mean to create a message > asynchronously? And how can I send a message asynchronously (without > manually creating a CompletableFuture), as there isn't a "sendAsync" > method in WebSocket? > That's a mistake. The intent was that message sending would only be blocking/synchronous. Whereas receiving could be either blocking or asynchronous. > * WebSocket: in "Asynchronous example", I believe "sockets" should be > defined as "new CopyOnWriteArrayList<>()", since LinkedList is not > thread-safe? Also, I personally would declare "futures" as "new > ArrayList<>()" (unless there's a compelling reason to use LinkedList > of which I'm unaware?). > Yes, that was pointed out to me already. Thanks > * please consider adding a HttpResponseBodyProcessor implementation > "asDefined()", which uses the same mechanism as > java.net.URLConnection::getContent (i.e. using the Content-Type header > & ContentHandlers) to determine the object to return. This would allow > for easy migration from the old API to the new API. (the "defined" in > the method name refers to the fact that the value of the Content-Type > header is used) > How would you determine the type of object to return? I believe that was one limitation of that API in URLConnection > * please consider adding a HttpResponseBodyProcessor implementation > "asFileDownload(Path downloadDirectory, OpenOption... openOptions)". > This would determine the filename automatically, exactly as browsers > do by inspecting e.g. the Content-Disposition header. > Interesting idea. Though there is nothing to prevent that being implemented on top of this API I won't respond to the documentation comments individually, but will take them on board as appropriate. Many thanks for your comprehensive review! Michael > === documentation === > * as I'm sure you are aware, the package Javadoc should be updated to > document the new API. I also think it would be good to clarify its > relation to the old API, JAX-RS and Java API for WebSocket (the latter > 2 of which will, I assume, in future versions use this API as the > basis for their Client API implementations). > > * HttpClient: "Request builders are then created by calling > request(URI) if associated with an application created client." > rephrase as "Request builders that are associated with an > application-created client, are created by calling request(URI)." > > * HttpClient.Builder: "If set, the first request to an origin server > using "http" URLs will attempt to upgrade to HTTP version 2. If that > fails, then following requests will not attempt to upgrade again." > ** make "origin server" a hyperlink to > https://tools.ietf.org/html/rfc6454#section-4 > ** explicitly state "following requests to the same origin server" > > * HttpRequest: "A request's uri, headers and body can be set." > change "uri" to "URI" & link it to java.net.URI > > * HttpRequest: currently, all examples specify ".body(noBody())". This > gives the impression it's actually required. I propose to remove this > from all examples of GET requests (especially the one in the "Two > simple, example HTTP interactions" at the top). > > * HttpRequest::fromString and HttpResponse::asString: replace > "ISO8859_1" with ISO-8859-1 and link to > java.nio.charset.StandardCharsets.ISO_8859_1 > > * HttpResponse: "such as String, byte arrays, Files." > change "Files" to "files", since "Files" suggests that it returns > java.io.File, when instead it's java.nio.file.Path > > * HttpResponseBodyProcessor: "write responses to String, byte[], File, > Consumer" > change "File" to "file", since "File" suggests that it returns > java.io.File, when instead it's java.nio.file.Path > > * HttpResponseBodyProcessor: "If an exact content length was provided > in onRequestStart(), then that number of bytes must be provided." > explicitly add "before returning null" at the end, so: "If an exact > content length was provided in onRequestStart(), then that number of > bytes must be provided before returning null." > > * WebSocket: add a note that using a WebSocket in a try-with-resources > statement will cause the close to be done by closing the underlying > TCP connection & what the possible implications are. > > === spelling === > * HttpHeaders: "read only" > should be "read-only" > > * HttpRequest: "any type as body," > either has missing text after the comma, or the comma should be a point > > * HttpRequest: "client initiated" > should be "client-initiated" > > * HttpRequest: "The response body can then be received (either > synchronous or asynchronously)" > should be "The response body can then be received (either > synchronously or asynchronously)." > > * HttpRequest: "Path body = r2.body(asFile("/tmp/response.txt));" > should be "Path body = r2.body(asFile("/tmp/response.txt"));" > > * HttpRequest: "All of above examples" > should be "All of the above examples" > > * HttpRequest: "CompletableFuture; last =" > should be "CompletableFuture last =" > > * HttpRequest: "Returns the HttpClient.requestHttp2() setting for this > request." > should note that this setting may have been overridden using > HttpRequest.Builder.requestHttp2(), and therefore is not always equal > to HttpClient.requestHttp2() > > * HttpRequest.Builder: "A builder of HttpRequests" > should be "A builder of HttpRequests." (if you look at the package > overview, all classes except this one have a point at the end) > > * HttpResponseBodyProcessor: "return null and the body" > has missing text after body > > * MultiResponseProcessor: "provides the" > should be "Provides the" > > * WebSocketMessage: "A WebSocketMessages (Binary or Text)" > should be "A WebSocketMessage (Binary or Text)" > > > On 9/03/2015 17:27, Michael McMahon wrote: >> Hi, >> >> JEP 110 HTTP 2 client >> >> in JDK 9, is defining and implementing a new API for HTTP which also >> supports >> the new HTTP version 2 that has recently been working its way through >> the IETF. >> The work also includes support for websockets (RFC 6455). >> >> In fact, the majority of the API is agnostic about the HTTP protocol >> version, with only minor >> configuration settings, and support for multiple responses (Http >> server push) having any direct impact. >> >> The HTTP API is defined around three main types (HttpClient, which is >> the central >> point for configuration of SSL, executor service cookie management >> etc), HttpRequest >> and HttpResponse (which should be self explanatory). >> >> Requests are sent/received either synchronously (blocking) or in a >> non-blocking (asynchronous) >> mode using java.util.future.CompletableFuture which is a powerful new >> framework for >> asynchronous execution introduced in JDK 8. >> >> The API docs can be seen at the link below: >> >> http://cr.openjdk.java.net/~michaelm/httpclient/01/ >> >> All new classes and interfaces belong to the java.net package. >> >> A prototype implementation of this API supporting HTTP/1.1 only, is >> available and will >> be uploaded into the JDK 9 sandbox forest in the coming day or two. >> >> Comments welcome! >> >> Thanks, >> Michael. >> > From anthony.vanelverdinghe at gmail.com Sun Mar 29 19:13:29 2015 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Sun, 29 Mar 2015 21:13:29 +0200 Subject: HTTP 2 client API In-Reply-To: <5512F150.70901@oracle.com> References: <54FDC9F5.7010705@oracle.com> <550D4B9E.3040903@gmail.com> <5512F150.70901@oracle.com> Message-ID: <55184ED9.10709@gmail.com> Hi Michael Further feedback is in-line (please note that, to improve readability, I took the liberty to discard points without further feedback). On 25/03/2015 18:33, Michael McMahon wrote: >> * how is compression (the >> Accept-Encoding/Content-Encoding/Transfer-Encoding headers) handled? >> Is this handled transparently by the HttpClient? For example, if I >> request a text document, will the client automatically send a header >> "Accept-Encoding: gzip, deflate" (this is the current default in >> Firefox)? And once I receive the response, transparently decompress >> it, so I can just do "response.body(asString())"? > It wouldn't be transparent as such. But, it should be possible to > implement it using HttpRequestBodyProcessor and > HttpResponseBodyProcessor, but I wasn't > planning to do it as part of this work initially. Someone could define > a class like: [...] After reading up on the different headers, I agree that Accept-Encoding/Content-Encoding must not be handled by the API. However, I believe that the TE/Transfer-Encoding headers should be fully supported, by adding a "compression(boolean enable)" method to HttpClient.Builder and HttpRequest.Builder. This method would allow transparent compression by supporting at least one of the standardized algorithms (preferably gzip) [ http://www.iana.org/assignments/http-parameters/http-parameters.xhtml#transfer-coding ]. Basically, I believe that the API should offer full support for the "low-level" RFC 7230 (Message Syntax and Routing), in which the "Transfer Codings" section specifies these headers. And since TE/Transfer-Encoding is the correct way for transparent on-the-fly compression, it seems logical to include support for it in the API (to me, it's on the same level as pipelining support, which is included in the API already). >> * HttpHeaders: for the proposed first*() methods, please also >> consider the signature: Optional firstValueAsT(String name). This >> way, the application developer can decide whether to use a default >> value or to throw an exception (or anything else) when the header is >> absent. > How would that be implemented without knowing the type ? Sorry for the confusion, this wasn't meant to represent a generic method. I just meant to say: please consider returning an Optional instead of the current behavior of returning null or taking a "default value" parameter. So instead of the current methods: String firstValue(String name) long firstValueAsLong(String name, long defaultValue) consider these methods instead: Optional firstValue(String name) OptionalLong firstValueAsLong(String name) The advantage of the latter methods would be that you can say for example: headers.firstValue("Content-Type").orElse("application/octet-stream") headers.firstValueAsLong("Content-Length").orElseThrow(() -> new IllegalStateException()) >> * HttpRequest::fromString and HttpResponse::asString should take a >> java.nio.charset.Charset as parameter > instead of the String name of the Charset? Will consider. I'd just like to point out that my main motivation for this is java.nio.charset.StandardCharsets. So for charsets such as UTF-8, UTF-16 and US-ASCII, one can use a static import & simply write e.g. asString(UTF_8). Of course, if it's estimated that most of the uses of this method will use a non-standard charset, then it may be undesirable having to write asString(Charset.forName("Windows-1252")) instead. On a sidenote, the method asString(String charset) in HttpResponse should specify to throw an UnsupportedCharsetException. And in the method fromString(String s, String charset) in HttpRequest, the parameter "s" should be renamed to "body". >> * HttpResponse: in my opinion, "asFile" should take a Path as >> parameter & the parameter name should be "file", instead of "filename" > same as above An advantage of taking a Path, would be that you don't have to embed (OS-specific) file separators to construct the desired argument: asFile(downloadDirectory.resolve(Paths.get("documents", "foo.pdf")); >> * please consider adding a HttpResponseBodyProcessor implementation >> "asDefined()", which uses the same mechanism as >> java.net.URLConnection::getContent (i.e. using the Content-Type >> header & ContentHandlers) to determine the object to return. This >> would allow for easy migration from the old API to the new API. (the >> "defined" in the method name refers to the fact that the value of the >> Content-Type header is used) > How would you determine the type of object to return? I believe that > was one limitation of that API in URLConnection This would be a HttpResponseBodyProcessor, and the type of object would just be whatever type the chosen ContentHandler returns (where the ContentHandler is chosen according to the algorithm specfied in java.net.ContentHandler). After giving this some more thought, I think the proposed HttpResponseBodyProcessor isn't what I'm after. Actually, what I like about the old API, is that I can write ContentHandlers, specify the java.content.handler.pkgs property, and then, for example, automatically have urlConnection.getContent() return an instance of org.w3c.dom.Document for text/html documents. To bring this idea to the new API, I would like to propose something like the following for consideration: * use the java.util.ServiceLoader mechanism to find HttpResponseBodyProcessor implementations * in HttpResponseBodyProcessor, add the methods: boolean canProcess(HttpHeaders headers) Class getBodyClass() * in HttpResponse, add the following method: T body(Class bodyClass) { Iterator processors = serviceLoader.iterator(); Predicate filter = p -> p.canProcess(headers) && bodyClass.isAssignableFrom(p.getBodyClass()); // convert the Iterator to a Stream HttpResponseBodyProcessor p = processorsStream.filter(filter).findFirst().orElseThrow(() -> new UnsupportedOperationException()); return body(p); } So then I'd create a .jar with all my HttpResponseBodyProcessor implementations, and simply write: HttpResponse response = client.request(new URI("http://www.foo.com/index.html")).get().send(); Document homePage = response.body(Document.class); > Many thanks for your comprehensive review! You're welcome, Anthony > Michael > > >> === documentation === >> * as I'm sure you are aware, the package Javadoc should be updated to >> document the new API. I also think it would be good to clarify its >> relation to the old API, JAX-RS and Java API for WebSocket (the >> latter 2 of which will, I assume, in future versions use this API as >> the basis for their Client API implementations). >> >> * HttpClient: "Request builders are then created by calling >> request(URI) if associated with an application created client." >> rephrase as "Request builders that are associated with an >> application-created client, are created by calling request(URI)." >> >> * HttpClient.Builder: "If set, the first request to an origin server >> using "http" URLs will attempt to upgrade to HTTP version 2. If that >> fails, then following requests will not attempt to upgrade again." >> ** make "origin server" a hyperlink to >> https://tools.ietf.org/html/rfc6454#section-4 >> ** explicitly state "following requests to the same origin server" >> >> * HttpRequest: "A request's uri, headers and body can be set." >> change "uri" to "URI" & link it to java.net.URI >> >> * HttpRequest: currently, all examples specify ".body(noBody())". >> This gives the impression it's actually required. I propose to remove >> this from all examples of GET requests (especially the one in the >> "Two simple, example HTTP interactions" at the top). >> >> * HttpRequest::fromString and HttpResponse::asString: replace >> "ISO8859_1" with ISO-8859-1 and link to >> java.nio.charset.StandardCharsets.ISO_8859_1 >> >> * HttpResponse: "such as String, byte arrays, Files." >> change "Files" to "files", since "Files" suggests that it returns >> java.io.File, when instead it's java.nio.file.Path >> >> * HttpResponseBodyProcessor: "write responses to String, byte[], >> File, Consumer" >> change "File" to "file", since "File" suggests that it returns >> java.io.File, when instead it's java.nio.file.Path >> >> * HttpResponseBodyProcessor: "If an exact content length was provided >> in onRequestStart(), then that number of bytes must be provided." >> explicitly add "before returning null" at the end, so: "If an exact >> content length was provided in onRequestStart(), then that number of >> bytes must be provided before returning null." >> >> * WebSocket: add a note that using a WebSocket in a >> try-with-resources statement will cause the close to be done by >> closing the underlying TCP connection & what the possible >> implications are. >> >> === spelling === >> * HttpHeaders: "read only" >> should be "read-only" >> >> * HttpRequest: "any type as body," >> either has missing text after the comma, or the comma should be a point >> >> * HttpRequest: "client initiated" >> should be "client-initiated" >> >> * HttpRequest: "The response body can then be received (either >> synchronous or asynchronously)" >> should be "The response body can then be received (either >> synchronously or asynchronously)." >> >> * HttpRequest: "Path body = r2.body(asFile("/tmp/response.txt));" >> should be "Path body = r2.body(asFile("/tmp/response.txt"));" >> >> * HttpRequest: "All of above examples" >> should be "All of the above examples" >> >> * HttpRequest: "CompletableFuture; last =" >> should be "CompletableFuture last =" >> >> * HttpRequest: "Returns the HttpClient.requestHttp2() setting for >> this request." >> should note that this setting may have been overridden using >> HttpRequest.Builder.requestHttp2(), and therefore is not always equal >> to HttpClient.requestHttp2() >> >> * HttpRequest.Builder: "A builder of HttpRequests" >> should be "A builder of HttpRequests." (if you look at the package >> overview, all classes except this one have a point at the end) >> >> * HttpResponseBodyProcessor: "return null and the body" >> has missing text after body >> >> * MultiResponseProcessor: "provides the" >> should be "Provides the" >> >> * WebSocketMessage: "A WebSocketMessages (Binary or Text)" >> should be "A WebSocketMessage (Binary or Text)" >> >> >> On 9/03/2015 17:27, Michael McMahon wrote: >>> Hi, >>> >>> JEP 110 HTTP 2 client >>> >>> in JDK 9, is defining and implementing a new API for HTTP which also >>> supports >>> the new HTTP version 2 that has recently been working its way >>> through the IETF. >>> The work also includes support for websockets (RFC 6455). >>> >>> In fact, the majority of the API is agnostic about the HTTP protocol >>> version, with only minor >>> configuration settings, and support for multiple responses (Http >>> server push) having any direct impact. >>> >>> The HTTP API is defined around three main types (HttpClient, which >>> is the central >>> point for configuration of SSL, executor service cookie management >>> etc), HttpRequest >>> and HttpResponse (which should be self explanatory). >>> >>> Requests are sent/received either synchronously (blocking) or in a >>> non-blocking (asynchronous) >>> mode using java.util.future.CompletableFuture which is a powerful >>> new framework for >>> asynchronous execution introduced in JDK 8. >>> >>> The API docs can be seen at the link below: >>> >>> http://cr.openjdk.java.net/~michaelm/httpclient/01/ >>> >>> All new classes and interfaces belong to the java.net package. >>> >>> A prototype implementation of this API supporting HTTP/1.1 only, is >>> available and will >>> be uploaded into the JDK 9 sandbox forest in the coming day or two. >>> >>> Comments welcome! >>> >>> Thanks, >>> Michael. >>> >> > >