Problem with fix B6369510 for HttpURLConnection Content-Type (original) (raw)

Matthew Hall mhall at mhcomputing.net
Wed Mar 27 11:03:51 PDT 2013

Thanks! Let me know what your opinion is, after you get a chance to look it over.

Matthew.

On Wed, Mar 27, 2013 at 05:25:03PM +0000, Rob McKenna wrote:

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/viewbug.do?bugid=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.

More information about the net-dev mailing list