Problem with fix B6369510 for HttpURLConnection Content-Type

[Matthew Hall]

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.