[
https://issues.apache.org/jira/browse/HTTPCORE-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17513783#comment-17513783
]
Ryan Schmitt commented on HTTPCORE-710:
---------------------------------------
[~olegk] Reproducer is here:
https://github.com/rschmitt/httpclient-benchmark/commit/d4c01121ee17d2f5ff2f3551e58b3dd45cc20740
Looks like my use of a non-default {{HttpVersionPolicy}}, in this case
{{FORCE_HTTP_1}}, is what triggered the regression.
> 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: [email protected]
For additional commands, e-mail: [email protected]
