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: [email protected]
For additional commands, e-mail: [email protected]
