[
https://issues.apache.org/jira/browse/HTTPCLIENT-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17423640#comment-17423640
]
Oleg Kalnichevski commented on HTTPCLIENT-2135:
-----------------------------------------------
> That mostly makes sense to me. I'm not so sure that HTTP protocol negotiation
> would belong in there, since there are other approaches that aren't based on
> TLS (such as prior knowledge, and the new-deprecated HTTP Upgrade mechanism)
[~rschmitt] HTTP protocol negotiation setting is directly equivalent to the TLS
ALPN extension. It does not preclude us from using HTTP protocol negotiation
setting elsewhere, should we decide to support HTTP upgrade mechanism for plain
connections.
Where would you have it instead? HTTP protocol policy at the client level seems
too restrictive and misplaced to me.
Oleg
> TLS handshake timeouts cannot be controlled through RequestConfig
> -----------------------------------------------------------------
>
> Key: HTTPCLIENT-2135
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2135
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 5.0.3
> Reporter: Ryan Schmitt
> Priority: Major
> Fix For: 5.2-alpha1
>
>
> Apparently as a consequence of HTTPCLIENT-2091 and/or HTTPCLIENT-2099, TLS
> handshake timeouts can no longer be specified through any of the three
> {{RequestConfig}} timeout parameters (connect, connection request, response).
> The only way to limit TLS handshake duration is through low-level socket
> configuration (socket timeout), which of course affects more than just TLS
> handshakes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
