seongsu shin created HTTPCLIENT-2436:
----------------------------------------
Summary: Async connect does not retry next resolved address after
TLS handshake failure, unlike classic
Key: HTTPCLIENT-2436
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2436
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpClient (async), HttpClient (classic), Site
Affects Versions: 5.6.5
Reporter: seongsu shin
h2. Summary
When the TLS handshake fails against a host that resolves to several addresses,
the classic transport tries the next resolved address and performs another
handshake. The async transport does not. The two transports behave differently
for the same configuration.
h2. How to reproduce
Use a server on {{localhost}} (resolves to {{127.0.0.1}} and {{::1}}) that
accepts the TCP connection but never answers the TLS handshake. Configure
{{handshakeTimeout}} (e.g. 3s), then execute one request with the classic
client and one with the async client.
h2. Observed
* classic: waits 2 x handshakeTimeout (one handshake per resolved address)
* async: fails after 1 x handshakeTimeout
h2. Expected
Both transports should behave consistently when a handshake fails and more
resolved addresses are available.
h2. Notes
Found while writing the timeouts section for HTTPCLIENT-2404
(https://github.com/apache/httpcomponents-website/pull/48). Oleg Kalnichevski
asked there for a JIRA, saying the transports should be consistent.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
