[
https://issues.apache.org/jira/browse/HTTPCORE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506459#comment-13506459
]
Oleg Kalnichevski commented on HTTPCORE-319:
--------------------------------------------
I think I have a theory what might be happening here. I think the cause of the
problem is a bug in the HTTP connection state management logic triggered by
premature termination of the connection but some things just do not seem to add
up. Most importantly I do not see where the I/O session code can be looping.
Another thing is that I do not see why #produceOutput method does not fire,
even though the session clearly enables output events in order to flush some
data stuck in the output buffer. It appears that the connection is still trying
to write out request body while the remote endpoint is clearly no longer
expecting any more data. More mystery. If the connection can timeout why on
earth are we not seeing any activity on that session that keeps inactivity
timer from triggering a timeout event?
Could you please do the following for me?
(1) Could you please tell me exactly there the session is looping, which method
and which loop?
(2) After that could you please apply the following patch and let me know if
that makes any difference?
Oleg
---
diff --git
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/DefaultNHttpClientConnection.java
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/DefaultNHttpClientConnection.java
index bf3eb62..0c10041 100644
---
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/DefaultNHttpClientConnection.java
+++
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/DefaultNHttpClientConnection.java
@@ -156,10 +156,6 @@ public class DefaultNHttpClientConnection
}
public void consumeInput(final NHttpClientEventHandler handler) {
- if (this.status != ACTIVE) {
- this.session.clearEvent(EventMask.READ);
- return;
- }
try {
if (this.response == null) {
int bytesRead;
diff --git
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/DefaultNHttpServerConnection.java
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/DefaultNHttpServerConnection.java
index 28b4046..ffb834d 100644
---
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/DefaultNHttpServerConnection.java
+++
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/DefaultNHttpServerConnection.java
@@ -162,10 +162,6 @@ public class DefaultNHttpServerConnection
}
public void consumeInput(final NHttpServerEventHandler handler) {
- if (this.status != ACTIVE) {
- this.session.clearEvent(EventMask.READ);
- return;
- }
try {
if (this.request == null) {
int bytesRead;
> SSLIOSession goes into a loop if the server rejects an invalid certificate
> --------------------------------------------------------------------------
>
> Key: HTTPCORE-319
> URL: https://issues.apache.org/jira/browse/HTTPCORE-319
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.2.2
> Reporter: Scott Stanton
> Assignee: Oleg Kalnichevski
> Priority: Critical
> Fix For: 4.2.3
>
> Attachments: log
>
>
> To reproduce:
> * Set up an SSL server that requests certificates from the client.
> * Set up a client with an expired SSL certificate.
> * Establish a connection from the client to the server using BaseNIOReactor
> and SSLIOSession.
> The server will proceed through the handshake until the client supplies its
> certificate in response to the CertificateRequest message. At this point,
> the server's certificate verification will fail and it will close the
> connection.
> The client socket will become readable due to the EOF and the
> SSLIOSession.isAppInputReady() method is called to handle the EOF. The
> bytesRead gets set to -1, which sets this.endOfStream = true. Nothing ever
> sets the session into the CLOSING or CLOSED state, so it keeps looping on the
> readable EOF event.
> I'm not sure what the best approach to fixing this should be. It appears
> that if I close the session manually with the debugger from inside
> isAppInputReady, the system proceeds normally from that point, however I
> don't know what the implications of doing that might be.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
