Details
-
New Feature
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
The classic client supports a single socket timeout, however requests are often broken into three (or more) phases. Note that connection initialization is not considered in this design, it aligns to the connection/route/pool rather than individual requests.
- Sending the request (request line, headers, and optionally a request body)
- Waiting for the remote server to process the request, until the first response byte is received.
- Reading the response (response line, headers, and optionally a response body)
Note that this can have additional steps between (1) and (2) for Expect-Continue, and it's important not to set an incorrect timeout for CONNECT upgrades.
Steps (1) and (3) are I/O timeouts, while (2) is generally based on the server processing a request and preparing to send a response. There are cases in which the server processes data as it's received or sent, where one might not wish to rely on more specific timeouts, however in the general case it is helpful to detect unhealthy state without waiting the maximum response duration.
General Proposal
I'd like to include options in the request config for a request socket timeout (step 1) and response socket timeout (step 3) allowing the existing responseTimeout to apply to step 2. I expect this can be done in a way that does not have any impact unless values are configured, but will require careful testing.
Looking at the code, such a change would span both httpclient and httpcore projects. I haven't dug into precisely how we would plumb this data to the HttpRequestExecutor.
The RequestConfig type is used by both the classic and async clients, it's not clear if we would support this feature on the asynchronous client as well as the blocking client initially.
Any and all feedback is appreciated, I'd like to build consensus on the feature/idea before I begin to build it.