But the SCEP RFC expects it to be sent without any header. How is JSCEP
supposed to do this if Java overrides it with no way to prevent the override?
--
Sent from my mobile device.
Anthony Vanelverdinghe <anthony.vanelverdin...@gmail.com> 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.
>>
>>
