Re: Problem with fix B6369510 for HttpURLConnection Content-Type
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.
Re: Problem with fix B6369510 for HttpURLConnection Content-Type
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 +, 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.
Re: Problem with fix B6369510 for HttpURLConnection Content-Type
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.
Re: Problem with fix B6369510 for HttpURLConnection Content-Type
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.
Problem with fix B6369510 for HttpURLConnection Content-Type
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.
Re: Problem with fix B6369510 for HttpURLConnection Content-Type
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.
