Problem with fix B6369510 for HttpURLConnection Content-Type

[Rob McKenna]

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.<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.