drogonframework / drogonframework/drogon
HttpClient timeout handling: support for connect timeout and response timeout
- Dominant language
- C++
- Stars
- 14.3k
- Forks
- 1.4k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 14
Description
Hi Drogon team,
First of all, thank you for building and maintaining Drogon. I have been using `HttpClient` and it has been very helpful.
I would like to ask for some guidance around `HttpClient` timeout handling.
In my use case, I need to distinguish between:
- **connect timeout**: the upstream cannot be connected quickly
- **response timeout**: the connection is established, but the upstream responds too slowly
Right now, it seems difficult to separate these two cases cleanly with the current `HttpClient` API.
From reading the code, requests seem to go through different internal states:
- waiting in `requestsBuffer_` before DNS/connect/available connection
- then moving into `pipeliningCallbacks_` after the request is actually sent
Because of this, when I try to implement timeout outside of Drogon, it is hard for me to know whether a request is still waiting for connection or has already been sent and is waiting for a response.
I also observed this log in some timeout scenarios:
```cpp
LOG_ERROR << "More responses than expected!";
```
From my understanding, this may happen when:
1. I time out a request locally
2. later, the upstream still sends back a delayed response
3. `HttpClient` receives that response when there is no longer a matching pending callback in the pipeline queue
4. the connection gets shutdown
This is especially hard for me when using short timeout values and connection reuse.
Would it be possible to support one of the following in the future?
1. separate timeout settings for:
- DNS/connect
- request/response
or
2. clearer lifecycle hooks / callbacks for stages like:
- DNS resolved
- connected
- request sent
- waiting response
or
3. a recommended safe way to handle local timeout so that delayed responses do not cause request/response mismatch later
A very common use case for me is something like:
- connect timeout: 300ms
- response timeout: 2000ms
This helps fail fast when the upstream is unreachable, while still allowing enough time for a slow but reachable upstream to respond.
If there is already a recommended way to do this with the current Drogon `HttpClient`, I would really appreciate your guidance.
Thank you very much for your time and support.
Contributor guide
Assessment
This issue has not been assessed yet.