Problem with fix B6369510 for HttpURLConnection Content-Type

[Rob McKenna]

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