You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Carter Kozak (Jira)" <ji...@apache.org> on 2021/03/17 14:39:00 UTC

[jira] [Created] (HTTPCLIENT-2143) Support additional per-request timeout options

Carter Kozak created HTTPCLIENT-2143:
----------------------------------------

             Summary: Support additional per-request timeout options
                 Key: HTTPCLIENT-2143
                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2143
             Project: HttpComponents HttpClient
          Issue Type: New Feature
          Components: HttpClient (classic)
            Reporter: Carter Kozak
            Assignee: Carter Kozak


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.
h3. 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.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org