yhirose
9bfd2ddf1c
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.
2.1 KiB
title, order, status
| title | order | status |
|---|---|---|
| C19. Set a Logger on the Client | 19 | draft |
To log requests sent and responses received by the client, use set_logger(). If you only care about errors, there's a separate set_error_logger().
Log requests and responses
httplib::Client cli("https://api.example.com");
cli.set_logger([](const httplib::Request &req, const httplib::Response &res) {
std::cout << req.method << " " << req.path
<< " -> " << res.status << std::endl;
});
auto res = cli.Get("/users");
The callback you pass to set_logger() fires once for each completed request. You get both the request and the response as arguments — so you can log the method, path, status, headers, body, or whatever else you need.
Catch errors only
When a network-layer error happens (like Error::Connection), set_logger() is not called — there's no response to log. For those cases, use set_error_logger().
cli.set_error_logger([](const httplib::Error &err, const httplib::Request *req) {
std::cerr << "error: " << httplib::to_string(err);
if (req) {
std::cerr << " (" << req->method << " " << req->path << ")";
}
std::cerr << std::endl;
});
The second argument req can be null — it happens when the error comes from setting up the connection, such as the TLS handshake, loading CA certificates, or opening a tunnel through a proxy. Always null-check before dereferencing.
Use both together
A nice pattern is to log successes through one, failures through the other.
cli.set_logger([](const auto &req, const auto &res) {
std::cout << "[ok] " << req.method << " " << req.path
<< " " << res.status << std::endl;
});
cli.set_error_logger([](const auto &err, const auto *req) {
std::cerr << "[ng] " << httplib::to_string(err);
if (req) std::cerr << " " << req->method << " " << req->path;
std::cerr << std::endl;
});
Note: The log callbacks run synchronously on the same thread as the request. Heavy work inside them slows the request down — push it to a background queue if you need to do anything expensive.