From xuelei.fan at oracle.com Fri Mar 1 02:35:40 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 01 Mar 2013 10:35:40 +0000 Subject: hg: jdk8/tl/jdk: 7030966: Support AEAD CipherSuites Message-ID: <20130301103619.27EE547512@hg.openjdk.java.net> Changeset: def2e05299b7 Author: xuelei Date: 2013-03-01 02:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/def2e05299b7 7030966: Support AEAD CipherSuites Reviewed-by: weijun, wetmore, valeriep ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java + src/share/classes/sun/security/ssl/Authenticator.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/sslecc/CipherTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java ! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java ! test/sun/security/ssl/sanity/interop/CipherTest.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java From chris.hegarty at oracle.com Fri Mar 1 07:33:40 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 01 Mar 2013 15:33:40 +0000 Subject: RFR: 8009251 - Add proxy handling and keep-alive fixes to jsse In-Reply-To: <512FF349.1040804@oracle.com> References: <512FF349.1040804@oracle.com> Message-ID: <5130CA54.1000108@oracle.com> On 03/01/2013 12:16 AM, Rob McKenna wrote: > Hi folks, > > I'd like to port some changes around proxy handling, keep alive and > tunnelling to the HttpsClient. These should have been done along with > the HttpClient. Webrev is at: > > http://cr.openjdk.java.net/~robm/8009251/webrev.01/ Looks fine to me Rob. Thanks for catching these issues with the HTTPS handler. > related issues: For the record, links to the related bugs: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7199219 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7199862 -Chris. From jonathan.gibbons at oracle.com Fri Mar 1 11:35:15 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Mar 2013 19:35:15 +0000 Subject: hg: jdk8/tl/langtools: 8008949: javadoc stopped copying doc-files Message-ID: <20130301193521.0B3404752A@hg.openjdk.java.net> Changeset: 6f988040a1c8 Author: jjg Date: 2013-03-01 10:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6f988040a1c8 8008949: javadoc stopped copying doc-files Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + test/com/sun/javadoc/testDocFiles/TestDocFiles.java + test/com/sun/javadoc/testDocFiles/pkg/Test.java + test/com/sun/javadoc/testDocFiles/pkg/doc-files/test.txt From sean.mullan at oracle.com Fri Mar 1 13:26:11 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 01 Mar 2013 21:26:11 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130301212643.176DB477C3@hg.openjdk.java.net> Changeset: 1652ac7b4bfd Author: mullan Date: 2013-03-01 16:12 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1652ac7b4bfd 8008908: Access denied when invoking Subject.doAsPrivileged() Summary: wildcard principal names are not processed correctly Reviewed-by: xuelei ! src/share/classes/sun/security/provider/PolicyFile.java + test/sun/security/provider/PolicyFile/WildcardPrincipalName.java + test/sun/security/provider/PolicyFile/wildcard.policy Changeset: 1ca712765acb Author: mullan Date: 2013-03-01 16:15 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ca712765acb Merge From dan.xu at oracle.com Fri Mar 1 14:30:57 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Fri, 01 Mar 2013 22:30:57 +0000 Subject: hg: jdk8/tl/jdk: 8006645: TEST_BUG: java/nio/file/Files/CopyAndMove.java failing intermittently (sol) Message-ID: <20130301223119.D494B477C9@hg.openjdk.java.net> Changeset: 30e30ef6077e Author: dxu Date: 2013-03-01 14:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30e30ef6077e 8006645: TEST_BUG: java/nio/file/Files/CopyAndMove.java failing intermittently (sol) Summary: Fix test failures and update java doc of Files.move Reviewed-by: alanb, chegar ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/CopyAndMove.java From chris.hegarty at oracle.com Sat Mar 2 00:37:30 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 02 Mar 2013 08:37:30 +0000 Subject: OpenJDK HTTP Client Bug In-Reply-To: <5131B5D2.7090601@redhat.com> References: <5131B5D2.7090601@redhat.com> Message-ID: <5131BA4A.1020703@oracle.com> [bcc'ing off jdk7-dev at openjdk.java.net, and including net-dev at openjdk.java.net] Hi Stuart, Thanks for reporting this issue. It does indeed look like a regression/side-effect of that recent change. There is no sign of your attached patch, maybe it got stripped by mailman. You can probably just post it inline. Thanks, -Chris. On 03/02/2013 08:18 AM, Stuart Douglas wrote: > Hello everyone, > > (This is my first post to this list, so I am not 100% sure if this is > the right place). > > I have run into a bug in the JDK HttpClient that was caused by a recent > commit: > > http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/diff/e6dc1d9bc70b/src/share/classes/sun/net/www/http/HttpClient.java > > > The method sun.net.www.http.HttpClient#available() can throw > java.net.SocketException, which can cause the creation of the HttpClient > to fail. This will happen if there is a connection in the cache that has > timed out and the socket has been closed. > > I have attached a small patch that should resolve the problem, although > due to its intermittent nature I have not been able to verify with 100% > certainty. > > > The exception is: > > Caused by: java.net.SocketException: Socket Closed > at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:286) > at java.net.Socket.getSoTimeout(Socket.java:1032) > at sun.net.www.http.HttpClient.available(HttpClient.java:356) > at sun.net.www.http.HttpClient.New(HttpClient.java:273) > at sun.net.www.http.HttpClient.New(HttpClient.java:310) > at > sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:987) > > at > sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:923) > > at > sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841) > > at > sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1031) > > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1410) > > > > This issue also seems to affect JDK 6, and it appears that other people > have also run into this: > http://stackoverflow.com/questions/14270311/rather-mysterious-socketexception-with-java-1-6-on-centos-4 > > > I attempted to file a bug for this on the Oracle website, however as far > as I can tell it was ignored. > > Stuart > From chris.hegarty at oracle.com Sat Mar 2 00:56:36 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 02 Mar 2013 08:56:36 +0000 Subject: hg: jdk8/tl/jdk: 8008378: FJP.commonPool support parallelism 0, add awaitQuiescence Message-ID: <20130302085658.C3B57477DA@hg.openjdk.java.net> Changeset: f08ad5938709 Author: chegar Date: 2013-03-02 08:54 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f08ad5938709 8008378: FJP.commonPool support parallelism 0, add awaitQuiescence Reviewed-by: chegar Contributed-by: Doug Lea
tags as empty Message-ID: <20130320021726.56BFA4827E@hg.openjdk.java.net> Changeset: 74d7f9bcac93 Author: jjg Date: 2013-03-19 19:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/74d7f9bcac93 8010317: DocLint incorrectly reports sometags as empty Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/EmptyPreTest.java From chris.hegarty at oracle.com Wed Mar 20 09:00:34 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 20 Mar 2013 16:00:34 +0000 Subject: hg: jdk8/tl/jdk: 8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe Message-ID: <20130320160054.9B3564829D@hg.openjdk.java.net> Changeset: 3070b7363853 Author: chegar Date: 2013-03-20 14:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3070b7363853 8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe Reviewed-by: khazra, alanb ! src/share/classes/sun/net/www/protocol/jar/JarURLConnection.java ! src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java From sean.mullan at oracle.com Wed Mar 20 09:07:12 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 20 Mar 2013 16:07:12 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130320160747.CAF5F4829F@hg.openjdk.java.net> Changeset: 38116bfe5323 Author: mullan Date: 2013-03-20 10:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38116bfe5323 8010112: NullPointerException in sun.security.provider.certpath.CertId() Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/CertId.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/x509/X509CertImpl.java Changeset: 9859856920ed Author: mullan Date: 2013-03-20 11:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9859856920ed Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 38c1d0c2d6a6 Author: mullan Date: 2013-03-20 12:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38c1d0c2d6a6 Merge From mandy.chung at oracle.com Wed Mar 20 09:51:42 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 20 Mar 2013 16:51:42 +0000 Subject: hg: jdk8/tl/jdk: 8006104: Improve tests to test ".useParentHandlers" property set in the logging configuration Message-ID: <20130320165154.8D490482A5@hg.openjdk.java.net> Changeset: ccd9f53377c4 Author: mchung Date: 2013-03-20 09:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ccd9f53377c4 8006104: Improve tests to test ".useParentHandlers" property set in the logging configuration Reviewed-by: alanb ! test/java/util/logging/CustomLogManager.java ! test/java/util/logging/CustomLogManagerTest.java From joe.darcy at oracle.com Wed Mar 20 15:21:33 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 20 Mar 2013 22:21:33 +0000 Subject: hg: jdk8/tl/jdk: 8010427: Refine Method.isDefault implementation Message-ID: <20130320222204.58614482BF@hg.openjdk.java.net> Changeset: cf0049037deb Author: darcy Date: 2013-03-20 15:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf0049037deb 8010427: Refine Method.isDefault implementation Reviewed-by: acorn, dlsmith ! src/share/classes/java/lang/reflect/Method.java From joe.darcy at oracle.com Wed Mar 20 17:41:53 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 21 Mar 2013 00:41:53 +0000 Subject: hg: jdk8/tl/langtools: 8010364: Clarify javax.lang.model API for Type Annotations Message-ID: <20130321004156.BF54C482CC@hg.openjdk.java.net> Changeset: 972474640b7d Author: darcy Date: 2013-03-20 17:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/972474640b7d 8010364: Clarify javax.lang.model API for Type Annotations Reviewed-by: jjg, abuckley ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/type/ExecutableType.java From david.holmes at oracle.com Wed Mar 20 19:40:14 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 21 Mar 2013 02:40:14 +0000 Subject: hg: jdk8/tl/jdk: 8006818: SunEC and SunPKCS11 providers should be in all profiles Message-ID: <20130321024037.46C27482D2@hg.openjdk.java.net> Changeset: 3c1a4966d901 Author: dholmes Date: 2013-03-20 22:39 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c1a4966d901 8006818: SunEC and SunPKCS11 providers should be in all profiles Reviewed-by: dholmes, alanb, valeriep Contributed-by: Jen Dority! makefiles/profile-includes.txt From rob.mckenna at oracle.com Thu Mar 21 10:32:52 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Thu, 21 Mar 2013 17:32:52 +0000 Subject: hg: jdk8/tl/jdk: 8009251: Add proxy handling and keep-alive fixes to jsse Message-ID: <20130321173305.A6311482F0@hg.openjdk.java.net> Changeset: 3f8fbb0ab155 Author: robm Date: 2013-03-21 17:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f8fbb0ab155 8009251: Add proxy handling and keep-alive fixes to jsse Reviewed-by: chegar ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java From weijun.wang at oracle.com Fri Mar 22 05:05:58 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 22 Mar 2013 12:05:58 +0000 Subject: hg: jdk8/tl/jdk: 8010531: Add BadKdc* tests to problem list for solaris-sparcv9 Message-ID: <20130322120610.2CBEA48337@hg.openjdk.java.net> Changeset: 93cd7052d306 Author: weijun Date: 2013-03-22 19:59 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93cd7052d306 8010531: Add BadKdc* tests to problem list for solaris-sparcv9 Reviewed-by: alanb ! test/ProblemList.txt From maurizio.cimadamore at oracle.com Fri Mar 22 05:45:45 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 22 Mar 2013 12:45:45 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20130322124559.BDE3D48338@hg.openjdk.java.net> Changeset: cc38a6723663 Author: mcimadamore Date: 2013-03-22 12:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cc38a6723663 8009649: Lambda back-end should generate invokespecial for method handles referring to private instance methods Summary: Private lambda methods should be accessed through invokespecial Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/bytecode/TestLambdaBytecode.java Changeset: f3814edefb33 Author: mcimadamore Date: 2013-03-22 12:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f3814edefb33 8010101: Intersection type cast issues redundant unchecked warning Summary: Code for checking intersection type cast is incorrectly swapping operands, leading to spurious warnings Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/Intersection02.java + test/tools/javac/lambda/Intersection02.out Changeset: b6cf07c54c29 Author: mcimadamore Date: 2013-03-22 12:41 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b6cf07c54c29 8009820: AssertionError when compiling java code with two identical static imports Summary: Speculative attribution is carried out twice with same method symbol in case of static imports Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/lambda/DoubleStaticImport.java Changeset: c6728c9addff Author: mcimadamore Date: 2013-03-22 12:43 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c6728c9addff 8010303: Graph inference: missing incorporation step causes spurious inference error Summary: Multiple equality constraints on inference vars are not used to generate new inference constraints Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/lambda/TargetType28.out + test/tools/javac/lambda/TargetType67.java + test/tools/javac/lambda/TargetType68.java + test/tools/javac/lambda/TargetType69.java Changeset: 5da12e8a59ba Author: mcimadamore Date: 2013-03-22 12:44 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5da12e8a59ba 8010387: Javac crashes when diagnostic mentions anonymous inner class' type variables Summary: Rich formatter doesn't preprocess supertypes of an anonymous inner class Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/Diagnostics/8010387/T8010387.java + test/tools/javac/Diagnostics/8010387/T8010387.out From joe.darcy at oracle.com Fri Mar 22 10:09:00 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 22 Mar 2013 17:09:00 +0000 Subject: hg: jdk8/tl/langtools: 7080464: langtools regression test failures when assertions are enabled Message-ID: <20130322170906.1F92948345@hg.openjdk.java.net> Changeset: f4500abff1fd Author: darcy Date: 2013-03-22 10:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f4500abff1fd 7080464: langtools regression test failures when assertions are enabled Reviewed-by: jjg ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/diags/MessageFile.java ! test/tools/javac/diags/MessageInfo.java From weijun.wang at oracle.com Fri Mar 22 20:50:00 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Sat, 23 Mar 2013 03:50:00 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130323035033.632B54836B@hg.openjdk.java.net> Changeset: 3470101fae58 Author: weijun Date: 2013-03-23 11:49 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3470101fae58 8009970: Several LoginModule classes need extra permission to load AuthResources Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java Changeset: ed63cace1d30 Author: weijun Date: 2013-03-23 11:49 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ed63cace1d30 8009875: Provide a default udp_preference_limit for krb5.conf Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/internal/Krb5.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/config/DefUdpLimit.java From chris.hegarty at oracle.com Mon Mar 25 07:30:18 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 25 Mar 2013 14:30:18 +0000 Subject: hg: jdk8/tl/jdk: 8010668: builtin JNI libraries should not be unloaded Message-ID: <20130325143042.9F4E2483AB@hg.openjdk.java.net> Changeset: 5d0c891264bf Author: chegar Date: 2013-03-25 14:29 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d0c891264bf 8010668: builtin JNI libraries should not be unloaded Reviewed-by: chegar, alanb Contributed-by: Bill Pittore ! src/share/native/java/lang/ClassLoader.c From mandy.chung at oracle.com Mon Mar 25 17:22:00 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 26 Mar 2013 00:22:00 +0000 Subject: hg: jdk8/tl/jdk: 8007703: Remove com.sun.servicetag API Message-ID: <20130326002227.A2616483BD@hg.openjdk.java.net> Changeset: 5e383a73386a Author: mchung Date: 2013-03-25 17:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e383a73386a 8007703: Remove com.sun.servicetag API Reviewed-by: dholmes, alanb, erikj ! make/com/sun/Makefile ! make/common/Release.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcProperties.gmk ! makefiles/profile-includes.txt ! makefiles/profile-rtjar-includes.txt ! test/Makefile From mandy.chung at oracle.com Mon Mar 25 18:17:13 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 26 Mar 2013 01:17:13 +0000 Subject: hg: jdk8/tl/jdk: 8010787: changeset for 8007703 is missing the deleted files Message-ID: <20130326011748.B254C483C1@hg.openjdk.java.net> Changeset: 335d2156222e Author: mchung Date: 2013-03-25 18:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/335d2156222e 8010787: changeset for 8007703 is missing the deleted files Reviewed-by: dholmes, alanb, erikj - make/com/sun/servicetag/Makefile - src/share/classes/com/sun/servicetag/BrowserSupport.java - src/share/classes/com/sun/servicetag/Installer.java - src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java - src/share/classes/com/sun/servicetag/RegistrationData.java - src/share/classes/com/sun/servicetag/RegistrationDocument.java - src/share/classes/com/sun/servicetag/Registry.java - src/share/classes/com/sun/servicetag/ServiceTag.java - src/share/classes/com/sun/servicetag/SolarisServiceTag.java - src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java - src/share/classes/com/sun/servicetag/SunConnection.java - src/share/classes/com/sun/servicetag/SystemEnvironment.java - src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java - src/share/classes/com/sun/servicetag/Util.java - src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java - src/share/classes/com/sun/servicetag/package.html - src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt - src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties - src/share/classes/com/sun/servicetag/resources/jdk_header.png - src/share/classes/com/sun/servicetag/resources/product_registration.xsd - src/share/classes/com/sun/servicetag/resources/register.html - src/share/classes/com/sun/servicetag/resources/register_ja.html - src/share/classes/com/sun/servicetag/resources/register_zh_CN.html - test/com/sun/servicetag/DeleteServiceTag.java - test/com/sun/servicetag/DuplicateNotFound.java - test/com/sun/servicetag/FindServiceTags.java - test/com/sun/servicetag/InstanceUrnCheck.java - test/com/sun/servicetag/InvalidRegistrationData.java - test/com/sun/servicetag/InvalidServiceTag.java - test/com/sun/servicetag/JavaServiceTagTest.java - test/com/sun/servicetag/JavaServiceTagTest1.java - test/com/sun/servicetag/NewRegistrationData.java - test/com/sun/servicetag/SvcTagClient.java - test/com/sun/servicetag/SystemRegistryTest.java - test/com/sun/servicetag/TestLoadFromXML.java - test/com/sun/servicetag/UpdateServiceTagTest.java - test/com/sun/servicetag/Util.java - test/com/sun/servicetag/ValidRegistrationData.java - test/com/sun/servicetag/environ.properties - test/com/sun/servicetag/missing-environ-field.xml - test/com/sun/servicetag/newer-registry-version.xml - test/com/sun/servicetag/registration.xml - test/com/sun/servicetag/servicetag1.properties - test/com/sun/servicetag/servicetag2.properties - test/com/sun/servicetag/servicetag3.properties - test/com/sun/servicetag/servicetag4.properties - test/com/sun/servicetag/servicetag5.properties From mark.sheppard at oracle.com Tue Mar 26 09:40:31 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 26 Mar 2013 16:40:31 +0000 Subject: RFR: JDK-8007373 Inet6Address serialization incompatibility Message-ID: <5151CF7F.4080508@oracle.com> Hi, could you oblige and review the webrev below as a fix for the issue raised in JDK8007373, Inet6Address serialization incompatibility http://cr.openjdk.java.net/~msheppar/8007373/webrev.00/ Description: We seem to have changed the serialization of Inet6Address in jdk8 compared with jdk7. It is causing a problem de-serializing instances (in 7) that were serialized by 8. The scope-id is not being recreated correctly. this is related to JDK-8004675 The fix has re-instated the scope_ifname_set variable, and sets this explicitly during serialization (writeObject). It also sets the scope id to 0 when the scope_ifname is determined to be null during deserialization (readObject). The refactoring undertaken in 8004675 has been left in place. It will be noted that an additional issue has been raised, JDK-8010826, arising from testing during this fix. the scope id can be incorrect after serialization where a scoped interface in the serialized object does not exist on the deserializing host. regards Mark From martinrb at google.com Tue Mar 26 13:41:30 2013 From: martinrb at google.com (martinrb at google.com) Date: Tue, 26 Mar 2013 20:41:30 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130326204203.53C25483EF@hg.openjdk.java.net> Changeset: 3b56ef8e1ce1 Author: martin Date: 2013-03-26 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b56ef8e1ce1 8007905: To add a system property to create zip file without using ZIP64 end table when entry count > 64k Summary: Provide a system property to inhibit ZIP64 mode for >64k entries Reviewed-by: alanb, sherman ! src/share/classes/java/util/zip/ZipOutputStream.java + test/java/util/zip/EntryCount64k.java Changeset: 266b43683a2c Author: martin Date: 2013-03-26 13:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/266b43683a2c 8010316: Improve handling of char sequences containing surrogates Summary: Fix and optimize codePointAt, codePointBefore and similar methods Reviewed-by: sherman, okutsu, ulfzibis, kizune ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/Character.java ! test/java/lang/StringBuilder/Supplementary.java From joe.darcy at oracle.com Tue Mar 26 17:17:33 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 27 Mar 2013 00:17:33 +0000 Subject: hg: jdk8/tl/langtools: 7041251: Use j.u.Objects utility methods in langtools Message-ID: <20130327001738.A090C48400@hg.openjdk.java.net> Changeset: 330b35b27e68 Author: darcy Date: 2013-03-26 17:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/330b35b27e68 7041251: Use j.u.Objects utility methods in langtools Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/Pair.java ! src/share/classes/javax/annotation/processing/AbstractProcessor.java From mhall at mhcomputing.net Tue Mar 26 17:33:15 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Tue, 26 Mar 2013 17:33:15 -0700 Subject: Problem with fix B6369510 for HttpURLConnection Content-Type Message-ID: <20130327003315.GA5791@mhcomputing.net> Hello, I was working on a situation which was similar to the situation described in this bug which was supposedly fixed in Java 5 and Java 6: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369510 The bug described how Content-Type was being auto-set to application/x-www-form-urlencoded in cases where it should not be. I was seeing this problem, where the open-source JSCEP library was creating a request to a Tomcat servlet I am implementing, which Tomcat was rejecting due to encoding issues in the POST body. When I looked at the traffic using Wireshark TCP Stream reassembly I discovered that the request had the URL-encoded content type even though no code in JSCEP requested this. Upon reading through the unit test, openjdk-7/jdk/test/sun/net/www/protocol/http/B6369510.java, I found a couple of issues: 1) The test fails if you have an IPv6 address configured on the system, because the code doesn't enclose the IPv6 literal with '[]': URL url = new URL("http://" + address.getHostName() + ":" + address.getPort() + "/test/"); java.net.MalformedURLException: For input string: "0:0:0:0:0:0:0:40392" at java.net.URL. (URL.java:601) at java.net.URL. (URL.java:464) at java.net.URL. (URL.java:413) at B6369510.doClient(B6369510.java:63) at B6369510. (B6369510.java:52) at B6369510.main(B6369510.java:45) 2) There appears to be a logic error in the test, or the fix and the bug description do not match: if (requestMethod.equalsIgnoreCase("GET") && ct != null && ct.get(0).equals("application/x-www-form-urlencoded")) t.sendResponseHeaders(400, -1); else if (requestMethod.equalsIgnoreCase("POST") && ct != null && !ct.get(0).equals("application/x-www-form-urlencoded")) t.sendResponseHeaders(400, -1); This code is saying, the unit test will fail if the method is GET, and the content-type is equal to url-encoded, and the unit test will fail if the method is POST, and the content-type is *NOT* equal to url-encoded. But, in the evaluation, the bug states, "Content-Type is being set to application/x-www-form-urlencoded for all HttpURLConnections requests other than PUT requests. This is not necessary and could even cause problems for some servers. We do not need to set this content-type for GET requests." To me this means, the code should not be setting the Content-Type to anything, on any type of request, because it will cause problems across the board. So I think that the test and the bug fix do not actually fix the original bug correctly, and the test needs to be fixed so it will work right on an IPv6 based system. Thoughts? Matthew Hall. From mhall at mhcomputing.net Tue Mar 26 17:42:43 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Tue, 26 Mar 2013 17:42:43 -0700 Subject: Problem with fix B6369510 for HttpURLConnection Content-Type In-Reply-To: <20130327003315.GA5791@mhcomputing.net> References: <20130327003315.GA5791@mhcomputing.net> Message-ID: <20130327004243.GA5834@mhcomputing.net> Forgot to include, offending code in HttpURLConnection: if (!method.equals("PUT") && (poster != null || streaming())) requests.setIfNotSet ("Content-type", "application/x-www-form-urlencoded"); Format adjusted a bit for readability. Matthew. On Tue, Mar 26, 2013 at 05:33:15PM -0700, Matthew Hall wrote: > Hello, > > I was working on a situation which was similar to the situation described in > this bug which was supposedly fixed in Java 5 and Java 6: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369510 > > The bug described how Content-Type was being auto-set to > application/x-www-form-urlencoded in cases where it should not be. > > I was seeing this problem, where the open-source JSCEP library was creating a > request to a Tomcat servlet I am implementing, which Tomcat was rejecting due > to encoding issues in the POST body. > > When I looked at the traffic using Wireshark TCP Stream reassembly I > discovered that the request had the URL-encoded content type even though no > code in JSCEP requested this. > > Upon reading through the unit test, > openjdk-7/jdk/test/sun/net/www/protocol/http/B6369510.java, I found a couple > of issues: > > 1) The test fails if you have an IPv6 address configured on the system, > because the code doesn't enclose the IPv6 literal with '[]': > > URL url = new URL("http://" + address.getHostName() + ":" + address.getPort() + "/test/"); > > java.net.MalformedURLException: For input string: "0:0:0:0:0:0:0:40392" > at java.net.URL. (URL.java:601) > at java.net.URL. (URL.java:464) > at java.net.URL. (URL.java:413) > at B6369510.doClient(B6369510.java:63) > at B6369510. (B6369510.java:52) > at B6369510.main(B6369510.java:45) > > 2) There appears to be a logic error in the test, or the fix and the bug > description do not match: > > if (requestMethod.equalsIgnoreCase("GET") && ct != null && > ct.get(0).equals("application/x-www-form-urlencoded")) > t.sendResponseHeaders(400, -1); > > else if (requestMethod.equalsIgnoreCase("POST") && ct != null && > !ct.get(0).equals("application/x-www-form-urlencoded")) > t.sendResponseHeaders(400, -1); > > This code is saying, the unit test will fail if the method is GET, and the > content-type is equal to url-encoded, and the unit test will fail if the > method is POST, and the content-type is *NOT* equal to url-encoded. > > But, in the evaluation, the bug states, "Content-Type is being set to > application/x-www-form-urlencoded for all HttpURLConnections requests other > than PUT requests. This is not necessary and could even cause problems for > some servers. We do not need to set this content-type for GET requests." > > To me this means, the code should not be setting the Content-Type to anything, > on any type of request, because it will cause problems across the board. > > So I think that the test and the bug fix do not actually fix the original bug > correctly, and the test needs to be fixed so it will work right on an IPv6 > based system. > > Thoughts? > Matthew Hall. From joe.darcy at oracle.com Tue Mar 26 18:15:34 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 27 Mar 2013 01:15:34 +0000 Subject: hg: jdk8/tl/langtools: 7059170: Assume availablility of URLClassLoader.close Message-ID: <20130327011539.80B7848402@hg.openjdk.java.net> Changeset: 33b6a52f0037 Author: darcy Date: 2013-03-26 18:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/33b6a52f0037 7059170: Assume availablility of URLClassLoader.close Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java - src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java From chris.hegarty at oracle.com Wed Mar 27 08:54:20 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 27 Mar 2013 15:54:20 +0000 Subject: DefaultProxySelector socks override In-Reply-To: <20130327144119.413AC97129@rebar.astron.com> References: <20130327144119.413AC97129@rebar.astron.com> Message-ID: <5153162C.1010401@oracle.com> [cc'ing net-dev, we can then probably drop core-libs-dev and continue the discussion over on net-dev] Christos, SOCKS is really old and not as widely deployed as other proxies. That said, I don't have any specific problem with your proposal. SOCKS is really in maintenance mode in the JDK, but I do see this as a reasonable request/proposal. Since socksNonProxyHosts is only set on Mac I can only presume that it is a remanent of the mac port. I would prefer to make the cosmetic changes as part of this patch. I cannot see that we need to keep socksNonProxyHosts, as it does nothing in the JDK anyway. Can you do this? -Chris. On 03/27/2013 02:41 PM, christos at zoulas.com wrote: > This trivial patch add "socksNonProxyHosts" to the default proxy, > so that we can select which socket traffic will be directed to > the proxy and which not. There is currently no way to do this. In > my scenario, I have applications that would benefit in terms of > performance to connect directly to our internal network hosts, and > at the same time need to connect to the outside via our socks proxy. > Having all of them go through the socks proxy would require me to > buy a very expensive proxy, and suffer the latency anyway. I would > also like to note that the "socksNonProxyHosts" variable is in: > > jdk/src/share/native/java/lang/System.c: PUTPROP(props, "socksNonProxyHosts", sprops->exceptionList); > > for MacOS/X but nowhere else. Finally (not in this patch), it would > be nice to provide socks.nonProxyHosts etc. to be symmetric with the > other http, https, and ftp variables. But this is purely cosmetic. And > here's the patch... > > Enjoy, > > christos > > --- jdk/src/share/classes/sun/net/spi/DefaultProxySelector.java.orig Wed Mar 27 10:26:36 2013 -0400 > +++ jdk/src/share/classes/sun/net/spi/DefaultProxySelector.java Wed Mar 27 10:28:15 2013 -0400 > @@ -124,6 +124,7 @@ > final String defaultVal; > static NonProxyInfo ftpNonProxyInfo = new NonProxyInfo("ftp.nonProxyHosts", null, null, defStringVal); > static NonProxyInfo httpNonProxyInfo = new NonProxyInfo("http.nonProxyHosts", null, null, defStringVal); > + static NonProxyInfo socksNonProxyInfo = new NonProxyInfo("socksNonProxyHosts", null, null, defStringVal); > > NonProxyInfo(String p, String s, RegexpPool pool, String d) { > property = p; > @@ -186,7 +187,9 @@ > pinfo = NonProxyInfo.httpNonProxyInfo; > } else if ("ftp".equalsIgnoreCase(protocol)) { > pinfo = NonProxyInfo.ftpNonProxyInfo; > - } > + } else if ("socket".equalsIgnoreCase(protocol)) { > + pinfo = NonProxyInfo.socksNonProxyInfo; > + } > > /** > * Let's check the System properties for that protocol > From dan.xu at oracle.com Wed Mar 27 09:02:17 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Wed, 27 Mar 2013 16:02:17 +0000 Subject: hg: jdk8/tl/jdk: 8010837: FileInputStream.available() throw IOException when encountering negative available values Message-ID: <20130327160234.87FFE4841B@hg.openjdk.java.net> Changeset: 49602f599c08 Author: dxu Date: 2013-03-27 09:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49602f599c08 8010837: FileInputStream.available() throw IOException when encountering negative available values Summary: Remove the check in the native code to allow negative values Reviewed-by: mchung ! src/solaris/native/java/io/io_util_md.c + test/java/io/FileInputStream/NegativeAvailable.java From joe.darcy at oracle.com Wed Mar 27 09:39:26 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 27 Mar 2013 16:39:26 +0000 Subject: hg: jdk8/tl/jdk: 7185456: (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotations Message-ID: <20130327163947.9634348424@hg.openjdk.java.net> Changeset: ae03282ba501 Author: darcy Date: 2013-03-27 09:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae03282ba501 7185456: (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotations Reviewed-by: mduigou, jfranck ! src/share/classes/sun/reflect/annotation/AnnotationType.java From rob.mckenna at oracle.com Wed Mar 27 10:25:03 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 27 Mar 2013 17:25:03 +0000 Subject: Problem with fix B6369510 for HttpURLConnection Content-Type In-Reply-To: <20130327004243.GA5834@mhcomputing.net> References: <20130327003315.GA5791@mhcomputing.net> <20130327004243.GA5834@mhcomputing.net> Message-ID: <51532B6F.8090005@oracle.com> HI Matthew, On the face of it this makes sense. I don't have time to dig into it this week, but I'll get stuck into it next week and get a fix together. -Rob On 27/03/13 00:42, Matthew Hall wrote: > Forgot to include, offending code in HttpURLConnection: > > if (!method.equals("PUT") && (poster != null || streaming())) > requests.setIfNotSet ("Content-type", "application/x-www-form-urlencoded"); > > Format adjusted a bit for readability. > > Matthew. > > On Tue, Mar 26, 2013 at 05:33:15PM -0700, Matthew Hall wrote: >> Hello, >> >> I was working on a situation which was similar to the situation described in >> this bug which was supposedly fixed in Java 5 and Java 6: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369510 >> >> The bug described how Content-Type was being auto-set to >> application/x-www-form-urlencoded in cases where it should not be. >> >> I was seeing this problem, where the open-source JSCEP library was creating a >> request to a Tomcat servlet I am implementing, which Tomcat was rejecting due >> to encoding issues in the POST body. >> >> When I looked at the traffic using Wireshark TCP Stream reassembly I >> discovered that the request had the URL-encoded content type even though no >> code in JSCEP requested this. >> >> Upon reading through the unit test, >> openjdk-7/jdk/test/sun/net/www/protocol/http/B6369510.java, I found a couple >> of issues: >> >> 1) The test fails if you have an IPv6 address configured on the system, >> because the code doesn't enclose the IPv6 literal with '[]': >> >> URL url = new URL("http://" + address.getHostName() + ":" + address.getPort() + "/test/"); >> >> java.net.MalformedURLException: For input string: "0:0:0:0:0:0:0:40392" >> at java.net.URL. (URL.java:601) >> at java.net.URL. (URL.java:464) >> at java.net.URL. (URL.java:413) >> at B6369510.doClient(B6369510.java:63) >> at B6369510. (B6369510.java:52) >> at B6369510.main(B6369510.java:45) >> >> 2) There appears to be a logic error in the test, or the fix and the bug >> description do not match: >> >> if (requestMethod.equalsIgnoreCase("GET") && ct != null && >> ct.get(0).equals("application/x-www-form-urlencoded")) >> t.sendResponseHeaders(400, -1); >> >> else if (requestMethod.equalsIgnoreCase("POST") && ct != null && >> !ct.get(0).equals("application/x-www-form-urlencoded")) >> t.sendResponseHeaders(400, -1); >> >> This code is saying, the unit test will fail if the method is GET, and the >> content-type is equal to url-encoded, and the unit test will fail if the >> method is POST, and the content-type is *NOT* equal to url-encoded. >> >> But, in the evaluation, the bug states, "Content-Type is being set to >> application/x-www-form-urlencoded for all HttpURLConnections requests other >> than PUT requests. This is not necessary and could even cause problems for >> some servers. We do not need to set this content-type for GET requests." >> >> To me this means, the code should not be setting the Content-Type to anything, >> on any type of request, because it will cause problems across the board. >> >> So I think that the test and the bug fix do not actually fix the original bug >> correctly, and the test needs to be fixed so it will work right on an IPv6 >> based system. >> >> Thoughts? >> Matthew Hall. From chris.hegarty at oracle.com Wed Mar 27 10:30:16 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 27 Mar 2013 17:30:16 +0000 Subject: DefaultProxySelector socks override In-Reply-To: <20130327172205.22C1B97129@rebar.astron.com> References: <20130327172205.22C1B97129@rebar.astron.com> Message-ID: <51532CA8.1020909@oracle.com> On 03/27/2013 05:22 PM, christos at zoulas.com wrote: > .... > Sure, I just requested a subscription to net-dev so I might not see the > first few messages. To clarify: > > 1. I will add socks.proxyHost and socks.proxyPort for consistency > with the other protocols, leaving as is socksProxyHost and > socksProxyPort for compatibility. > 2. I will add socks.nonProxyHosts and not socksNonProxyHosts. > > Is that what you had in mind? Re-checking the code I take back my previous comment. We already have socksProxyHost, socksProxyPort, socksProxyVersion so your original proposal of 'socksNonProxyHosts' is probably best, and consistent with existing properties. -Chris. > > christos > From christos at zoulas.com Wed Mar 27 10:49:10 2013 From: christos at zoulas.com (Christos Zoulas) Date: Wed, 27 Mar 2013 13:49:10 -0400 Subject: DefaultProxySelector socks override In-Reply-To: <51532CA8.1020909@oracle.com> from Chris Hegarty (Mar 27, 5:30pm) Message-ID: <20130327174910.85AA097129@rebar.astron.com> On Mar 27, 5:30pm, chris.hegarty at oracle.com (Chris Hegarty) wrote: -- Subject: Re: DefaultProxySelector socks override | On 03/27/2013 05:22 PM, christos at zoulas.com wrote: | > .... | > Sure, I just requested a subscription to net-dev so I might not see the | > first few messages. To clarify: | > | > 1. I will add socks.proxyHost and socks.proxyPort for consistency | > with the other protocols, leaving as is socksProxyHost and | > socksProxyPort for compatibility. | > 2. I will add socks.nonProxyHosts and not socksNonProxyHosts. | > | > Is that what you had in mind? | | Re-checking the code I take back my previous comment. We already have | | socksProxyHost, socksProxyPort, socksProxyVersion | | so your original proposal of 'socksNonProxyHosts' is probably best, and | consistent with existing properties. I concur. Nothing for me to do :-) Best, christos From mhall at mhcomputing.net Wed Mar 27 11:03:51 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Wed, 27 Mar 2013 11:03:51 -0700 Subject: Problem with fix B6369510 for HttpURLConnection Content-Type In-Reply-To: <51532B6F.8090005@oracle.com> References: <20130327003315.GA5791@mhcomputing.net> <20130327004243.GA5834@mhcomputing.net> <51532B6F.8090005@oracle.com> Message-ID: <20130327180351.GA11391@mhcomputing.net> Thanks! Let me know what your opinion is, after you get a chance to look it over. Matthew. On Wed, Mar 27, 2013 at 05:25:03PM +0000, Rob McKenna wrote: > HI Matthew, > > On the face of it this makes sense. I don't have time to dig into it > this week, but I'll get stuck into it next week and get a fix > together. > > -Rob > > On 27/03/13 00:42, Matthew Hall wrote: > >Forgot to include, offending code in HttpURLConnection: > > > >if (!method.equals("PUT") && (poster != null || streaming())) > > requests.setIfNotSet ("Content-type", "application/x-www-form-urlencoded"); > > > >Format adjusted a bit for readability. > > > >Matthew. > > > >On Tue, Mar 26, 2013 at 05:33:15PM -0700, Matthew Hall wrote: > >>Hello, > >> > >>I was working on a situation which was similar to the situation described in > >>this bug which was supposedly fixed in Java 5 and Java 6: > >> > >>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369510 > >> > >>The bug described how Content-Type was being auto-set to > >>application/x-www-form-urlencoded in cases where it should not be. > >> > >>I was seeing this problem, where the open-source JSCEP library was creating a > >>request to a Tomcat servlet I am implementing, which Tomcat was rejecting due > >>to encoding issues in the POST body. > >> > >>When I looked at the traffic using Wireshark TCP Stream reassembly I > >>discovered that the request had the URL-encoded content type even though no > >>code in JSCEP requested this. > >> > >>Upon reading through the unit test, > >>openjdk-7/jdk/test/sun/net/www/protocol/http/B6369510.java, I found a couple > >>of issues: > >> > >>1) The test fails if you have an IPv6 address configured on the system, > >>because the code doesn't enclose the IPv6 literal with '[]': > >> > >>URL url = new URL("http://" + address.getHostName() + ":" + address.getPort() + "/test/"); > >> > >>java.net.MalformedURLException: For input string: "0:0:0:0:0:0:0:40392" > >> at java.net.URL. (URL.java:601) > >> at java.net.URL. (URL.java:464) > >> at java.net.URL. (URL.java:413) > >> at B6369510.doClient(B6369510.java:63) > >> at B6369510. (B6369510.java:52) > >> at B6369510.main(B6369510.java:45) > >> > >>2) There appears to be a logic error in the test, or the fix and the bug > >>description do not match: > >> > >>if (requestMethod.equalsIgnoreCase("GET") && ct != null && > >> ct.get(0).equals("application/x-www-form-urlencoded")) > >> t.sendResponseHeaders(400, -1); > >> > >>else if (requestMethod.equalsIgnoreCase("POST") && ct != null && > >> !ct.get(0).equals("application/x-www-form-urlencoded")) > >> t.sendResponseHeaders(400, -1); > >> > >>This code is saying, the unit test will fail if the method is GET, and the > >>content-type is equal to url-encoded, and the unit test will fail if the > >>method is POST, and the content-type is *NOT* equal to url-encoded. > >> > >>But, in the evaluation, the bug states, "Content-Type is being set to > >>application/x-www-form-urlencoded for all HttpURLConnections requests other > >>than PUT requests. This is not necessary and could even cause problems for > >>some servers. We do not need to set this content-type for GET requests." > >> > >>To me this means, the code should not be setting the Content-Type to anything, > >>on any type of request, because it will cause problems across the board. > >> > >>So I think that the test and the bug fix do not actually fix the original bug > >>correctly, and the test needs to be fixed so it will work right on an IPv6 > >>based system. > >> > >>Thoughts? > >>Matthew Hall. > From anthony.vanelverdinghe at gmail.com Wed Mar 27 13:19:40 2013 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Wed, 27 Mar 2013 21:19:40 +0100 Subject: Problem with fix B6369510 for HttpURLConnection Content-Type In-Reply-To: <51532B6F.8090005@oracle.com> References: <20130327003315.GA5791@mhcomputing.net> <20130327004243.GA5834@mhcomputing.net> <51532B6F.8090005@oracle.com> Message-ID: <5153545C.9000508@gmail.com> Hello I don't see any issues with the bug, fix, and test: before the bug, the header was set for all but PUT requests (cfr. the evaluation) then it was reported this should not be done for GET requests, and the evaluation agreed on this, so the test makes sure GET requests don't have this header set anymore, while POST requests still do I believe the current behavior of setting a default Content-Type for POST requests is correct & even desired. Moreover, many Java applications do POST requests without explicitly setting the Content-type, thereby depending on the default of "application/x-www-form-urlencoded" being set. In my opinion, this is a bug in JSCEP, which does not set the Content-Type itself. If the content-type is not "application/x-www-form-urlencoded", then JSCEP should set it to whatever value is appropriate. Kind regards Anthony Op 27/03/2013 18:25, Rob McKenna schreef: > HI Matthew, > > On the face of it this makes sense. I don't have time to dig into it > this week, but I'll get stuck into it next week and get a fix together. > > -Rob > > On 27/03/13 00:42, Matthew Hall wrote: >> Forgot to include, offending code in HttpURLConnection: >> >> if (!method.equals("PUT") && (poster != null || streaming())) >> requests.setIfNotSet ("Content-type", >> "application/x-www-form-urlencoded"); >> >> Format adjusted a bit for readability. >> >> Matthew. >> >> On Tue, Mar 26, 2013 at 05:33:15PM -0700, Matthew Hall wrote: >>> Hello, >>> >>> I was working on a situation which was similar to the situation >>> described in >>> this bug which was supposedly fixed in Java 5 and Java 6: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369510 >>> >>> The bug described how Content-Type was being auto-set to >>> application/x-www-form-urlencoded in cases where it should not be. >>> >>> I was seeing this problem, where the open-source JSCEP library was >>> creating a >>> request to a Tomcat servlet I am implementing, which Tomcat was >>> rejecting due >>> to encoding issues in the POST body. >>> >>> When I looked at the traffic using Wireshark TCP Stream reassembly I >>> discovered that the request had the URL-encoded content type even >>> though no >>> code in JSCEP requested this. >>> >>> Upon reading through the unit test, >>> openjdk-7/jdk/test/sun/net/www/protocol/http/B6369510.java, I found >>> a couple >>> of issues: >>> >>> 1) The test fails if you have an IPv6 address configured on the system, >>> because the code doesn't enclose the IPv6 literal with '[]': >>> >>> URL url = new URL("http://" + address.getHostName() + ":" + >>> address.getPort() + "/test/"); >>> >>> java.net.MalformedURLException: For input string: "0:0:0:0:0:0:0:40392" >>> at java.net.URL. (URL.java:601) >>> at java.net.URL. (URL.java:464) >>> at java.net.URL. (URL.java:413) >>> at B6369510.doClient(B6369510.java:63) >>> at B6369510. (B6369510.java:52) >>> at B6369510.main(B6369510.java:45) >>> >>> 2) There appears to be a logic error in the test, or the fix and the >>> bug >>> description do not match: >>> >>> if (requestMethod.equalsIgnoreCase("GET") && ct != null && >>> ct.get(0).equals("application/x-www-form-urlencoded")) >>> t.sendResponseHeaders(400, -1); >>> >>> else if (requestMethod.equalsIgnoreCase("POST") && ct != null && >>> !ct.get(0).equals("application/x-www-form-urlencoded")) >>> t.sendResponseHeaders(400, -1); >>> >>> This code is saying, the unit test will fail if the method is GET, >>> and the >>> content-type is equal to url-encoded, and the unit test will fail if >>> the >>> method is POST, and the content-type is *NOT* equal to url-encoded. >>> >>> But, in the evaluation, the bug states, "Content-Type is being set to >>> application/x-www-form-urlencoded for all HttpURLConnections >>> requests other >>> than PUT requests. This is not necessary and could even cause >>> problems for >>> some servers. We do not need to set this content-type for GET >>> requests." >>> >>> To me this means, the code should not be setting the Content-Type to >>> anything, >>> on any type of request, because it will cause problems across the >>> board. >>> >>> So I think that the test and the bug fix do not actually fix the >>> original bug >>> correctly, and the test needs to be fixed so it will work right on >>> an IPv6 >>> based system. >>> >>> Thoughts? >>> Matthew Hall. > > From rob.mckenna at oracle.com Wed Mar 27 13:54:17 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 27 Mar 2013 20:54:17 +0000 Subject: Problem with fix B6369510 for HttpURLConnection Content-Type In-Reply-To: <5153545C.9000508@gmail.com> References: <20130327003315.GA5791@mhcomputing.net> <20130327004243.GA5834@mhcomputing.net> <51532B6F.8090005@oracle.com> <5153545C.9000508@gmail.com> Message-ID: <51535C79.7000907@oracle.com> Ah, yes. I interpreted that evaluation incorrectly too. We should be setting the content-type for POST requests which we appear to be doing. Furthermore user-agents must support it: http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4 -Rob On 27/03/13 20:19, Anthony Vanelverdinghe wrote: > Hello > > I don't see any issues with the bug, fix, and test: > before the bug, the header was set for all but PUT requests (cfr. the > evaluation) > then it was reported this should not be done for GET requests, and the > evaluation agreed on this, > so the test makes sure GET requests don't have this header set > anymore, while POST requests still do > > I believe the current behavior of setting a default Content-Type for > POST requests is correct & even desired. Moreover, many Java > applications do POST requests without explicitly setting the > Content-type, thereby depending on the default of > "application/x-www-form-urlencoded" being set. > > In my opinion, this is a bug in JSCEP, which does not set the > Content-Type itself. If the content-type is not > "application/x-www-form-urlencoded", then JSCEP should set it to > whatever value is appropriate. > > Kind regards > > Anthony > > > Op 27/03/2013 18:25, Rob McKenna schreef: >> HI Matthew, >> >> On the face of it this makes sense. I don't have time to dig into it >> this week, but I'll get stuck into it next week and get a fix together. >> >> -Rob >> >> On 27/03/13 00:42, Matthew Hall wrote: >>> Forgot to include, offending code in HttpURLConnection: >>> >>> if (!method.equals("PUT") && (poster != null || streaming())) >>> requests.setIfNotSet ("Content-type", >>> "application/x-www-form-urlencoded"); >>> >>> Format adjusted a bit for readability. >>> >>> Matthew. >>> >>> On Tue, Mar 26, 2013 at 05:33:15PM -0700, Matthew Hall wrote: >>>> Hello, >>>> >>>> I was working on a situation which was similar to the situation >>>> described in >>>> this bug which was supposedly fixed in Java 5 and Java 6: >>>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369510 >>>> >>>> The bug described how Content-Type was being auto-set to >>>> application/x-www-form-urlencoded in cases where it should not be. >>>> >>>> I was seeing this problem, where the open-source JSCEP library was >>>> creating a >>>> request to a Tomcat servlet I am implementing, which Tomcat was >>>> rejecting due >>>> to encoding issues in the POST body. >>>> >>>> When I looked at the traffic using Wireshark TCP Stream reassembly I >>>> discovered that the request had the URL-encoded content type even >>>> though no >>>> code in JSCEP requested this. >>>> >>>> Upon reading through the unit test, >>>> openjdk-7/jdk/test/sun/net/www/protocol/http/B6369510.java, I found >>>> a couple >>>> of issues: >>>> >>>> 1) The test fails if you have an IPv6 address configured on the >>>> system, >>>> because the code doesn't enclose the IPv6 literal with '[]': >>>> >>>> URL url = new URL("http://" + address.getHostName() + ":" + >>>> address.getPort() + "/test/"); >>>> >>>> java.net.MalformedURLException: For input string: >>>> "0:0:0:0:0:0:0:40392" >>>> at java.net.URL. (URL.java:601) >>>> at java.net.URL. (URL.java:464) >>>> at java.net.URL. (URL.java:413) >>>> at B6369510.doClient(B6369510.java:63) >>>> at B6369510. (B6369510.java:52) >>>> at B6369510.main(B6369510.java:45) >>>> >>>> 2) There appears to be a logic error in the test, or the fix and >>>> the bug >>>> description do not match: >>>> >>>> if (requestMethod.equalsIgnoreCase("GET") && ct != null && >>>> ct.get(0).equals("application/x-www-form-urlencoded")) >>>> t.sendResponseHeaders(400, -1); >>>> >>>> else if (requestMethod.equalsIgnoreCase("POST") && ct != null && >>>> !ct.get(0).equals("application/x-www-form-urlencoded")) >>>> t.sendResponseHeaders(400, -1); >>>> >>>> This code is saying, the unit test will fail if the method is GET, >>>> and the >>>> content-type is equal to url-encoded, and the unit test will fail >>>> if the >>>> method is POST, and the content-type is *NOT* equal to url-encoded. >>>> >>>> But, in the evaluation, the bug states, "Content-Type is being set to >>>> application/x-www-form-urlencoded for all HttpURLConnections >>>> requests other >>>> than PUT requests. This is not necessary and could even cause >>>> problems for >>>> some servers. We do not need to set this content-type for GET >>>> requests." >>>> >>>> To me this means, the code should not be setting the Content-Type >>>> to anything, >>>> on any type of request, because it will cause problems across the >>>> board. >>>> >>>> So I think that the test and the bug fix do not actually fix the >>>> original bug >>>> correctly, and the test needs to be fixed so it will work right on >>>> an IPv6 >>>> based system. >>>> >>>> Thoughts? >>>> Matthew Hall. >> >> > From mhall at mhcomputing.net Wed Mar 27 13:55:42 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Wed, 27 Mar 2013 13:55:42 -0700 Subject: Problem with fix B6369510 for HttpURLConnection Content-Type In-Reply-To: <5153545C.9000508@gmail.com> References: <20130327003315.GA5791@mhcomputing.net> <20130327004243.GA5834@mhcomputing.net> <51532B6F.8090005@oracle.com> <5153545C.9000508@gmail.com> Message-ID: But the SCEP RFC expects it to be sent without any header. How is JSCEP supposed to do this if Java overrides it with no way to prevent the override? -- Sent from my mobile device. Anthony Vanelverdinghe wrote: >Hello > >I don't see any issues with the bug, fix, and test: >before the bug, the header was set for all but PUT requests (cfr. the >evaluation) >then it was reported this should not be done for GET requests, and the >evaluation agreed on this, >so the test makes sure GET requests don't have this header set anymore, > >while POST requests still do > >I believe the current behavior of setting a default Content-Type for >POST requests is correct & even desired. Moreover, many Java >applications do POST requests without explicitly setting the >Content-type, thereby depending on the default of >"application/x-www-form-urlencoded" being set. > >In my opinion, this is a bug in JSCEP, which does not set the >Content-Type itself. If the content-type is not >"application/x-www-form-urlencoded", then JSCEP should set it to >whatever value is appropriate. > >Kind regards > > Anthony > > >Op 27/03/2013 18:25, Rob McKenna schreef: >> HI Matthew, >> >> On the face of it this makes sense. I don't have time to dig into it >> this week, but I'll get stuck into it next week and get a fix >together. >> >> -Rob >> >> On 27/03/13 00:42, Matthew Hall wrote: >>> Forgot to include, offending code in HttpURLConnection: >>> >>> if (!method.equals("PUT") && (poster != null || streaming())) >>> requests.setIfNotSet ("Content-type", >>> "application/x-www-form-urlencoded"); >>> >>> Format adjusted a bit for readability. >>> >>> Matthew. >>> >>> On Tue, Mar 26, 2013 at 05:33:15PM -0700, Matthew Hall wrote: >>>> Hello, >>>> >>>> I was working on a situation which was similar to the situation >>>> described in >>>> this bug which was supposedly fixed in Java 5 and Java 6: >>>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369510 >>>> >>>> The bug described how Content-Type was being auto-set to >>>> application/x-www-form-urlencoded in cases where it should not be. >>>> >>>> I was seeing this problem, where the open-source JSCEP library was >>>> creating a >>>> request to a Tomcat servlet I am implementing, which Tomcat was >>>> rejecting due >>>> to encoding issues in the POST body. >>>> >>>> When I looked at the traffic using Wireshark TCP Stream reassembly >I >>>> discovered that the request had the URL-encoded content type even >>>> though no >>>> code in JSCEP requested this. >>>> >>>> Upon reading through the unit test, >>>> openjdk-7/jdk/test/sun/net/www/protocol/http/B6369510.java, I found > >>>> a couple >>>> of issues: >>>> >>>> 1) The test fails if you have an IPv6 address configured on the >system, >>>> because the code doesn't enclose the IPv6 literal with '[]': >>>> >>>> URL url = new URL("http://" + address.getHostName() + ":" + >>>> address.getPort() + "/test/"); >>>> >>>> java.net.MalformedURLException: For input string: >"0:0:0:0:0:0:0:40392" >>>> at java.net.URL. (URL.java:601) >>>> at java.net.URL. (URL.java:464) >>>> at java.net.URL. (URL.java:413) >>>> at B6369510.doClient(B6369510.java:63) >>>> at B6369510. (B6369510.java:52) >>>> at B6369510.main(B6369510.java:45) >>>> >>>> 2) There appears to be a logic error in the test, or the fix and >the >>>> bug >>>> description do not match: >>>> >>>> if (requestMethod.equalsIgnoreCase("GET") && ct != null && >>>> ct.get(0).equals("application/x-www-form-urlencoded")) >>>> t.sendResponseHeaders(400, -1); >>>> >>>> else if (requestMethod.equalsIgnoreCase("POST") && ct != null && >>>> !ct.get(0).equals("application/x-www-form-urlencoded")) >>>> t.sendResponseHeaders(400, -1); >>>> >>>> This code is saying, the unit test will fail if the method is GET, >>>> and the >>>> content-type is equal to url-encoded, and the unit test will fail >if >>>> the >>>> method is POST, and the content-type is *NOT* equal to url-encoded. >>>> >>>> But, in the evaluation, the bug states, "Content-Type is being set >to >>>> application/x-www-form-urlencoded for all HttpURLConnections >>>> requests other >>>> than PUT requests. This is not necessary and could even cause >>>> problems for >>>> some servers. We do not need to set this content-type for GET >>>> requests." >>>> >>>> To me this means, the code should not be setting the Content-Type >to >>>> anything, >>>> on any type of request, because it will cause problems across the >>>> board. >>>> >>>> So I think that the test and the bug fix do not actually fix the >>>> original bug >>>> correctly, and the test needs to be fixed so it will work right on >>>> an IPv6 >>>> based system. >>>> >>>> Thoughts? >>>> Matthew Hall. >> >> From maurizio.cimadamore at oracle.com Thu Mar 28 04:40:18 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 28 Mar 2013 11:40:18 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130328114024.08FB148466@hg.openjdk.java.net> Changeset: 7bebe17ff323 Author: mcimadamore Date: 2013-03-28 11:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7bebe17ff323 8010469: Bad assertion in LambdaToMethod Summary: Add assertion in LambdaToMethod.serializedLambdaName Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java Changeset: a200d8ccfe47 Author: mcimadamore Date: 2013-03-28 11:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a200d8ccfe47 8010490: FindBugs: double assignments in LambdaToMethod.visitIdent Summary: Remove dead code from LambdaToMethod Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java From weijun.wang at oracle.com Thu Mar 28 05:28:44 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 28 Mar 2013 12:28:44 +0000 Subject: hg: jdk8/tl/jdk: 8010125: keytool -importkeystore could create a pkcs12 keystore with different storepass and keypass Message-ID: <20130328122907.EE76A48467@hg.openjdk.java.net> Changeset: a87fac00915e Author: weijun Date: 2013-03-28 20:27 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a87fac00915e 8010125: keytool -importkeystore could create a pkcs12 keystore with different storepass and keypass Reviewed-by: vinnie ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/tools/keytool/Resources.java + test/sun/security/tools/keytool/p12importks.sh From brian.goetz at oracle.com Thu Mar 28 08:34:23 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 28 Mar 2013 08:34:23 -0700 Subject: hg: jdk8/tl/jdk: 8001642: Add Optional , OptionalDouble, OptionalInt, OptionalLong In-Reply-To: References: <20130319231031.7F46B48272@hg.openjdk.java.net> Message-ID: > Has the optional classes been verified to serialize/deserialize correctly? > They are not serializable. > Finally, are these utilities critical to some other part JDK 8 that they were pushed out now as opposed to JDK 9? > > They are part of the libraries being added by JSR-335 / Project Lambda. There is extensive discussion on Optional on lambda-dev and the JSR 335 EG lists. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130328/593b9a39/attachment.html From jonathan.gibbons at oracle.com Thu Mar 28 10:49:57 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 28 Mar 2013 17:49:57 +0000 Subject: hg: jdk8/tl/langtools: 8006346: doclint should make allowance for headers generated by standard doclet Message-ID: <20130328175002.0B94F48470@hg.openjdk.java.net> Changeset: 991f11e13598 Author: jjg Date: 2013-03-28 10:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/991f11e13598 8006346: doclint should make allowance for headers generated by standard doclet Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/Env.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java + test/tools/javac/doclint/ImplicitHeadersTest.java + test/tools/javadoc/doclint/ImplicitHeadersTest.java From jonathan.gibbons at oracle.com Thu Mar 28 10:59:01 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 28 Mar 2013 17:59:01 +0000 Subject: hg: jdk8/tl/langtools: 8010511: Tests are creating files in /tmp Message-ID: <20130328175906.7F55348471@hg.openjdk.java.net> Changeset: d3648557391b Author: jjg Date: 2013-03-28 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d3648557391b 8010511: Tests are creating files in /tmp Reviewed-by: darcy ! test/tools/javac/T6558476.java ! test/tools/javac/T6900149.java ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/RunExamples.java From anthony.vanelverdinghe at gmail.com Thu Mar 28 11:11:28 2013 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Thu, 28 Mar 2013 19:11:28 +0100 Subject: Problem with fix B6369510 for HttpURLConnection Content-Type In-Reply-To: References: <20130327003315.GA5791@mhcomputing.net> <20130327004243.GA5834@mhcomputing.net> <51532B6F.8090005@oracle.com> <5153545C.9000508@gmail.com> Message-ID: <515487D0.6060602@gmail.com> Hello As far as I can see, SCEP is not an RFC yet, but still an Internet Draft [1]. In Appendix F, it says that a POST message contains "binary PKCS#7 data". It does indeed not mention an explicit Content-Type, but this seems no more than an oversight: the focus of the document is on doing SCEP requests via GET, in which case a Content-Type header is not needed. It 's not because the draft doesn't mention a Content-Type, that it expects the header to not be set. Actually, as the HTTP RFC says, it really should be set: "Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body." [2] Now I don't know what the correct Media Type is for "binary PKCS#7 data", but there is e.g. application/pkcs7-mime & application/pkcs7-signature. And setting it to "application/octet-stream" ought to work anyhow (again from the HTTP RFC: "If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".) As a conclusion, I believe the SCEP draft should be updated to mention the correct Content-Type in case of POST requests. [1] http://datatracker.ietf.org/doc/draft-nourse-scep/?include_text=1 [2] http://tools.ietf.org/html/rfc2616#section-7.2.1 Kind regards, Anthony Op 27/03/2013 21:55, Matthew Hall schreef: > But the SCEP RFC expects it to be sent without any header. How is JSCEP supposed to do this if Java overrides it with no way to prevent the override? From mhall at mhcomputing.net Thu Mar 28 11:13:42 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Thu, 28 Mar 2013 11:13:42 -0700 Subject: Problem with fix B6369510 for HttpURLConnection Content-Type In-Reply-To: <515487D0.6060602@gmail.com> References: <20130327003315.GA5791@mhcomputing.net> <20130327004243.GA5834@mhcomputing.net> <51532B6F.8090005@oracle.com> <5153545C.9000508@gmail.com> <515487D0.6060602@gmail.com> Message-ID: <20130328181342.GB21370@mhcomputing.net> On Thu, Mar 28, 2013 at 07:11:28PM +0100, Anthony Vanelverdinghe wrote: > As a conclusion, I believe the SCEP draft should be updated to > mention the correct Content-Type in case of POST requests. Good analysis, I agree. I'll see if I can get it corrected. It would still be nice if there were a way to inform HttpURLConnection that you do not want it to change your content-types, even if they're blank. There are going to be times where it could get in the way. There's also the topic of the IPv6 incapable unit test. Which makes me wonder, why hasn't anyone else unit-testing the JDK ran into this? I am betting there are a lot of IPv6-incompatible JDK unit tests out there, and it should be addressed as a bigger initiative to be IPv6 Dual Stack ready. Regards, Matthew. From mandy.chung at oracle.com Thu Mar 28 13:16:32 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 28 Mar 2013 20:16:32 +0000 Subject: hg: jdk8/tl/jdk: 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level Message-ID: <20130328201656.E120C48477@hg.openjdk.java.net> Changeset: e433ed08b733 Author: mchung Date: 2013-03-28 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e433ed08b733 8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level Reviewed-by: mchung Contributed-by: peter.levart at gmail.com, bourges.laurent at gmail.com ! src/share/classes/sun/util/logging/PlatformLogger.java ! test/sun/util/logging/PlatformLoggerTest.java From chris.hegarty at oracle.com Sun Mar 31 07:16:24 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 31 Mar 2013 15:16:24 +0100 Subject: RFR: JDK-8007373 Inet6Address serialization incompatibility In-Reply-To: <5151CF7F.4080508@oracle.com> References: <5151CF7F.4080508@oracle.com> Message-ID: <44FC0EA3-8EA9-4E25-AE52-5D0725D055B4@oracle.com> Thanks for taking this Mark. It was my change that introduced this incompatibility. The source changes look fine to me. In fact, the removal of scope_ifname_set was not necessary for the original fix, just "bad" clean up. Also, there is no need to reset its default value where declared. The test needs the usual GPL header. We never call exit from a test, but it looks like this only possible during generation of the static byte arrays. -Chris On 26 Mar 2013, at 16:40, Mark Sheppard wrote: > Hi, > could you oblige and review the webrev below as a fix for the issue raised in > JDK8007373, Inet6Address serialization incompatibility > > http://cr.openjdk.java.net/~msheppar/8007373/webrev.00/ > > Description: > We seem to have changed the serialization of Inet6Address in jdk8 compared with jdk7. It is causing a problem de-serializing instances (in 7) that were serialized by 8. The scope-id is not being recreated correctly. > > this is related to JDK-8004675 > > The fix has re-instated the scope_ifname_set variable, and sets this explicitly during serialization (writeObject). It also > sets the scope id to 0 when the scope_ifname is determined to be null during deserialization (readObject). > The refactoring undertaken in 8004675 has been left in place. > > It will be noted that an additional issue has been raised, JDK-8010826, arising from testing during this fix. > the scope id can be incorrect after serialization where a scoped interface in the serialized object does not > exist on the deserializing host. > > > regards > Mark