Open
Description
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue, please leave a comment
Describe the Feature
Today we expose several timeouts on HttpClientEngineConfig including:
- socketReadTimeout - Timeout for each read to an underlying socket
- socketWriteTimeout - Timeout for each write to an underlying socket
- connectTimeout - The amount of time to wait for a connection to be established
- connectionAcquireTimeout - The amount of time to wait for an already-established connection from a connection pool
- connectionIdleTimeout - The amount of time before an idle connection should be reaped from a connection pool
An HTTP engine MAY not support all of these but to the extent possible they try to respect these settings.
We should extend configuration to cover:
- tlsNegotiationTimeout - Upper limit on how long from the time a TLS handshake is allowed to take (client and server have fully negotiated ciphers and exchanged keys)
- (maybe) timeToFirstHeader - Timeout after sending request to first header received (TTFH).
- This may overlap sufficiently with socket read timeout to not be necessary. We should strive for less knobs not more and understand if we really need this
- httpAttemptTimeout - Amount of time to wait for a single HTTP request to complete before giving up and timing out
- apiCallTimeout - Amount of time for the client to complete the execution of an API call (including retries)
NOTE: Both httpAttemptTimeout and apiCallTimeout have no sensible default and would need to be opt-in only and set by a user
NOTE: Not all of these would necessarily be on the HTTP engine config (e.g. apiCallTimeout)