drogonframework / drogonframework/drogon

HttpClient timeout handling: support for connect timeout and response timeout

Open
#2,483 2 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.