You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2022/04/01 15:13:00 UTC
[jira] [Commented] (HTTPCORE-710) Async client hangs if remote peer closes connection during TLS handshake
[ https://issues.apache.org/jira/browse/HTTPCORE-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515960#comment-17515960 ]
ASF subversion and git services commented on HTTPCORE-710:
----------------------------------------------------------
Commit 1736fe414f5f27a4199d4752b4a49e847e7079fc in httpcomponents-core's branch refs/heads/HTTPCORE-710 from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=1736fe4 ]
HTTPCORE-710: In case of some TLS handshake failures (protocol version mismatch) the local TLS engine quietly closes the stream instead of throwing a handshake exception
> Async client hangs if remote peer closes connection during TLS handshake
> ------------------------------------------------------------------------
>
> Key: HTTPCORE-710
> URL: https://issues.apache.org/jira/browse/HTTPCORE-710
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore
> Affects Versions: 5.2-beta1
> Reporter: Ryan Schmitt
> Priority: Blocker
>
> I discovered a regression in the 5.2 async client while testing various failure modes for TLS negotiation. In this case, the failure condition is when the client sends a Client Hello and the server responds by immediately closing the connection (with a FIN in this case, not a RST). With client version 5.1.3, when this happened the client would simply throw an exception with the following cause:
> {code}
> Caused by:
> org.apache.hc.core5.http2.impl.nio.ProtocolNegotiationException: Unexpected input
> at app//org.apache.hc.core5.http2.impl.nio.ClientHttpProtocolNegotiator.inputReady(ClientHttpProtocolNegotiator.java:165)
> at app//org.apache.hc.core5.reactor.ssl.SSLIOSession.decryptData(SSLIOSession.java:574)
> at app//org.apache.hc.core5.reactor.ssl.SSLIOSession.access$400(SSLIOSession.java:72)
> at app//org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:172)
> at app//org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:131)
> at app//org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
> ... 5 more
> {code}
> Now, on the latest 5.2 nightly, no exception gets thrown at all; whereas {{SSLIOSession}} used to call into {{ClientHttpProtocolNegotiator#inputReady}}, it now ends up in {{AbstractHttp1IOEventHandler#inputReady}} and then {{AbstractHttp1StreamDuplexer#onInput}}, which placidly requests a graceful shutdown by following this code path:
> {code:java}
> if (endOfStream && !inbuf.hasData()) {
> if (outputIdle() && inputIdle()) {
> requestShutdown(CloseMode.GRACEFUL);
> {code}
> However, even if I force the code to take the other path ({{shutdownSession(new ConnectionClosedException("Connection closed by peer"))}}), the client still just hangs forever. Something, presumably {{SSLIOSession}} itself, is forgetting to invoke the appropriate callback to fail the handshake in this situation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org