Re: DefaultProxySelector socks override
[cc'ing net-dev, we can then probably drop core-libs-dev and continue
the discussion over on net-dev]
Christos,
SOCKS is really old and not as widely deployed as other proxies. That
said, I don't have any specific problem with your proposal. SOCKS is
really in maintenance mode in the JDK, but I do see this as a reasonable
request/proposal.
Since socksNonProxyHosts is only set on Mac I can only presume that it
is a remanent of the mac port. I would prefer to make the cosmetic
changes as part of this patch. I cannot see that we need to keep
socksNonProxyHosts, as it does nothing in the JDK anyway.
Can you do this?
-Chris.
On 03/27/2013 02:41 PM, chris...@zoulas.com wrote:
This trivial patch add "socksNonProxyHosts" to the default proxy,
so that we can select which socket traffic will be directed to
the proxy and which not. There is currently no way to do this. In
my scenario, I have applications that would benefit in terms of
performance to connect directly to our internal network hosts, and
at the same time need to connect to the outside via our socks proxy.
Having all of them go through the socks proxy would require me to
buy a very expensive proxy, and suffer the latency anyway. I would
also like to note that the "socksNonProxyHosts" variable is in:
jdk/src/share/native/java/lang/System.c:PUTPROP(props,
"socksNonProxyHosts", sprops->exceptionList);
for MacOS/X but nowhere else. Finally (not in this patch), it would
be nice to provide socks.nonProxyHosts etc. to be symmetric with the
other http, https, and ftp variables. But this is purely cosmetic. And
here's the patch...
Enjoy,
christos
--- jdk/src/share/classes/sun/net/spi/DefaultProxySelector.java.origWed Mar
27 10:26:36 2013 -0400
+++ jdk/src/share/classes/sun/net/spi/DefaultProxySelector.java Wed Mar 27
10:28:15 2013 -0400
@@ -124,6 +124,7 @@
final String defaultVal;
static NonProxyInfo ftpNonProxyInfo = new
NonProxyInfo("ftp.nonProxyHosts", null, null, defStringVal);
static NonProxyInfo httpNonProxyInfo = new
NonProxyInfo("http.nonProxyHosts", null, null, defStringVal);
+static NonProxyInfo socksNonProxyInfo = new
NonProxyInfo("socksNonProxyHosts", null, null, defStringVal);
NonProxyInfo(String p, String s, RegexpPool pool, String d) {
property = p;
@@ -186,7 +187,9 @@
pinfo = NonProxyInfo.httpNonProxyInfo;
} else if ("ftp".equalsIgnoreCase(protocol)) {
pinfo = NonProxyInfo.ftpNonProxyInfo;
-}
+} else if ("socket".equalsIgnoreCase(protocol)) {
+pinfo = NonProxyInfo.socksNonProxyInfo;
+}
/**
* Let's check the System properties for that protocol
hg: jdk8/tl/jdk: 8010837: FileInputStream.available() throw IOException when encountering negative available values
Changeset: 49602f599c08 Author:dxu Date: 2013-03-27 09:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49602f599c08 8010837: FileInputStream.available() throw IOException when encountering negative available values Summary: Remove the check in the native code to allow negative values Reviewed-by: mchung ! src/solaris/native/java/io/io_util_md.c + test/java/io/FileInputStream/NegativeAvailable.java
hg: jdk8/tl/jdk: 7185456: (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotations
Changeset: ae03282ba501 Author:darcy Date: 2013-03-27 09:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae03282ba501 7185456: (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotations Reviewed-by: mduigou, jfranck ! src/share/classes/sun/reflect/annotation/AnnotationType.java
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.(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.
Re: DefaultProxySelector socks override
On 03/27/2013 05:22 PM, chris...@zoulas.com wrote: Sure, I just requested a subscription to net-dev so I might not see the first few messages. To clarify: 1. I will add socks.proxyHost and socks.proxyPort for consistency with the other protocols, leaving as is socksProxyHost and socksProxyPort for compatibility. 2. I will add socks.nonProxyHosts and not socksNonProxyHosts. Is that what you had in mind? Re-checking the code I take back my previous comment. We already have socksProxyHost, socksProxyPort, socksProxyVersion so your original proposal of 'socksNonProxyHosts' is probably best, and consistent with existing properties. -Chris. christos
Re: DefaultProxySelector socks override
On Mar 27, 5:30pm, chris.hega...@oracle.com (Chris Hegarty) wrote: -- Subject: Re: DefaultProxySelector socks override | On 03/27/2013 05:22 PM, chris...@zoulas.com wrote: | > | > Sure, I just requested a subscription to net-dev so I might not see the | > first few messages. To clarify: | > | > 1. I will add socks.proxyHost and socks.proxyPort for consistency | >with the other protocols, leaving as is socksProxyHost and | >socksProxyPort for compatibility. | > 2. I will add socks.nonProxyHosts and not socksNonProxyHosts. | > | > Is that what you had in mind? | | Re-checking the code I take back my previous comment. We already have | | socksProxyHost, socksProxyPort, socksProxyVersion | | so your original proposal of 'socksNonProxyHosts' is probably best, and | consistent with existing properties. I concur. Nothing for me to do :-) Best, christos
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.(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.
>
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.(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.
Re: Problem with fix B6369510 for HttpURLConnection Content-Type
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.(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.
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 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.(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.
>>
>>
