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