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.<init>(URL.java:601)
> at java.net.URL.<init>(URL.java:464)
> at java.net.URL.<init>(URL.java:413)
> at B6369510.doClient(B6369510.java:63)
> at B6369510.<init>(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.
