hg: jdk8/tl/langtools: 7059170: Assume availablility of URLClassLoader.close
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
Re: Problem with fix B6369510 for HttpURLConnection Content-Type
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.
Problem with fix B6369510 for HttpURLConnection Content-Type
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.
hg: jdk8/tl/langtools: 7041251: Use j.u.Objects utility methods in langtools
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
hg: jdk8/tl/jdk: 2 new changesets
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
RFR: JDK-8007373 Inet6Address serialization incompatibility
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
