bef278e0d2
Samples that did not compile or run as shown: - res.user_data.get<T>() inside a generic lambda needs the `template` keyword; use explicit parameter types (tour 09, cookbook s15). - listen() on a Unix domain socket fails with port 0 (tour 09, s22). - "*.dev.local" is not a NO_PROXY pattern (c16). - ssl_backend_error() holds a verify result, not an ERR_get_error() value, after a verification failure; decode each with the matching OpenSSL function (c18). - The content provider's `length` is everything that remains, so the sample read the whole file in one call (s05). Statements corrected: - Client keep-alive is off by default; c14 is rewritten around set_keep_alive(true). - Mounted files are looked up before GET handlers (tour 04, s04). - Params keep insertion order, and to_string(Error::Connection) reads "Could not establish connection" (tour 02). - A chunked provider ends with sink.done(), and post_routing_handler runs before the response is sent (tour 09). - Timeouts surface as Error::Read; Error::Timeout comes from the stream API (c17). The max timeout cuts off the wait for the response only (c13). The progress callback needs Content-Length (c11). - Encoding selection follows q-values, then Brotli, gzip, Zstd (s08), and the client compresses with the first of those it was built with (c15). - stop() cuts a provider-driven response short (s19); a rejected content_reader already gets 400 or 413 (s07); user_data values must be copyable (s12); Client accepts a client certificate too (t04); on_message() is the fallback for every unhandled event and 204/403/404 end reconnection (e04); the pong timeout takes two to three intervals and ends a waiting read() (w02). In the LLM app tutorial, an uncaught exception does not crash the server, so say what it does instead. Drop the server and client timeout settings whose stated purpose, covering inference and download time, they do not serve: those timeouts bound a single socket wait. Update the llama.cpp server layout in chapter 7.
1.9 KiB
title, order, status
| title | order | status |
|---|---|---|
| C14. Understand Connection Reuse and Keep-Alive | 14 | draft |
By default, httplib::Client closes the connection after every request (it sends Connection: close). Call set_keep_alive(true) and the requests you send through the same instance share one TCP connection, so you don't pay the TCP and TLS handshake cost on every call.
Enable Keep-Alive
httplib::Client cli("https://api.example.com");
cli.set_keep_alive(true);
auto res1 = cli.Get("/users/1");
auto res2 = cli.Get("/users/2"); // reuses the same connection
auto res3 = cli.Get("/users/3"); // reuses the same connection
After that, just hold on to cli. Internally, the socket stays open across calls. The effect is especially noticeable over HTTPS, where the TLS handshake is expensive.
Turn Keep-Alive back off
To go back to a fresh connection every time, call set_keep_alive(false). This is the default behavior.
cli.set_keep_alive(false);
Don't create a Client per request
If you create a Client inside a loop and let it fall out of scope each iteration, you lose the reuse benefit. Create the instance outside the loop.
// Bad: a new connection every iteration
for (auto id : ids) {
httplib::Client cli("https://api.example.com");
cli.set_keep_alive(true);
cli.Get("/users/" + id);
}
// Good: the connection is reused
httplib::Client cli("https://api.example.com");
cli.set_keep_alive(true);
for (auto id : ids) {
cli.Get("/users/" + id);
}
Concurrent requests
If you want to send requests in parallel from multiple threads, give each thread its own Client instance. A single Client uses a single TCP connection, so firing concurrent requests at the same instance ends up serializing them anyway.
Note: If the server closes the connection after its Keep-Alive timeout, cpp-httplib notices before it sends the next request and reconnects. You don't need to handle this in application code.