[
https://issues.apache.org/jira/browse/HTTPCORE-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16392444#comment-16392444
]
Gary Gregory commented on HTTPCORE-517:
---------------------------------------
In order to do this properly, I think we need to do this (does not compile, see
below):
{noformat}
diff --git
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java
index 38598bb..358a533 100644
---
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java
+++
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java
@@ -280,6 +280,10 @@
closeChannel(socketChannel);
request.failed(ex);
return;
+ } catch (final SecurityException ex) {
+ closeChannel(socketChannel);
+ request.failed(ex);
+ return;
}
final SessionRequestHandle requestHandle = new
SessionRequestHandle(request);
diff --git
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/SessionRequestImpl.java
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/SessionRequestImpl.java
index f9656b9..4692ecd 100644
---
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/SessionRequestImpl.java
+++
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/SessionRequestImpl.java
@@ -56,8 +56,8 @@
private final SessionRequestCallback callback;
private volatile int connectTimeout;
- private volatile IOSession session = null;
- private volatile IOException exception = null;
+ private volatile IOSession session;
+ private volatile Exception exception;
public SessionRequestImpl(
final SocketAddress remoteAddress,
@@ -138,7 +138,7 @@
}
}
- public void failed(final IOException exception) {
+ public void failed(final Exception exception) {
if (exception == null) {
return;
}
{noformat}
But this means breaking BC on
{{org.apache.http.nio.reactor.SessionRequest.getException()}} to make it return
an {{Exception}} instead of an {{IOException}}. IMO, this is not acceptable.
We can do this for version 5 though. Within 4, we are left with wrapping the
{{SecurityException}} in a new {{IOException}} like this:
{noformat}
diff --git
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java
index 38598bb..da21c1b 100644
---
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java
+++
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java
@@ -280,6 +280,10 @@
closeChannel(socketChannel);
request.failed(ex);
return;
+ } catch (final SecurityException ex) {
+ closeChannel(socketChannel);
+ request.failed(new IOException(ex));
+ return;
}
final SessionRequestHandle requestHandle = new
SessionRequestHandle(request);
{noformat}
Thoughts?
> Allow SecurityManager to stop socket connections
> ------------------------------------------------
>
> Key: HTTPCORE-517
> URL: https://issues.apache.org/jira/browse/HTTPCORE-517
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore NIO
> Reporter: Paul Thompson
> Priority: Major
> Fix For: 4.4.10, 5.0-beta3
>
>
> Utilising a java security manager you're able to block certain socket
> connections from taking place. This can be useful to block outgoing
> connections for all components.
> {code:java}
> @Override
> public void checkConnect(String host, int port) {
> if(port != -1) {
> for (String bannedPerm : bannedSocketPerms) {
> if (host.equalsIgnoreCase(bannedPerm)) {
> throw new new SecurityException();
> }
> }
> }
> }{code}
> Unfortunately when doing this, the apache reactor shuts down. The call site
> is in the {{DefaultConnectingIOReactor}}.
> {code:java}
> final boolean connected = socketChannel.connect(request.getRemoteAddress());
> {code}
> this line is wrapped in a try/catch that catches an {{IOException}}. This
> means the {{SecurityException}} is propagated out, and is never offered to be
> caught (even with the {{ExceptionHandler}} that you can set.
> It would be an improvement to be able to throw these types of exceptions and
> have the reactor continue on. It's very understandable for the
> {{SecurityException}} to be a transient error and as such shouldn't shut down
> the entire reactor by default.
> Either that, or one should be able to define a {{handleRuntimeException}} (as
> seen in the {{BaseIOREactor}}) in such a way that it would get the option to
> handle the exceptions that are thrown as part of the {{processEvents}} call
> in the {{AbstractIOReactor}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
