Bring the READMEs and the docs pages (en and ja) in line with the current header: - Fix the client sample that does not compile, the Transfer-Encoding statement for default headers, the verifier callback comment, the thread pool spawn rule, the sanitize_filename description, and the inverted Accept-Encoding sentence. - Describe recent behaviour: TLS errors behind Read/Write failures, Host validation, Connection: close for a body without length, content_reader rules, refused CONNECT, WebSocketClient proxies, CPPHTTPLIB_INTERIM_RESPONSE_MAX_COUNT, the SSE event size limit, and the payload limit of the Stream API. - Complete the API references of WebSocket, WebSocketClient and the stream:: helpers, and the SSE reconnect rules. - Fix cookbook pages: keychain loading on every backend, received Close status, a multipart sample that trusted the client's file name, an echo sample that sent binary as text, SNI, pre-request handler scope, stop() with WebSocket handlers, and the thread pool notes. - Restore the mutex in the LLM app's Chapter 5 code.
1.7 KiB
title, order, status
| title | order | status |
|---|---|---|
| C13. Set an Overall Timeout | 13 | draft |
The three timeouts from C12. Set timeouts each cover only one step: the read and write timeouts apply to a single recv or send call, and the connection timeout to connecting. To cap the total time a request can take, use set_max_timeout().
Basic usage
httplib::Client cli("http://localhost:8080");
cli.set_max_timeout(5000); // 5 seconds (in milliseconds)
auto res = cli.Get("/slow-endpoint");
The value is in milliseconds. Once that much time has passed since the request started, waiting for the response is cut off. The limit does not shorten the connection and write waits themselves, so bound those with set_connection_timeout and set_write_timeout.
Use std::chrono
There's also an overload that takes a std::chrono duration.
using namespace std::chrono_literals;
cli.set_max_timeout(5s);
When to use which
set_read_timeout fires when no data arrives for a while. If data keeps trickling in bit by bit, it will never fire. An endpoint that sends one byte per second can make set_read_timeout useless no matter how short you set it.
set_max_timeout caps elapsed time, so it handles those cases cleanly. It's great for calls to external APIs or anywhere you don't want users waiting forever.
cli.set_connection_timeout(3s);
cli.set_read_timeout(10s);
cli.set_max_timeout(30s); // abort if the whole request takes over 30s
Note:
set_max_timeout()works alongside the regular timeouts. Short stalls get caught byset_read_timeout; long-running requests get capped byset_max_timeout. Use both for a safety net.