Fix README and docs pages that no longer match the code

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.

README-sse.md

@@ -4,7 +4,7 @@ A simple, EventSource-like SSE client for C++11.
 
 ## Features
 
-- **Auto-reconnect**: Automatically reconnects on connection loss
+- **Auto-reconnect**: Automatically reconnects on connection loss or an error status (except 204, 403 and 404)
 - **Last-Event-ID**: Sends last received ID on reconnect for resumption
 - **retry field**: Respects server's reconnect interval
 - **Event types**: Supports custom event types via `on_event()`
@@ -52,7 +52,7 @@ SSEClient(Client &client, const std::string &path, const Headers &headers);
 #### Event Handlers
 
 ```cpp
-// Called for all events (or events without a specific handler)
+// Called for events whose type has no on_event() handler
 sse.on_message([](const SSEMessage &msg) { });
 
 // Called for specific event types
@@ -79,6 +79,8 @@ sse.set_max_reconnect_attempts(10);
 sse.set_headers({{"Authorization", "Bearer new_token"}});
 ```
 
+The client reconnects when it cannot connect or the stream ends. A status other than `200` calls `on_error(Error::Connection)`; a `204`, `403` or `404` then stops the client, and any other status, `401` included, reconnects, so an `on_error` handler can refresh credentials with `set_headers()`. `set_max_reconnect_attempts()` counts reconnect attempts in a row: the count starts over after each successful connection.
+
 An event, or a line still waiting for its end, longer than `CPPHTTPLIB_SSE_MAX_EVENT_LENGTH` (16MB by default, `0` for no limit) ends the connection with `Error::ExceedMaxPayloadSize`, and the client stops rather than reconnect to the same event. The client's `set_payload_max_length()` does not apply to the stream as a whole, which has no end.
 
 #### Control
@@ -193,7 +195,7 @@ sse.start();
 
 ## SSE Protocol
 
-The client parses SSE format according to the [W3C specification](https://html.spec.whatwg.org/multipage/server-sent-events.html):
+The client parses SSE format according to the [WHATWG HTML Living Standard](https://html.spec.whatwg.org/multipage/server-sent-events.html):
 
 ```
 event: custom-type

README-stream.md

@@ -14,7 +14,7 @@ The streaming API allows you to process HTTP response bodies chunk by chunk usin
 
 - **LLM/AI streaming responses** (e.g., ChatGPT, Claude, Ollama)
 - **Server-Sent Events (SSE)**
-- **Large file downloads** with progress tracking
+- **Large file downloads** with progress tracking (mind the [payload size limit](#payload-size-limit))
 - **Reverse proxy implementations**
 
 ## Quick Start
@@ -62,7 +62,7 @@ cpp-httplib provides multiple API layers for different use cases:
 | Use Case | Recommended API |
 |----------|----------------|
 | SSE with auto-reconnect | `SSEClient` (see [README-sse.md](README-sse.md)) |
-| LLM streaming (JSON Lines) | `stream::Get()` |
+| LLM streaming (JSON Lines) | `stream::Post()` or `stream::Get()` |
 | Large file download | `stream::Get()` or `open_stream()` |
 | Reverse proxy | `open_stream()` |
 | Small responses with Keep-Alive | `Client::Get()` |
@@ -106,6 +106,8 @@ if (handle.is_valid()) {
 | `get_read_error()` | `Error` | Get the last read error |
 | `has_read_error()` | `bool` | Check if a read error occurred |
 
+For a chunked response, the trailers are in `response->trailers` once `read()` has reached the end of the body.
+
 ### High-Level API: `stream::Get()` and `stream::Result`
 
 The `httplib.h` header provides a more ergonomic iterator-style API.
@@ -137,6 +139,30 @@ if (result2) {
 }
 ```
 
+#### Helpers
+
+There is a helper for each HTTP method. The arguments in brackets can be left out, and every helper takes a trailing `size_t chunk_size = 8192`, the most bytes one `next()` returns.
+
+| Helper | Arguments |
+|--------|-----------|
+| `stream::Get()` | `(cli, path, [params], [headers], [chunk_size])` |
+| `stream::Head()` | `(cli, path, [params], [headers], [chunk_size])` |
+| `stream::Options()` | `(cli, path, [params], [headers], [chunk_size])` |
+| `stream::Post()` | `(cli, path, [params], [headers], body, content_type, [chunk_size])` |
+| `stream::Put()` | `(cli, path, [params], [headers], body, content_type, [chunk_size])` |
+| `stream::Patch()` | `(cli, path, [params], [headers], body, content_type, [chunk_size])` |
+| `stream::Delete()` | `(cli, path, [params], [headers], [chunk_size])` |
+| `stream::Delete()` | `(cli, path, [params], [headers], body, content_type, [chunk_size])` |
+
+`params` is a `Params`, `headers` a `Headers`, and `body` and `content_type` are `std::string`s.
+
+```cpp
+// POST a JSON body and stream the response in 4KB chunks
+auto result3 = httplib::stream::Post(cli, "/api/generate", headers,
+                                     R"({"prompt": "hello"})",
+                                     "application/json", 4096);
+```
+
 #### stream::Result Members
 
 | Member | Type | Description |
@@ -216,6 +242,7 @@ int main() {
 
 int main() {
     httplib::Client cli("http://example.com");
+    cli.set_payload_max_length(0);  // No limit (the default is 100MB)
     auto result = httplib::stream::Get(cli, "/large-file.zip");
     
     if (!result || result.status() != 200) {
@@ -232,6 +259,12 @@ int main() {
         std::cout << "\rDownloaded: " << (total / 1024) << " KB" << std::flush;
     }
     
+    if (result.has_read_error()) {
+        std::cerr << "\nDownload failed: "
+                  << httplib::to_string(result.read_error()) << "\n";
+        return 1;
+    }
+
     std::cout << "\nComplete!\n";
     return 0;
 }
@@ -316,6 +349,10 @@ while (result.next()) { /* ... */ }
 auto res = cli.Get("/api/data");  // Connection can be reused
 ```
 
+### Payload Size Limit
+
+`open_stream()` and the `stream::` helpers apply the client's `set_payload_max_length()` (100MB by default, `CPPHTTPLIB_PAYLOAD_MAX_LENGTH`) to the body, both as received and after decompression. Past the limit, `read()` and `next()` stop, and the read error is `Error::ExceedMaxPayloadSize`. To download something larger, raise the limit, or call `cli.set_payload_max_length(0)` for no limit.
+
 ## Related
 
 - [Issue #2269](https://github.com/yhirose/cpp-httplib/issues/2269) - Original feature request

README-websocket.md

@@ -6,7 +6,7 @@ A simple, blocking WebSocket implementation for C++11.
 > This is a blocking I/O WebSocket implementation using a thread-per-connection model (plus one heartbeat thread per connection). It is intended for small- to mid-scale workloads; handling large numbers of simultaneous WebSocket connections is outside the design target of this library. If you need high-concurrency WebSocket support with non-blocking/async I/O (e.g., thousands of simultaneous connections), this is not the one that you want.
 
 > [!NOTE]
-> WebSocket extensions (`permessage-deflate` and others defined by RFC 6455) are **not supported**. If a client proposes an extension via `Sec-WebSocket-Extensions`, the server silently declines it — the negotiated connection always runs without extensions.
+> WebSocket extensions (such as `permessage-deflate`, RFC 7692) are **not supported**. If a client proposes an extension via `Sec-WebSocket-Extensions`, the server silently declines it — the negotiated connection always runs without extensions.
 
 ## Features
 
@@ -126,7 +126,7 @@ The `SubProtocolSelector` receives the list of subprotocols proposed by the clie
 Passed to the handler registered with `Server::WebSocket()`. The handler runs in a dedicated thread per connection.
 
 ```cpp
-// Read next message (blocks until received, returns Fail/Text/Binary)
+// Read next message (blocks until received, returns Fail/Text/Binary/Timeout)
 ReadResult read(std::string &msg);
 
 // Send messages
@@ -142,12 +142,20 @@ const Request &request() const;
 
 // Check if the connection is still open
 bool is_open() const;
+
+// Bound how long read() waits before returning Timeout (0 waits forever).
+// Safe to call while another thread is in read().
+void set_read_timeout(time_t sec, time_t usec = 0);
+template <class Rep, class Period>
+void set_read_timeout(const std::chrono::duration<Rep, Period> &duration);
 ```
 
 ### WebSocketClient
 
 ```cpp
-// Constructor - accepts ws:// or wss:// URL
+// Constructor - accepts ws:// or wss:// URL. Any other scheme, or wss:// in a
+// build without SSL, throws std::invalid_argument (with
+// CPPHTTPLIB_NO_EXCEPTIONS, is_valid() returns false instead).
 explicit WebSocketClient(const std::string &scheme_host_port_path,
                          const Headers &headers = {});
 
@@ -163,7 +171,8 @@ struct PemMemory {
 explicit WebSocketClient(const std::string &scheme_host_port_path,
                          const PemMemory &pem, const Headers &headers = {});
 
-// Check if the URL was parsed successfully
+// Check if the URL was parsed successfully. For wss://, also false when the
+// TLS context or the client certificate cannot be loaded.
 bool is_valid() const;
 
 // Connect (performs HTTP upgrade handshake). The returned Result is truthy
@@ -174,6 +183,8 @@ bool is_valid() const;
 //                           or of the proxy's CONNECT reply when error() is
 //                           Error::ProxyConnection
 //   res.headers()           headers of that same response
+//   res.get_header_value(key, def), res.has_header(key)
+//                           look up one of those headers
 //   res.ssl_error()         TLS error detail (wss://, SSL builds only)
 //   res.ssl_backend_error() backend-specific TLS error code (SSL builds only)
 Result connect();
@@ -212,12 +223,26 @@ void set_write_timeout(const std::chrono::duration<Rep, Period> &duration);
 template <class Rep, class Period>
 void set_connection_timeout(const std::chrono::duration<Rep, Period> &duration);
 
+// Heartbeat (see Runtime Ping Interval and Unresponsive-Peer Detection below)
+void set_websocket_ping_interval(time_t sec);
+void set_websocket_max_missed_pongs(int count);
+
+// Socket - the same setters Client has
+void set_tcp_nodelay(bool on);
+void set_address_family(int family);
+void set_ipv6_v6only(bool on);
+void set_socket_options(SocketOptions socket_options);
+void set_interface(const std::string &intf);
+void set_hostname_addr_map(std::map<std::string, std::string> addr_map);
+
 // SSL configuration (wss:// only, SSL builds only)
 void set_ca_cert_path(const std::string &ca_cert_file_path,
                       const std::string &ca_cert_dir_path = std::string());
 void set_ca_cert_store(tls::ca_store_t store);
+void load_ca_cert_store(const char *ca_cert, std::size_t size);
 void enable_server_certificate_verification(bool enabled);
 void enable_server_hostname_verification(bool enabled);
+void enable_system_ca(bool enabled);
 // The same verifiers as SSLClient's, e.g. to pin the server's certificate
 void set_server_certificate_verifier(tls::VerifyCallback verifier);
 void set_session_verifier(
@@ -266,17 +291,21 @@ if (ws.connect()) {
 
 `connect()` returns a `Result` that tells you why a connection attempt failed.
 `error()` distinguishes network problems (`Connection`, `ConnectionTimeout`),
-TLS problems (`SSLConnection`, `SSLServerVerification`,
-`SSLServerHostnameVerification`), and upgrade rejections
-(`WebSocketHandshake`). When the server answered with something other than
-`101 Switching Protocols`, `status()` and `headers()` carry that response:
+proxy problems (`ProxyConnection`), TLS problems (`SSLConnection`,
+`SSLServerVerification`, `SSLServerHostnameVerification`), and upgrade
+rejections (`WebSocketHandshake`). `WebSocketHandshake` covers a status other
+than `101 Switching Protocols` as well as a `101` that fails validation (for
+example a wrong `Sec-WebSocket-Accept`); either way `status()` and `headers()`
+carry the server's response. When a proxy refuses the `CONNECT` request, the
+error is `ProxyConnection` and they carry the proxy's reply instead (e.g. 407):
 
 ```cpp
 auto res = ws.connect();
 if (!res) {
     std::cerr << "connect failed: " << httplib::to_string(res.error()) << std::endl;
     if (res.status() != -1) {
-        // The server responded but refused the upgrade (e.g. 401, 404)
+        // The server refused the upgrade (e.g. 401, 404, or an invalid 101),
+        // or, with ProxyConnection, the proxy refused CONNECT (e.g. 407)
         std::cerr << "HTTP status: " << res.status() << std::endl;
     }
 }

README.md

@@ -71,7 +71,7 @@ cpp-httplib supports multiple TLS backends through an abstraction layer:
 | wolfSSL | `CPPHTTPLIB_WOLFSSL_SUPPORT` | `libwolfssl` | 5.x supported; must build with `--enable-opensslall` |
 
 > [!NOTE]
-> **wolfSSL limitation:** `get_ca_certs()` and `get_ca_names()` only reflect CA certificates loaded via `load_ca_cert_store()`. Certificates loaded through `set_ca_cert_path()` or system certificates (`load_system_certs`) are not enumerable.
+> **wolfSSL limitation:** `get_ca_certs()` and `get_ca_names()` only reflect CA certificates loaded via `load_ca_cert_store()` or `set_ca_cert_store()`. Certificates loaded through `set_ca_cert_path()` or system certificates (`load_system_certs`) are not enumerable.
 >
 > A wolfSSL server that verifies client certificates does not resume TLS sessions: wolfSSL shares its session cache between contexts, so a resumed session could carry a certificate checked against another server's client CA.
 
@@ -108,8 +108,10 @@ cli.enable_server_hostname_verification(false);
 
 When SSL operations fail, cpp-httplib provides detailed error information through `ssl_error()` and `ssl_backend_error()`:
 
-- `ssl_error()` - Returns the TLS-level error as a backend-independent `httplib::tls::ErrorCode` value (e.g., `Fatal`, `CertVerifyFailed`), cast to `int`
-- `ssl_backend_error()` - Returns the backend-specific error code (e.g., `ERR_get_error()` for OpenSSL/wolfSSL, return value for Mbed TLS). With OpenSSL, a certificate verification failure reports the verify result (`X509_V_ERR_*`) here instead
+- `ssl_error()` - Returns the TLS-level error as a backend-independent `httplib::tls::ErrorCode` value (e.g., `Fatal`, `CertVerifyFailed`), cast to `int`. `CertVerifyFailed` comes from Mbed TLS and wolfSSL. OpenSSL checks the chain and the host name after the handshake, so a failure there leaves this `0`
+- `ssl_backend_error()` - Returns the backend-specific error code (e.g., `ERR_get_error()` for OpenSSL/wolfSSL, return value for Mbed TLS). With OpenSSL, a certificate verification failure reports the verify result (`X509_V_ERR_*`) here instead. On Windows, when CryptoAPI verifies the chain, a failure there reports the CryptoAPI error code here
+
+A request that fails after the handshake with `Error::Read` or `Error::Write` also carries the TLS error behind it in both values, such as a TLS 1.3 "certificate required" alert from the server. Both values are reset for each request.
 
 ```c++
 #define CPPHTTPLIB_OPENSSL_SUPPORT  // or CPPHTTPLIB_MBEDTLS_SUPPORT or CPPHTTPLIB_WOLFSSL_SUPPORT
@@ -168,11 +170,13 @@ cli.set_server_certificate_verifier(
         std::cout << "SAN: " << san.value << std::endl;
       }
 
-      // Return true to accept, false to reject
+      // Return false to reject
       return ctx.preverify_ok;
     });
 ```
 
+Returning `false`, or throwing, rejects the certificate. The callback runs alongside the built-in verification, so to accept a certificate that verification rejects, such as a self-signed one, also call `enable_server_certificate_verification(false)`; the callback is then the only check.
+
 ### Mutual TLS (mTLS)
 
 Regular TLS only verifies the server certificate. With mTLS, the client also presents a certificate that the server verifies.
@@ -237,14 +241,18 @@ cpp-httplib automatically integrates with the OS certificate store on macOS and
 | macOS | Loads system certs from Keychain (link `CoreFoundation` and `Security` with `-framework`). Requires Apple Clang; GCC is not supported for this feature. | `CPPHTTPLIB_DISABLE_MACOSX_AUTOMATIC_ROOT_CERTIFICATES` |
 | Windows | Verifies the certificate chain with CryptoAPI (`CertGetCertificateChain` / `CertVerifyCertificateChainPolicy`) instead of the TLS backend. Revocation checking is best-effort: a revoked server certificate is rejected, while one whose revocation status cannot be determined is accepted. Windows fetches missing roots and intermediates on demand. With a custom CA, the TLS backend verifies the chain instead; with `set_server_certificate_verifier()`, both do. | `CPPHTTPLIB_DISABLE_WINDOWS_AUTOMATIC_ROOT_CERTIFICATES_UPDATE` |
 
-On Windows, verification can also be disabled at runtime:
+On Windows, the CryptoAPI check can also be turned off at runtime. The TLS backend then verifies the chain instead, as on other platforms:
 
 ```c++
 cli.enable_windows_certificate_verification(false);
 ```
 
+`WebSocketClient` does not use CryptoAPI; the TLS backend always verifies its chain.
+
 > [!NOTE]
 > When using SSL, it seems impossible to avoid SIGPIPE in all cases, since on some operating systems, SIGPIPE can only be suppressed on a per-message basis, but there is no way to make the OpenSSL library do so for its internal communications. If your program needs to avoid being terminated on SIGPIPE, the only fully general way might be to set up a signal handler for SIGPIPE to handle or ignore it yourself.
+>
+> On systems other than Windows, the `Server` constructor does this already: it calls `signal(SIGPIPE, SIG_IGN)`, which affects the whole process. A program that only uses clients has to do it itself.
 
 ## Server
 
@@ -340,12 +348,12 @@ Patterns work exactly as they do for `Get` and the other methods, so regular exp
 Note the following:
 
 * The method name must be a valid HTTP method token (RFC 9110) and must be registered before `listen()` is called.
-* `GET`, `HEAD`, `POST`, `PUT`, `DELETE`, `CONNECT`, `OPTIONS`, `TRACE`, `PATCH` and `PRI` cannot be registered this way. Use the dedicated methods above instead.
+* `GET`, `HEAD`, `POST`, `PUT`, `DELETE`, `CONNECT`, `OPTIONS`, `TRACE`, `PATCH` and `PRI` cannot be registered this way. Use `Get` (which also serves `HEAD`), `Post`, `Put`, `Delete`, `Options` or `Patch` instead. There are no handlers for `CONNECT`, `TRACE` and `PRI`; such requests get `400 Bad Request`.
 * A rejected registration makes `is_valid()` return `false`, and `listen()` then fails rather than starting a server with a route that would never fire.
 * Static file serving remains `GET`/`HEAD` only, and WebSocket upgrades `GET` only.
 * `Allow` and the WebDAV `DAV:` header are not generated automatically. Register an `Options` handler if clients need them.
 
-The request line itself is read strictly, as RFC 9112 asks: a single space between its three parts, no fragment (`#...`) in the target, and a `Host` header in every HTTP/1.1 request. Anything else gets `400 Bad Request`.
+The request line and the `Host` header are read strictly, as RFC 9112 asks: a single space between the three parts of the request line, `HTTP/1.0` or `HTTP/1.1` as the version, no fragment (`#...`) in the target, and exactly one valid `Host` header (an HTTP/1.0 request may have none). Anything else gets `400 Bad Request`.
 
 ### Bind a socket to multiple interfaces and any available port
 
@@ -403,6 +411,8 @@ svr.set_file_extension_and_mimetype_mapping("cpp", "text/x-c");
 svr.set_file_extension_and_mimetype_mapping("hh", "text/x-h");
 ```
 
+Extensions match regardless of case, so `photo.JPG` is served as `image/jpeg`. A user mapping is looked up by the exact extension first, then by the extension in lowercase.
+
 The following are built-in mappings:
 
 | Extension  |          MIME Type          | Extension  |          MIME Type          |
@@ -453,7 +463,7 @@ cpp-httplib provides separate logging capabilities for access logs and error log
 
 #### Access Logging
 
-Access loggers capture successful HTTP requests and responses:
+Access loggers capture each request and the response written for it, including the error responses the library writes itself, such as `400`, `404`, `413` or `500`:
 
 ```cpp
 svr.set_logger([](const httplib::Request& req, const httplib::Response& res) {
@@ -476,7 +486,7 @@ svr.set_pre_compression_logger([](const httplib::Request& req, const httplib::Re
 });
 ```
 
-The pre-compression logger is only called when compression would be applied. For responses without compression, only the access logger is called.
+The pre-compression logger is only called when the server compresses `res.body` or a static file. It is not called for a response without compression, nor for a chunked content provider, whose body is compressed as it is written; for those, only the access logger is called.
 
 For a static file response (see [Static file compression](#static-file-compression)), `res.body` is empty when the logger runs. The bytes are still on disk at that point, not in memory.
 
@@ -508,7 +518,7 @@ svr.set_error_handler([](const auto& req, auto& res) {
 ```
 
 ### Exception handler
-The exception handler gets called if a user routing handler throws an error.
+The exception handler gets called if a user routing handler throws an error. This covers the pre-routing handler, the file request handler, the pre-request handler, route handlers and content readers. An exception from the post-routing handler, the error handler, the `Expect: 100-continue` handler, a content provider, a logger or a WebSocket handler does not reach it: the connection is dropped, and the error logger receives `Error::UserCallbackException`.
 
 ```cpp
 svr.set_exception_handler([](const auto& req, auto& res, std::exception_ptr ep) {
@@ -584,6 +594,7 @@ Request received
   │     └─ returns Handled → go straight to post_routing_handler
   │
   ├─ file_request_handler         when a static file is served (GET only)
+  │     └─ a mount point answered → go straight to post_routing_handler
   │
   ├─ route matching → req.matched_route is set
   │
@@ -598,7 +609,7 @@ Request received
   On an error status (4xx/5xx) → error_handler
 ```
 
-Use `pre_routing_handler` to reject a request as early as possible, before the route is known. Use `pre_request_handler` for route-specific checks, since `req.matched_route` is available and the body has not been read yet.
+Use `pre_routing_handler` to reject a request as early as possible, before the route is known. Use `pre_request_handler` for route-specific checks, since `req.matched_route` is available and the body has not been read yet. A request that a mount point answers never reaches route matching or `pre_request_handler`, so reject such a request in `pre_routing_handler`.
 
 For a request with `Expect: 100-continue`, the `100 Continue` response is not sent until the body is about to be read. A request rejected before that point (by `pre_routing_handler`, `pre_request_handler`, or because no route matched) gets its final response without `100 Continue`, so the client never sends the body.
 
@@ -724,7 +735,7 @@ svr.Post("/multipart", [&](const Request& req, Response& res) {
 auto safe = httplib::sanitize_filename(file.filename);
 ```
 
-This function strips path separators (`/`, `\`), null bytes, leading/trailing whitespace, and rejects `.` and `..`. Returns an empty string if the filename is unsafe.
+This function keeps only the part after the last `/` or `\`, removes null bytes, and trims leading and trailing spaces and tabs. It returns an empty string if what is left is empty, `.` or `..`.
 
 > [!NOTE]
 > `name` and `filename` are read as quoted-strings (RFC 9110 §5.6.4), where `\"` and `\\` stand for `"` and `\`. Browsers send a backslash as it is, so from a browser, a value with `\\` in it arrives with a single `\`, and one that ends in `\` is not read correctly.
@@ -769,6 +780,11 @@ svr.Post("/content_receiver",
   });
 ```
 
+`content_reader` reads the body once per request; a second call returns `false`.
+When a callback returns `false`, reading stops, `content_reader` returns `false`,
+and `res.status` is set to `400` unless the handler sets another status. The
+rest of the body is left unread, so the connection is closed after the response.
+
 `CPPHTTPLIB_MULTIPART_FORM_DATA_FILE_MAX_COUNT` (default 1024, `0` for no limit)
 caps the number of form-data parts only on the buffered path, where every part
 is accumulated into `req.form`. The content receiver keeps nothing, so the cap
@@ -796,7 +812,7 @@ svr.Get("/stream", [&](const Request &req, Response &res) {
 });
 ```
 
-Write at most `length` bytes per call. Anything past it is not sent, and the response fails.
+Write at most `length` bytes per call. Anything past it is not sent, and the response fails. The response also fails if a call returns `true` without writing anything, or if `sink.done()` is called before the whole content length is written.
 
 Without content length:
 
@@ -817,6 +833,8 @@ svr.Get("/stream", [&](const Request &req, Response &res) {
 });
 ```
 
+Such a body ends where the connection does, so the server sends `Connection: close` and closes the connection after the response. Use `set_chunked_content_provider()` to keep the connection open.
+
 ### Chunked transfer encoding
 
 ```cpp
@@ -914,8 +932,10 @@ The read timeout bounds the request line and headers as a whole, and each read o
 svr.set_payload_max_length(1024 * 1024 * 512); // 512MB
 ```
 
+The default is `CPPHTTPLIB_PAYLOAD_MAX_LENGTH` (100MB), and `0` means no limit. A request with a larger body gets `413 Payload Too Large`.
+
 > [!NOTE]
-> When the request body content type is 'www-form-urlencoded', the actual payload length shouldn't exceed `CPPHTTPLIB_FORM_URL_ENCODED_PAYLOAD_MAX_LENGTH` (`0` for no limit).
+> When the request body content type is `application/x-www-form-urlencoded`, the body must not exceed `CPPHTTPLIB_FORM_URL_ENCODED_PAYLOAD_MAX_LENGTH` (8192 bytes by default, `0` for no limit). A larger one gets `413 Payload Too Large`.
 
 ### Server-Sent Events
 
@@ -925,7 +945,7 @@ Please see [Server example](https://github.com/yhirose/cpp-httplib/blob/master/e
 
 `ThreadPool` is used as the **default** task queue, with dynamic scaling support. By default, it maintains a base thread count of 8 or `std::thread::hardware_concurrency() - 1` (whichever is greater), and can scale up to 4x that count under load. You can change these with `CPPHTTPLIB_THREAD_POOL_COUNT` and `CPPHTTPLIB_THREAD_POOL_MAX_COUNT`.
 
-When all threads are busy and a new task arrives, a temporary thread is spawned (up to the maximum). A dynamic thread exits automatically once it has waited for the idle timeout without receiving a task. The idle timeout defaults to 3 seconds, configurable via `CPPHTTPLIB_THREAD_POOL_IDLE_TIMEOUT`.
+When a new task arrives and the queued tasks outnumber the idle threads, a temporary thread is spawned (up to the maximum). A dynamic thread exits automatically once it has waited for the idle timeout without receiving a task. The idle timeout defaults to 3 seconds, configurable via `CPPHTTPLIB_THREAD_POOL_IDLE_TIMEOUT`.
 
 A connection holds its thread while it is served: between requests up to the keep-alive timeout, through a request body sent slowly but within the read timeout, and for the whole life of a WebSocket. Enough of them leave no thread for anyone else, so in front of untrusted clients, put a reverse proxy that limits connections per client, and reject unwanted WebSocket upgrades in the pre-request handler.
 
@@ -998,7 +1018,7 @@ int main(void)
   httplib::Client cli("localhost", 1234);
 
   if (auto res = cli.Get("/hi")) {
-    if (res->status == StatusCode::OK_200) {
+    if (res->status == httplib::StatusCode::OK_200) {
       std::cout << res->body << std::endl;
     }
   } else {
@@ -1135,7 +1155,7 @@ cli.set_default_headers({
 auto res = cli.Get("/hi");
 ```
 
-A `Content-Length` or `Transfer-Encoding` among these headers is sent in place of the one the library would send, so it has to describe the body as written. Leave both out when passing on the headers of another message, as a proxy does.
+A `Content-Length` among these headers is sent in place of the one the library would send, so it has to match the body as written. A `Transfer-Encoding` is sent in addition to the library's own framing, so leave it out. Leave both out when passing on the headers of another message, as a proxy does.
 
 ### POST
 
@@ -1230,7 +1250,7 @@ cli.set_connection_timeout(0, 300000); // 300 milliseconds
 cli.set_read_timeout(5, 0); // 5 seconds
 cli.set_write_timeout(5, 0); // 5 seconds
 
-// This method works the same as curl's `--max-time` option
+// A deadline for the whole request (see below)
 cli.set_max_timeout(5000); // 5 seconds
 
 // std::chrono is also supported
@@ -1240,6 +1260,8 @@ cli.set_write_timeout(std::chrono::seconds(5));
 cli.set_max_timeout(std::chrono::seconds(5));
 ```
 
+`set_max_timeout()` is similar to curl's `--max-time` option, but the deadline only shortens the waits for reading the response. Connecting and writing are bounded by the connection and write timeouts.
+
 ### Set maximum payload length for reading a response body
 
 ```c++
@@ -1264,8 +1286,8 @@ std::string body;
 auto res = cli.Get(
   "/stream", Headers(),
   [&](const Response &response) {
-    EXPECT_EQ(StatusCode::OK_200, response.status);
-    return true; // return 'false' if you want to cancel the request.
+    // return 'false' if you want to cancel the request.
+    return response.status == StatusCode::OK_200;
   },
   [&](const char *data, size_t data_length) {
     body.append(data, data_length);
@@ -1287,6 +1309,8 @@ auto res = cli.Post(
   "text/plain");
 ```
 
+As on the server, write at most `length` bytes per call. The request fails with `Error::Write` if a call writes more, returns `true` without writing anything, or calls `sink.done()` before the whole content length is written.
+
 ### Chunked transfer encoding
 
 ```cpp
@@ -1366,6 +1390,10 @@ Hostname matching is case-insensitive with a dot-boundary rule. See the
 [NO_PROXY cookbook](https://yhirose.github.io/cpp-httplib/en/cookbook/c16-proxy)
 for details and for reading the variable from the environment.
 
+`set_proxy()`, `set_proxy_basic_auth()`, `set_proxy_bearer_token_auth()`,
+`set_proxy_digest_auth()` and `set_no_proxy()` are also available on
+`httplib::ws::WebSocketClient`.
+
 ### Range
 
 ```cpp
@@ -1411,14 +1439,16 @@ res = cli.Get("/");
 res->status; // 200
 ```
 
-A URL with userinfo (`http://user:pass@host/`) is not supported, neither for a `Client` nor in a `Location`; use `set_basic_auth()` for the credentials.
+A URL with userinfo (`http://user:pass@host/`) is not supported, neither for a `Client` nor in a `Location`; use `set_basic_auth()` for the credentials. A `Client` constructed from a URL it cannot use, such as one with userinfo, a backslash in the authority or an invalid port, is not valid: `is_valid()` returns `false`, and every request fails with `Error::Connection`.
 
-On a redirect to another host, `Authorization`, `Cookie` and `Proxy-Authorization` are dropped along with the credentials set with `set_basic_auth()`, `set_bearer_token_auth()` and `set_digest_auth()`, and the client certificate is not presented. Other headers, the default ones included, go along (RFC 9110 §15.4), and so do the timeouts, the payload limit and the TLS verification settings.
+On a redirect to another origin (a different scheme, host or port), `Authorization`, `Cookie` and `Proxy-Authorization` are dropped along with the credentials set with `set_basic_auth()`, `set_bearer_token_auth()` and `set_digest_auth()`, and the client certificate is not presented. Other headers, the default ones included, go along (RFC 9110 §15.4), and so do the timeouts, the payload limit and the TLS verification settings. A `303` that turns a request into a `GET` drops its headers and body; only on the same origin are the default headers sent again.
+
+Up to `CPPHTTPLIB_REDIRECT_MAX_COUNT` (20 by default) redirects are followed for a request; one more fails it with `Error::ExceedRedirectCount`. Interim `1xx` responses before the final response are skipped, up to `CPPHTTPLIB_INTERIM_RESPONSE_MAX_COUNT` (100 by default); one more fails the request with `Error::Read`.
 
 ### Use a specific network interface
 
 > [!NOTE]
-> This feature is not available on Windows, yet.
+> This feature is not available on Windows, Android, AIX and z/OS. The setting is ignored there.
 
 ```cpp
 cli.set_interface("eth0"); // Interface name, IP address or host name
@@ -1467,13 +1497,15 @@ auto res = cli.Get("/path with spaces/file.txt"); // Automatically encodes space
 
 // Disable automatic path encoding
 cli.set_path_encode(false);
-auto res = cli.Get("/already%20encoded/path"); // Use pre-encoded paths
+res = cli.Get("/already%20encoded/path"); // Use pre-encoded paths
 ```
 
 - `set_path_encode(bool on)` - Controls automatic encoding of special characters in URL paths
   - `true` (default): Automatically encodes spaces, plus signs, newlines, and other special characters
   - `false`: Sends paths as-is without encoding (useful for pre-encoded URLs)
 
+A fragment (`#...`) in the path is never sent, whatever the setting.
+
 ### Performance Note for Local Connections
 
 > [!WARNING]
@@ -1518,7 +1550,7 @@ auto second = req.get_header_value("Accept-Encoding", "", 1); // "br"
 
 ## Payload Limit
 
-The maximum payload body size is limited to 100MB by default for both server and client. You can change it with `set_payload_max_length()` or by defining `CPPHTTPLIB_PAYLOAD_MAX_LENGTH` at compile time. Setting it to `0` disables the limit entirely. On the client, a request made with a content receiver is not limited unless you call `set_payload_max_length()` yourself, so that a large download can be streamed without raising the limit first.
+The maximum payload body size is limited to 100MB by default for both server and client. You can change it with `set_payload_max_length()` or by defining `CPPHTTPLIB_PAYLOAD_MAX_LENGTH` at compile time. Setting it to `0` disables the limit entirely. On the client, a request made with a content receiver is not limited unless you call `set_payload_max_length()` yourself, so that a large download can be streamed without raising the limit first. The [Stream API](#stream-api) is limited either way.
 
 ## Compression
 
@@ -1592,14 +1624,14 @@ Please see https://github.com/facebook/zstd for more detail.
 
 ### Default `Accept-Encoding` value
 
-The default `Accept-Encoding` value contains all possible compression types. So, the following two examples are same.
+The default `Accept-Encoding` value lists the compression types the library is built with. It is not added to a request made with a content receiver. So, with Brotli, zlib and Zstd support all enabled, the following two examples are the same.
 
 ```c++
 res = cli.Get("/resource/foo");
 res = cli.Get("/resource/foo", httplib::Headers{{"Accept-Encoding", "br, gzip, deflate, zstd"}});
 ```
 
-If we don't want a response without compression, we have to set `Accept-Encoding` to an empty string. This behavior is similar to curl.
+If we want a response without compression, we have to set `Accept-Encoding` to an empty string. This behavior is similar to curl.
 
 ```c++
 res = cli.Get("/resource/foo", httplib::Headers{{"Accept-Encoding", ""}});
@@ -1612,7 +1644,7 @@ cli.set_compress(true);
 res = cli.Post("/resource/foo", "...", "text/plain");
 ```
 
-### Compress response body on client
+### Keep response body compressed on client
 
 ```c++
 cli.set_decompress(false);
@@ -1637,7 +1669,7 @@ cli.set_address_family(AF_UNIX);
 
 "my-socket.sock" can be a relative path or an absolute path. Your application must have the appropriate permissions for the path. You can also use an abstract socket address on Linux. To use an abstract socket address, prepend a null byte ('\x00') to the path.
 
-This library automatically sets the Host header to "localhost" for Unix socket connections, similar to curl's behavior:
+This library automatically sets the Host header to "localhost" for Unix socket connections, similar to curl's behavior.
 
 
 URI Encoding/Decoding Utilities
@@ -1660,8 +1692,8 @@ std::string decoded_component = httplib::decode_uri_component(encoded_component)
 ### Functions
 
 - `encode_uri(const std::string &value)` - Encodes a full URI, preserving reserved characters like `://`, `?`, `&`, `=`
-- `decode_uri(const std::string &value)` - Decodes a URI-encoded string
-- `encode_uri_component(const std::string &value)` - Encodes a URI component (query parameter, path segment), encoding all reserved characters
+- `decode_uri(const std::string &value)` - Decodes a URI-encoded string, but leaves escapes of the reserved characters that `encode_uri()` preserves (e.g. `%2F`, `%3F`) as they are, like JavaScript's `decodeURI()`
+- `encode_uri_component(const std::string &value)` - Encodes a URI component (query parameter, path segment), encoding all reserved characters except `!`, `*`, `'`, `(` and `)`, like JavaScript's `encodeURIComponent()`
 - `decode_uri_component(const std::string &value)` - Decodes a URI component
 
 Use `encode_uri()` for full URLs and `encode_uri_component()` for individual query parameters or path segments.
@@ -1690,6 +1722,8 @@ if (result2) {
 
 All HTTP methods are supported: `stream::Get`, `Post`, `Put`, `Patch`, `Delete`, `Head`, `Options`.
 
+Unlike a content receiver, the Stream API is bounded by the client's `set_payload_max_length()` (100MB by default). Reading past it stops with `read_error() == Error::ExceedMaxPayloadSize`.
+
 See [README-stream.md](README-stream.md) for more details.
 
 ## SSE Client

docs-src/pages/en/cookbook/c03-default-headers.md

@@ -50,6 +50,6 @@ httplib::Headers headers = {
 auto res = cli.Get("/users", headers);
 ```
 
-Per-request headers are **added** on top of the defaults. Both are sent to the server.
+Per-request headers are **added** on top of the defaults, and both are sent to the server. If a per-request header has the same name as a default one, only the per-request one is sent.
 
 > For details on Bearer token auth, see [C06. Call an API with a Bearer token](../c06-bearer-token).

docs-src/pages/en/cookbook/c04-follow-location.md

@@ -33,6 +33,8 @@ auto res = cli.Get("/");
 
 Many sites redirect HTTP traffic to HTTPS. With `set_follow_location(true)` on, this case is handled transparently — the client follows redirects even when the scheme or host changes.
 
+When a redirect goes to another origin (a different scheme, host, or port), the client drops the `Authorization`, `Cookie`, and `Proxy-Authorization` headers, along with the credentials set with `set_basic_auth()` and the like, and doesn't present the client certificate. Other headers, default ones included, go along, and so do the timeouts, the payload limit, and the TLS verification settings.
+
 > **Warning:** To follow redirects to HTTPS, you need to build cpp-httplib with OpenSSL (or another TLS backend). Without TLS support, redirects to HTTPS will fail.
 
 > **Note:** Following redirects adds to the total request time. See [C12. Set timeouts](../c12-timeouts) for timeout configuration.

docs-src/pages/en/cookbook/c08-post-file-body.md

@@ -12,7 +12,7 @@ Sometimes you want to send a file's contents as the request body directly — no
 httplib::Client cli("https://storage.example.com");
 
 auto [size, provider] = httplib::make_file_body("backup.tar.gz");
-if (size == 0) {
+if (!provider) {
   std::cerr << "Failed to open file" << std::endl;
   return 1;
 }
@@ -27,7 +27,7 @@ The `ContentProvider` reads the file in chunks, so even huge files never sit ful
 
 ## When the file can't be opened
 
-If the file can't be opened, `make_file_body()` returns `size` as `0` and `provider` as an empty function object. Sending that would produce garbage — always check `size` first.
+If the file can't be opened, `make_file_body()` returns `size` as `0` and `provider` as an empty function object. Sending that would upload an empty body — always check `provider` first. Checking `size` won't do: an empty file also gives `0`, with a working `provider`.
 
 > **Warning:** `make_file_body()` needs to fix the Content-Length up front, so it reads the file size ahead of time. If the file size might change mid-upload, this API isn't the right fit.
 

docs-src/pages/en/cookbook/c12-timeouts.md

@@ -12,6 +12,8 @@ The client has three kinds of timeouts, each set independently.
 | Read | `set_read_timeout` | 300s | Time to wait for a single `recv` when receiving the response |
 | Write | `set_write_timeout` | 5s | Time to wait for a single `send` when sending the request |
 
+Over HTTPS, the connection timeout also bounds the whole TLS handshake. A handshake that doesn't finish in time fails with `Error::SSLConnection`.
+
 ## Basic usage
 
 ```cpp

docs-src/pages/en/cookbook/c13-max-timeout.md

@@ -4,7 +4,7 @@ order: 13
 status: "draft"
 ---
 
-The three timeouts from [C12. Set timeouts](../c12-timeouts) all apply to a single `send` or `recv` call. To cap the total time a request can take, use `set_max_timeout()`.
+The three timeouts from [C12. Set timeouts](../c12-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
 

docs-src/pages/en/cookbook/c15-compression.md

@@ -29,7 +29,7 @@ std::string big_payload = build_payload();
 auto res = cli.Post("/api/data", big_payload, "application/json");
 ```
 
-With `set_compress(true)`, the body of POST or PUT requests is compressed before sending. The encoding is the first one enabled in your build, in the order Brotli, gzip, Zstd. The server needs to handle compressed bodies too.
+With `set_compress(true)`, the body of POST, PUT, or PATCH requests is compressed before sending. The encoding is the first one enabled in your build, in the order Brotli, gzip, Zstd. The server needs to handle compressed bodies too.
 
 ## Decompress the response
 

docs-src/pages/en/cookbook/c16-proxy.md

@@ -17,6 +17,8 @@ auto res = cli.Get("/users");
 
 The request goes through the proxy. For HTTPS, the client uses the CONNECT method to tunnel through — no extra setup required.
 
+If the proxy refuses the tunnel, the request fails with `Error::ProxyConnection`. The exception is a 407: it comes back as the response, so `res` is truthy and `res->status` is 407, while `res.error()` still returns `Error::ProxyConnection`.
+
 ## Proxy authentication
 
 If the proxy itself requires authentication, use `set_proxy_basic_auth()` or `set_proxy_bearer_token_auth()`.

docs-src/pages/en/cookbook/c17-error-codes.md

@@ -4,7 +4,7 @@ order: 17
 status: "draft"
 ---
 
-`cli.Get()`, `cli.Post()`, and friends return a `Result`. When the request fails — can't reach the server, times out, etc. — the result is "falsy". To get the specific reason, use `Result::error()`.
+`cli.Get()`, `cli.Post()`, and friends return a `Result`. When the request fails — can't reach the server, times out, etc. — the result is "falsy", with one exception noted in the table below. To get the specific reason, use `Result::error()`.
 
 ## Basic check
 
@@ -27,14 +27,15 @@ Use `if (res)` to check success. On failure, `res.error()` returns a `httplib::E
 
 | Value | Meaning |
 | --- | --- |
-| `Error::Connection` | Couldn't connect to the server |
+| `Error::Connection` | Couldn't connect to the server, or the `Client` was built from a URL it can't use (userinfo or a backslash in the authority, a bad port). In the latter case `cli.is_valid()` is `false` |
 | `Error::ConnectionTimeout` | Connection timeout (`set_connection_timeout`) |
 | `Error::Read` / `Error::Write` | Error during send or receive. A timeout from `set_read_timeout` or `set_max_timeout` is also reported as `Error::Read` |
 | `Error::Timeout` | A body read timed out in `stream::Get()` or `SSEClient` |
 | `Error::ExceedRedirectCount` | Too many redirects |
 | `Error::SSLConnection` | TLS handshake failed |
 | `Error::SSLServerVerification` | Server certificate verification failed |
-| `Error::Canceled` | A progress callback returned `false` |
+| `Error::ProxyConnection` | The proxy refused the CONNECT tunnel. A 407 is the exception: `res` is truthy with `res->status == 407`, and `res.error()` is still `Error::ProxyConnection` |
+| `Error::Canceled` | A progress callback, a `ContentReceiver`, a `ResponseHandler`, or an upload content provider returned `false` |
 
 ## Network errors vs. HTTP errors
 

docs-src/pages/en/cookbook/c18-ssl-errors.md

@@ -17,14 +17,17 @@ if (!res) {
   std::cerr << "error: " << httplib::to_string(err) << std::endl;
 
   if (err == httplib::Error::SSLConnection ||
-      err == httplib::Error::SSLServerVerification) {
+      err == httplib::Error::SSLServerVerification ||
+      err == httplib::Error::Read || err == httplib::Error::Write) {
     std::cerr << "ssl_error: " << res.ssl_error() << std::endl;
     std::cerr << "ssl_backend_error: " << res.ssl_backend_error() << std::endl;
   }
 }
 ```
 
-`ssl_error()` is a backend-independent TLS error category: an `httplib::tls::ErrorCode` cast to `int`. `ssl_backend_error()` gives you the backend's own error value. With OpenSSL that is `ERR_get_error()` when the handshake failed, and the verify result (`X509_V_ERR_*`) when certificate verification failed.
+`ssl_error()` is a backend-independent TLS error category: an `httplib::tls::ErrorCode` cast to `int`. `ssl_backend_error()` gives you the backend's own error value. With OpenSSL that is `ERR_get_error()` when the handshake or a later read or write failed, and the verify result (`X509_V_ERR_*`) when certificate verification failed.
+
+A request that fails after the handshake reports `Error::Read` or `Error::Write`. Even then, `ssl_error()` and `ssl_backend_error()` carry the TLS error behind it. For example, if the server requires a client certificate you didn't send, OpenSSL's error reads "tlsv13 alert certificate required". Both values are reset for each request and are `0` when no TLS error was involved.
 
 ## Format OpenSSL errors as strings
 

docs-src/pages/en/cookbook/c19-client-logger.md

@@ -35,7 +35,7 @@ cli.set_error_logger([](const httplib::Error &err, const httplib::Request *req)
 });
 ```
 
-The second argument `req` can be null — it happens when the failure occurred before the request was built. Always null-check before dereferencing.
+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
 

docs-src/pages/en/cookbook/e04-sse-client.md

@@ -55,7 +55,9 @@ sse.on_error([](httplib::Error err) {
 });
 ```
 
-Hook into connection open and error events. Even when the error handler fires, `SSEClient` keeps trying to reconnect in the background. The exceptions are a 204, 403, or 404 response, after which it stops.
+Hook into connection open and error events. Even when the error handler fires, `SSEClient` keeps trying to reconnect in the background. It stops after a 204, 403, or 404 response, or once the attempts set with `set_max_reconnect_attempts()` run out.
+
+It also stops when an event, or a line still waiting for its end, grows past `CPPHTTPLIB_SSE_MAX_EVENT_LENGTH` (16MB by default, 0 for no limit). The error handler then gets `Error::ExceedMaxPayloadSize`. The client's `set_payload_max_length()` doesn't apply to the stream as a whole, since an event stream has no end.
 
 ## Run asynchronously
 
@@ -88,6 +90,8 @@ If the server sends a `retry:` field, that takes precedence.
 
 `SSEClient` tracks the `id` of each received event internally and sends it back as `Last-Event-ID` on reconnect. As long as the server sends events with `id:`, this all works automatically.
 
+An empty `id:` clears the stored id. An `id:` that can't be sent as a header value (one with NUL or other control characters, or with leading or trailing whitespace) is ignored, and the previous id stays.
+
 ```cpp
 std::cout << "last id: " << sse.last_event_id() << std::endl;
 ```

docs-src/pages/en/cookbook/s03-path-params.md

@@ -44,6 +44,8 @@ svr.Get(R"(/users/(\d+))", [](const httplib::Request &req, httplib::Response &re
 
 Parentheses in the pattern become captures in `req.matches`. `req.matches[0]` is the full match; `req.matches[1]` onward are the captures.
 
+A regex route isn't applied to a path longer than `CPPHTTPLIB_REGEX_ROUTE_PATH_MAX_LENGTH` (256 by default); such a path is treated as no match. This keeps `std::regex` from overflowing the stack on long input. If your routes need longer paths, define the macro with a larger value.
+
 ## Which to use
 
 - For plain IDs or slugs, `:name` is enough — readable, and the shape is obvious

docs-src/pages/en/cookbook/s04-static-files.md

@@ -10,12 +10,19 @@ To serve static files like HTML, CSS, and images, use `set_mount_point()`. Just
 
 ```cpp
 httplib::Server svr;
-svr.set_mount_point("/", "./public");
+if (!svr.set_mount_point("/", "./public")) {
+  // ./public doesn't exist
+  return 1;
+}
 svr.listen("0.0.0.0", 8080);
 ```
 
+`set_mount_point()` returns `false` when the directory doesn't exist, so check the return value.
+
 `./public/index.html` is now reachable at `http://localhost:8080/index.html`, and `./public/css/style.css` at `http://localhost:8080/css/style.css`. The directory layout maps directly to URLs.
 
+A request for a directory serves its `index.html`, and one without the trailing slash (`/docs`) is redirected (301) to `/docs/`. A symlink that resolves outside the mounted directory gets a 403.
+
 ## Multiple mount points
 
 You can register more than one mount point.

docs-src/pages/en/cookbook/s07-multipart-reader.md

@@ -48,22 +48,30 @@ svr.Post("/upload",
      const httplib::ContentReader &content_reader) {
     std::ofstream ofs;
 
-    content_reader(
+    auto ok = content_reader(
       [&](const httplib::FormData &file) {
-        if (!file.filename.empty()) {
-          ofs.open("uploads/" + file.filename, std::ios::binary);
-        }
-        return static_cast<bool>(ofs);
+        if (ofs.is_open()) { ofs.close(); }         // done with the previous file
+        if (file.filename.empty()) { return true; } // a plain field, skip it
+
+        auto name = httplib::sanitize_filename(file.filename);
+        if (name.empty()) { return false; }         // reject an unsafe name
+
+        ofs.open("uploads/" + name, std::ios::binary);
+        return ofs.is_open();
       },
       [&](const char *data, size_t len) {
+        if (!ofs.is_open()) { return true; }        // not part of a file
         ofs.write(data, len);
         return static_cast<bool>(ofs);
       });
 
+    if (!ok) { return; } // the status is already set
     res.set_content("uploaded", "text/plain");
   });
 ```
 
+The header callback runs at the start of every part, so it closes the previous file before opening the next one. `file.filename` is whatever the client sent, so always pass it through `httplib::sanitize_filename()`. An empty result means the name is unsafe.
+
 Only a small chunk sits in memory at any moment, so gigabyte-scale files are no problem.
 
 ## Count the parts yourself

docs-src/pages/en/cookbook/s09-pre-routing.md

@@ -16,7 +16,7 @@ svr.set_pre_routing_handler(
   });
 ```
 
-The pre-routing handler runs **before routing**. It catches every request — including ones that don't match any handler.
+The pre-routing handler runs **before routing**. It catches every request — including ones that don't match any handler. The exception is a request rejected while its request line and headers are parsed (400 for a malformed request, 414 for an overlong URI, 416 for a malformed `Range`); the server answers those before this handler runs.
 
 The `HandlerResponse` return value is key:
 

docs-src/pages/en/cookbook/s10-post-routing.md

@@ -38,6 +38,8 @@ svr.Options("/.*", [](const auto &req, auto &res) {
 });
 ```
 
+`/.*` is a regex route, so it isn't applied to paths longer than `CPPHTTPLIB_REGEX_ROUTE_PATH_MAX_LENGTH` (256 by default). If your paths can be longer, handle `OPTIONS` in the pre-routing handler instead.
+
 ## Bundle your security headers
 
 Manage browser security headers in one spot.

docs-src/pages/en/cookbook/s11-pre-request.md

@@ -17,6 +17,8 @@ In a pre-request handler, `req.matched_route` holds the **pattern string** that
 
 Because the body has not been read when the pre-request handler runs, you can reject a request — for example on a failed auth check — without consuming a (potentially large) request body. Note that this also means `req.body` and form fields parsed from the body are not available here; inspect headers, the path, query parameters, or `req.matched_route` instead.
 
+The pre-request handler runs only for requests that match a route. Files served by `set_mount_point()` are answered before route matching, so guard static files in the pre-routing handler.
+
 ## Switch auth per route
 
 ```cpp
@@ -39,6 +41,8 @@ svr.set_pre_request_handler(
 
 The pre-request handler also runs for routes registered with `svr.WebSocket()`. It is called before the `101 Switching Protocols` response, so returning `Handled` sends your HTTP response (such as a 403) and the connection is never upgraded.
 
+The server accepts a handshake from any `Origin`. A browser sends its cookies even with a handshake that another site starts, so if cookies authenticate the connection, also check `req.get_header_value("Origin")` against your own origins here.
+
 ## Return values
 
 Same as pre-routing — return `HandlerResponse`.

docs-src/pages/en/cookbook/s13-error-handler.md

@@ -4,7 +4,7 @@ order: 32
 status: "draft"
 ---
 
-To customize the response for 4xx or 5xx errors, use `set_error_handler()`. You can replace the plain default error page with your own HTML or JSON.
+To customize the response for 4xx or 5xx errors, use `set_error_handler()`. By default, an error response has an empty body; an error handler lets you fill it with your own HTML or JSON.
 
 ## Basic usage
 

docs-src/pages/en/cookbook/s15-server-logger.md

@@ -4,7 +4,7 @@ order: 34
 status: "draft"
 ---
 
-To log the requests the server receives and the responses it returns, use `Server::set_logger()`. The callback fires once per completed request, making it the foundation for access logs and metrics collection.
+To log the requests the server receives and the responses it returns, use `Server::set_logger()`. The callback fires once per request, right before the response is written, making it the foundation for access logs and metrics collection.
 
 ## Basic usage
 
@@ -18,6 +18,8 @@ svr.set_logger([](const httplib::Request &req, const httplib::Response &res) {
 
 The log callback receives both the `Request` and the `Response`. You can grab the method, path, status, client IP, headers, body — whatever you need.
 
+`req.path` is percent-decoded, so it may contain control characters such as CR/LF. Escape it before writing it to a log file, or a crafted request can forge log lines.
+
 ## Access-log style format
 
 Here's an Apache/Nginx-ish access log format.
@@ -38,6 +40,8 @@ svr.set_logger([](const auto &req, const auto &res) {
 });
 ```
 
+For a response sent through a content provider, such as a file served from a mount point, `res.body` is empty here, so the size shows `0B`.
+
 ## Measure request time
 
 To include request duration in the log, stash a start timestamp in `res.user_data` from a pre-routing handler, then subtract in the logger.
@@ -59,6 +63,8 @@ svr.set_logger([](const httplib::Request &req, const httplib::Response &res) {
 });
 ```
 
+Since the logger runs before the response is written, the time doesn't include sending the body.
+
 For more on `user_data`, see [S12. Pass data between handlers with `res.user_data`](../s12-user-data).
 
-> **Note:** The logger runs synchronously on the same thread as request processing. Heavy work inside it hurts throughput — push it to a queue and process asynchronously if you need anything expensive.
+> **Note:** The logger runs synchronously on the same thread as request processing, and all logger calls on a server share one lock. Heavy work inside it hurts throughput — push it to a queue and process asynchronously if you need anything expensive.

docs-src/pages/en/cookbook/s19-graceful-shutdown.md

@@ -55,3 +55,5 @@ int main() {
 When you call `stop()`, new connections are refused, but handlers that are already running are **allowed to finish**. A response still being sent by a content provider (a streaming response, for example) is cut short, though. Once all workers drain, `listen()` returns. That's what makes it graceful.
 
 > **Warning:** There's a wait between calling `stop()` and `listen()` returning — it's the time in-flight requests take to finish. To enforce a timeout, you'll need to add your own shutdown timer in application code.
+
+> **Note:** `stop()` doesn't interrupt WebSocket handlers. A handler looping on `read()` keeps running as long as its peer stays connected, and `listen()` doesn't return until it ends. Keep track of open WebSocket connections and `close()` them on shutdown, e.g. with `CloseStatus::GoingAway`.

docs-src/pages/en/cookbook/s20-keep-alive.md

@@ -52,6 +52,6 @@ Set `set_keep_alive_max_count(1)` and every request gets its own connection. Mos
 
 ## Relationship with the thread pool
 
-A Keep-Alive connection holds a worker thread for its entire lifetime. If `connections × concurrent requests` exceeds the thread pool size, new requests wait. For thread counts, see [S21. Configure the thread pool](../s21-thread-pool).
+A Keep-Alive connection holds a worker thread for its entire lifetime. The pool adds threads under load, up to its maximum thread count (4× the base count by default). If open connections outnumber that maximum, new connections wait in the queue until one closes. For thread counts, see [S21. Configure the thread pool](../s21-thread-pool).
 
 > **Note:** For the client side, see [C14. Understand connection reuse and Keep-Alive behavior](../c14-keep-alive). Even when the server closes the connection on timeout, the client reconnects automatically.

docs-src/pages/en/cookbook/s21-thread-pool.md

@@ -66,4 +66,4 @@ You can set the defaults with macros if you want compile-time configuration.
 #include <httplib.h>
 ```
 
-> **Note:** A WebSocket connection holds a worker thread for its entire lifetime. For lots of simultaneous WebSocket connections, enable dynamic scaling (e.g. `ThreadPool(8, 64)`).
+> **Note:** A WebSocket connection holds a worker thread for its entire lifetime. For lots of simultaneous WebSocket connections, raise the maximum thread count (e.g. `ThreadPool(8, 64)`).

docs-src/pages/en/cookbook/t01-tls-backends.md

@@ -46,4 +46,4 @@ Certificate verification control, standing up an SSLServer, reading the peer cer
 - [T03. Start an SSL/TLS server](../t03-ssl-server)
 - [T05. Access the peer certificate on the server](../t05-peer-cert)
 
-> **Note:** On macOS with an OpenSSL-family backend, cpp-httplib automatically loads root certificates from the system keychain (via `CPPHTTPLIB_USE_CERTS_FROM_MACOSX_KEYCHAIN`, on by default). To disable this, define `CPPHTTPLIB_DISABLE_MACOSX_AUTOMATIC_ROOT_CERTIFICATES`.
+> **Note:** On macOS, with any of the three backends, cpp-httplib automatically loads root certificates from the system keychain (via `CPPHTTPLIB_USE_CERTS_FROM_MACOSX_KEYCHAIN`, on by default). To disable this, define `CPPHTTPLIB_DISABLE_MACOSX_AUTOMATIC_ROOT_CERTIFICATES`.

docs-src/pages/en/cookbook/t02-cert-verification.md

@@ -19,6 +19,8 @@ auto res = cli.Get("/");
 
 The first argument is the CA certificate file; the second is an optional CA directory. With the OpenSSL backend, you can also pass an `X509_STORE*` directly via `set_ca_cert_store()`.
 
+Once you set a custom CA, the client trusts only that CA and skips the OS store. To trust both, also call `cli.enable_system_ca(true)`. CA certificates are loaded once, on the client's first connection, so make these settings before the first request.
+
 ## Disable certificate verification (not recommended)
 
 For development servers or self-signed certificates, you can skip verification entirely.
@@ -46,7 +48,7 @@ The certificate itself is still validated, so this is safer than fully disabling
 
 ## Use the OS cert store as-is
 
-On most Linux distributions, root certificates live in a single file like `/etc/ssl/certs/ca-certificates.crt`. cpp-httplib reads the OS default store at startup, so for most servers you don't need to configure anything.
+On most Linux distributions, root certificates live in a single file like `/etc/ssl/certs/ca-certificates.crt`. cpp-httplib loads the OS default store on the client's first connection, so for most servers you don't need to configure anything.
 
 > The same APIs work on the mbedTLS and wolfSSL backends. For choosing between backends, see [T01. Choosing between OpenSSL, mbedTLS, and wolfSSL](../t01-tls-backends).
 

docs-src/pages/en/cookbook/t05-peer-cert.md

@@ -44,7 +44,7 @@ for (const auto &san : sans) {
 }
 ```
 
-There's also a helper to check if a hostname is covered by the SAN list:
+There's also a helper that checks whether the certificate covers a hostname. It follows the rules of TLS hostname verification: an IP address is matched against the IP address SANs, a name against the DNS SANs, and the CN is used only when there's no DNS SAN.
 
 ```cpp
 if (cert.check_hostname("alice.corp.example.com")) {
@@ -81,7 +81,7 @@ Combined with a pre-request handler, you can keep all authorization logic in one
 
 ## SNI (Server Name Indication)
 
-cpp-httplib handles SNI automatically. If one server hosts multiple domains, SNI is used under the hood — but normally handlers don't need to care.
+Clients send SNI automatically. On the server, `req.sni()` returns the name the client asked for. `SSLServer` presents the same certificate whatever that name is, though, so to host several domains on one server, use a certificate that covers all of them. To choose a certificate per name, hook into the TLS backend yourself — with OpenSSL, for example, set a servername callback through the `SSLServer` constructor that takes a context setup callback.
 
 > **Warning:** `req.peer_cert()` only returns a meaningful value when mTLS is enabled and the client actually presented a certificate. For plain TLS, you get an empty `PeerCert`. Always do the `bool` check before using it.
 

docs-src/pages/en/cookbook/w01-websocket-echo.md

@@ -21,7 +21,12 @@ int main() {
       if (result == httplib::ws::ReadResult::Fail) {
         break;
       }
-      ws.send(msg); // echo back what we received
+      // echo back what we received, in the same frame type
+      if (result == httplib::ws::ReadResult::Binary) {
+        ws.send(msg.data(), msg.size());
+      } else {
+        ws.send(msg);
+      }
     }
   });
 
@@ -29,7 +34,7 @@ int main() {
 }
 ```
 
-Register a WebSocket handler with `svr.WebSocket()`. By the time the handler runs, the WebSocket handshake is already complete. Inside the loop, just `ws.read()` and `ws.send()` to get a working echo.
+Register a WebSocket handler with `svr.WebSocket()`. By the time the handler runs, the WebSocket handshake is already complete. Inside the loop, just `ws.read()` and `ws.send()` to get a working echo. A binary message goes back through the `data()` + `size()` overload so it stays binary (more on that below).
 
 The `read()` return value is a `ReadResult` enum:
 
@@ -76,7 +81,7 @@ The `std::string` overload sends as **text**; the `const char*` + size overload
 
 ## Thread pool implications
 
-A WebSocket handler holds its worker thread for the entire life of the connection — one connection per thread. For many concurrent clients, configure a dynamic thread pool.
+A WebSocket handler holds its worker thread for the entire life of the connection — one connection per thread. The default pool already grows under load, up to 4× its base thread count. For many concurrent clients, raise that maximum.
 
 ```cpp
 svr.new_task_queue = [] {

docs-src/pages/en/cookbook/w02-websocket-ping.md

@@ -43,7 +43,7 @@ The default interval is set by the build-time macro `CPPHTTPLIB_WEBSOCKET_PING_I
 
 ## What about Pong?
 
-The WebSocket protocol requires that Ping frames are answered with Pong frames. cpp-httplib responds to Pings automatically — you don't need to think about it in application code.
+The WebSocket protocol requires that Ping frames are answered with Pong frames. cpp-httplib answers Pings automatically inside `read()` — as long as your code keeps calling `read()`, you don't need to think about it.
 
 ## Picking an interval
 

docs-src/pages/en/cookbook/w03-websocket-close.md

@@ -67,7 +67,7 @@ To notify in-flight clients that the server is going down, use `GoingAway`.
 ws.close(httplib::ws::CloseStatus::GoingAway, "server restarting");
 ```
 
-The client can inspect that status and decide whether to reconnect.
+On the client, `read()` just returns `Fail`; the status and reason it received aren't exposed. If the client needs to tell a restart from other closures, send it a message first (say, `ws.send("restarting")`), then call `close()`.
 
 ## Example: a tiny chat with quit
 

docs-src/pages/en/cookbook/w04-websocket-binary.md

@@ -85,4 +85,4 @@ if (cli.read(buf) == httplib::ws::ReadResult::Binary) {
 
 You can mix text and binary in the same connection. A common pattern: JSON for control messages, binary for the actual data — you get efficient handling of metadata and payload both.
 
-> **Note:** WebSocket frames don't have an infinite size limit. For very large data, chunk it in your application code. cpp-httplib can handle a big frame in one shot, but it does load it all into memory at once.
+> **Note:** An incoming message can be at most `CPPHTTPLIB_WEBSOCKET_MAX_PAYLOAD_LENGTH` (16MB by default, 0 for no limit). A larger one makes `read()` return `Fail` and ends the connection. Within that limit, a message is held in memory whole, so for very large data, chunk it in your application code.

docs-src/pages/en/cookbook/w05-websocket-tls.md

@@ -26,6 +26,8 @@ if (ws.connect()) {
 
 To disable certificate verification entirely, use `enable_server_certificate_verification(false)`. For details on that behavior, see [T02. Control SSL Certificate Verification](../t02-cert-verification).
 
+`WebSocketClient` also has `set_server_certificate_verifier()` and `set_session_verifier()` for custom checks, plus the proxy setters (`set_proxy()`, `set_proxy_basic_auth()`, `set_proxy_bearer_token_auth()`, `set_proxy_digest_auth()`, `set_no_proxy()`). CA certificates are loaded on the first `connect()`, so set them before that.
+
 ## Presenting a client certificate (mTLS)
 
 `ws::WebSocketClient` has a constructor overload that takes a `PemMemory` struct, letting `wss://` connections present a client certificate.

docs-src/pages/en/index.md

@@ -9,7 +9,7 @@ When you need a quick HTTP server or client in C++, you want something that just
 
 The API uses a lambda-based design that feels natural. It runs anywhere you have a C++11 or later compiler. Windows, macOS, Linux — use whatever environment you already have.
 
-HTTPS works too. Just link OpenSSL or mbedTLS, and both server and client gain TLS support. Content-Encoding (gzip, Brotli, etc.), file uploads, and other features you actually need in real-world development are all included. WebSocket is also supported.
+HTTPS works too. Just link OpenSSL, Mbed TLS, or wolfSSL, and both server and client gain TLS support. Content-Encoding (gzip, Brotli, etc.), file uploads, and other features you actually need in real-world development are all included. WebSocket is also supported.
 
 Under the hood, it uses blocking I/O with a thread pool. It's not built for handling massive numbers of simultaneous connections. But for API servers, embedded HTTP in tools, mock servers for testing, and many other use cases, it delivers solid performance.
 

docs-src/pages/en/llm-app/ch04-model-management.md

@@ -76,7 +76,7 @@ Defining `CPPHTTPLIB_OPENSSL_SUPPORT` enables `httplib::Client("https://...")` t
 
 ## 4.2 Defining the Model List
 
-Let's define the list of models that the app can handle. Here are four models we've verified for translation tasks.
+Let's define the list of models that the app can handle. Here are three models we've verified for translation tasks.
 
 ```cpp
 struct ModelInfo {

docs-src/pages/en/llm-app/ch05-web-ui.md

@@ -875,6 +875,7 @@ The only server-side change is the single `set_mount_point` line. Add it before
 #include <filesystem>
 #include <fstream>
 #include <iostream>
+#include <mutex>
 
 using json = nlohmann::json;
 
@@ -934,11 +935,11 @@ std::filesystem::path get_models_dir() {
 // Model download
 // -------------------------------------------------------------------------
 
-// Abort the download if progress_cb returns false
+// If progress_cb returns false, the download is aborted
 bool download_model(const ModelInfo &model,
                     std::function<bool(int)> progress_cb) {
   httplib::Client cli("https://huggingface.co");
-  cli.set_follow_location(true);  // Hugging Face redirects to CDN
+  cli.set_follow_location(true);  // Hugging Face redirects to a CDN
 
   auto url = "/" + model.repo + "/resolve/main/" + model.filename;
   auto path = get_models_dir() / model.filename;
@@ -948,12 +949,12 @@ bool download_model(const ModelInfo &model,
   if (!ofs) { return false; }
 
   auto res = cli.Get(url,
-    // content_receiver: receive chunks and write to file
+    // content_receiver: receive data chunk by chunk and write to file
     [&](const char *data, size_t len) {
       ofs.write(data, len);
       return ofs.good();
     },
-    // progress: report download progress (return false to abort)
+    // progress: report download progress (returning false aborts)
     [&, last_pct = -1](size_t current, size_t total) mutable {
       int pct = total ? (int)(current * 100 / total) : 0;
       if (pct == last_pct) return true; // Skip if same value
@@ -987,11 +988,11 @@ void signal_handler(int sig) {
 }
 
 int main() {
-  // Create model storage directory
+  // Create the model storage directory
   auto models_dir = get_models_dir();
   std::filesystem::create_directories(models_dir);
 
-  // Auto-download default model if not present
+  // Automatically download the default model if not yet present
   std::string selected_model = MODELS[0].filename;
   auto path = models_dir / selected_model;
   if (!std::filesystem::exists(path)) {
@@ -1006,6 +1007,7 @@ int main() {
     std::cout << std::endl;
   }
   auto llm = llamalib::Llama{path};
+  std::mutex llm_mutex; // Protect access during model switching
 
   svr.set_logger([](const auto &req, const auto &res) {
     std::cout << req.method << " " << req.path << " -> " << res.status
@@ -1020,6 +1022,7 @@ int main() {
 
   svr.Post("/translate",
            [&](const httplib::Request &req, httplib::Response &res) {
+    // JSON parsing and validation (see Chapter 2 for details)
     auto input = json::parse(req.body, nullptr, false);
     if (input.is_discarded()) {
       res.status = 400;
@@ -1043,6 +1046,7 @@ int main() {
                   ". Output only the translation, nothing else.\n\n" + text;
 
     try {
+      std::lock_guard<std::mutex> lock(llm_mutex);
       auto translation = llm.chat(prompt);
       res.set_content(json{{"translation", translation}}.dump(),
                       "application/json");
@@ -1052,7 +1056,7 @@ int main() {
     }
   });
 
-  // --- SSE streaming translation (Chapter 3) --------------------------------
+  // --- SSE streaming translation (Chapter 3) -------------------------------
 
   svr.Post("/translate/stream",
            [&](const httplib::Request &req, httplib::Response &res) {
@@ -1081,6 +1085,7 @@ int main() {
     res.set_chunked_content_provider(
         "text/event-stream",
         [&, prompt](size_t, httplib::DataSink &sink) {
+          std::lock_guard<std::mutex> lock(llm_mutex);
           try {
             llm.chat(prompt, [&](std::string_view token) {
               sink.os << "data: "
@@ -1098,7 +1103,7 @@ int main() {
         });
   });
 
-  // --- Model list (Chapter 4) -----------------------------------------------
+  // --- Model list (Chapter 4) ----------------------------------------------
 
   svr.Get("/models",
           [&](const httplib::Request &, httplib::Response &res) {
@@ -1117,7 +1122,7 @@ int main() {
     res.set_content(json{{"models", arr}}.dump(), "application/json");
   });
 
-  // --- Model selection (Chapter 4) ------------------------------------------
+  // --- Model selection (Chapter 4) -----------------------------------------
 
   svr.Post("/models/select",
            [&](const httplib::Request &req, httplib::Response &res) {
@@ -1143,16 +1148,16 @@ int main() {
 
     const auto &model = *it;
 
-    // Always respond with SSE (same format whether downloaded or not)
+    // Always respond with SSE (same format whether already downloaded or not)
     res.set_chunked_content_provider(
         "text/event-stream",
         [&, model](size_t, httplib::DataSink &sink) {
-          // SSE event send helper
+          // SSE event sending helper
           auto send = [&](const json &event) {
             sink.os << "data: " << event.dump() << "\n\n";
           };
 
-          // Download if not yet downloaded (report progress via SSE)
+          // Download if not yet present (report progress via SSE)
           auto path = get_models_dir() / model.filename;
           if (!std::filesystem::exists(path)) {
             bool ok = download_model(model, [&](int pct) {
@@ -1168,8 +1173,11 @@ int main() {
 
           // Load and switch to the model
           send({{"status", "loading"}});
-          llm = llamalib::Llama{path};
-          selected_model = model.filename;
+          {
+            std::lock_guard<std::mutex> lock(llm_mutex);
+            llm = llamalib::Llama{path};
+            selected_model = model.filename;
+          }
 
           send({{"status", "ready"}});
           sink.done();
@@ -1177,11 +1185,11 @@ int main() {
         });
   });
 
-  // --- Static file serving (Chapter 5) --------------------------------------
+  // --- Static file serving (Chapter 5) -------------------------------------
 
   svr.set_mount_point("/", "./public");
 
-  // Allow graceful shutdown via `Ctrl+C` (`SIGINT`) or `kill` (`SIGTERM`)
+  // Allow the server to be stopped with `Ctrl+C` (`SIGINT`) or `kill` (`SIGTERM`)
   signal(SIGINT, signal_handler);
   signal(SIGTERM, signal_handler);
 

docs-src/pages/en/llm-app/ch06-desktop-app.md

@@ -675,9 +675,10 @@ int main() {
 To summarize the changes from Chapter 5:
 
 - `#include <csignal>` replaced with `#include <thread>`, `<cpp-embedlib-httplib.h>`, `"WebAssets.h"`, `"webview/webview.h"`
-- Removed the `signal_handler` function
+- Removed the `signal_handler` function and moved `svr` into `main()`
 - `svr.set_mount_point("/", "./public")` replaced with `httplib::mount(svr, Web::FS)`
 - `svr.listen("127.0.0.1", 8080)` replaced with `bind_to_any_port` + `listen_after_bind` + WebView event loop
+- Added `setup_macos_edit_menu()` and its `<objc/objc-runtime.h>` include (macOS only)
 
 Not a single line of handler code has changed. The REST API, SSE streaming, and model management built through Chapter 5 all work as-is.
 

docs-src/pages/en/llm-app/ch07-code-reading.md

@@ -59,7 +59,7 @@ Compatibility with existing tools and libraries is a big design decision. We des
 
 ## 7.3 Concurrent Request Handling
 
-Our server processes requests one at a time. If another request arrives while a translation is in progress, it waits until the previous inference finishes. This is fine for a desktop app used by one person, but it becomes a problem for a server shared by multiple users.
+Our server runs inference one request at a time. If another request arrives while a translation is in progress, it waits until the previous inference finishes. This is fine for a desktop app used by one person, but it becomes a problem for a server shared by multiple users.
 
 `llama-server` handles concurrent requests through a mechanism called **slots**.
 
@@ -67,7 +67,7 @@ Our server processes requests one at a time. If another request arrives while a
 
 The key point is that tokens from each slot are not inferred **one by one in sequence**, but rather **all at once in a single batch**. GPUs excel at parallel processing, so processing two users simultaneously takes almost the same time as processing one. This is called "continuous batching."
 
-In our server, cpp-httplib's thread pool assigns one thread per request, but the inference itself runs single-threaded inside `llm.chat()`. `llama-server` consolidates this inference step into a shared batch processing loop.
+In our server, cpp-httplib's thread pool serves each connection on its own worker thread, so requests on different connections are handled concurrently. Inference, however, is serialized by `llm_mutex`, so only one `llm.chat()` runs at a time. `llama-server` consolidates this inference step into a shared batch processing loop.
 
 ## 7.4 Differences in SSE Format
 

docs-src/pages/en/tour/09-whats-next.md

@@ -21,7 +21,9 @@ if (result) {
 }
 ```
 
-You can also pass a `content_receiver` callback to `Get()`. This approach works with Keep-Alive.
+Note that `stream::Get()` reads no more of the body than the client's `set_payload_max_length()` allows, which is 100MB by default. For larger downloads, raise it, or set it to 0 for no limit.
+
+You can also pass a `content_receiver` callback to `Get()`. This approach works with Keep-Alive, and it has no size limit unless you set one with `set_payload_max_length()`.
 
 ```cpp
 httplib::Client cli("http://localhost:8080");

docs-src/pages/ja/cookbook/c03-default-headers.md

@@ -50,6 +50,6 @@ httplib::Headers headers = {
 auto res = cli.Get("/users", headers);
 ```
 
-リクエスト単位で渡したヘッダーはデフォルトヘッダーに**追加**されます。両方がサーバーに送られます。
+リクエスト単位で渡したヘッダーはデフォルトヘッダーに**追加**され、両方がサーバーに送られます。デフォルトヘッダーと同じ名前のヘッダーを渡した場合は、リクエスト単位のものだけが送られます。
 
 > Bearerトークンを使った認証の詳細は[C06. BearerトークンでAPIを呼ぶ](../c06-bearer-token)を参照してください。

docs-src/pages/ja/cookbook/c04-follow-location.md

@@ -33,6 +33,8 @@ auto res = cli.Get("/");
 
 多くのサイトはHTTPアクセスをHTTPSへリダイレクトします。`set_follow_location(true)`を有効にしておけば、こうしたケースも透過的に扱えます。スキームやホストが変わっても自動で追従します。
 
+リダイレクト先が別のオリジン（スキーム、ホスト、ポートのどれかが違う）の場合、`Authorization`、`Cookie`、`Proxy-Authorization`ヘッダーは外され、`set_basic_auth()`などで設定した認証情報も送られません。クライアント証明書も提示しません。それ以外のヘッダーはデフォルトヘッダーも含めてそのまま送られ、タイムアウト、ペイロードの上限、TLSの検証設定も引き継がれます。
+
 > **Warning:** HTTPSへのリダイレクトを追従するには、cpp-httplibをOpenSSL（または他のTLSバックエンド）付きでビルドしておく必要があります。TLSサポートがないと、HTTPSへのリダイレクトは失敗します。
 
 > **Note:** リダイレクトを追従すると、リクエストの実行時間は伸びます。タイムアウトの設定は[C12. タイムアウトを設定する](../c12-timeouts)を参照してください。

docs-src/pages/ja/cookbook/c08-post-file-body.md

@@ -12,7 +12,7 @@ status: "draft"
 httplib::Client cli("https://storage.example.com");
 
 auto [size, provider] = httplib::make_file_body("backup.tar.gz");
-if (size == 0) {
+if (!provider) {
   std::cerr << "Failed to open file" << std::endl;
   return 1;
 }
@@ -27,7 +27,7 @@ auto res = cli.Put("/bucket/backup.tar.gz", size,
 
 ## ファイルが開けなかったとき
 
-`make_file_body()`は開けなかった場合、`size`を`0`、`provider`を空の関数オブジェクトとして返します。そのまま送信するとおかしな結果になるので、必ず`size`をチェックしてください。
+`make_file_body()`は開けなかった場合、`size`を`0`、`provider`を空の関数オブジェクトとして返します。そのまま送信すると空のボディが送られてしまうので、必ず`provider`をチェックしてください。`size`では判定できません。空のファイルでも`size`は`0`になり、そのときの`provider`は正しく使えるからです。
 
 > **Warning:** `make_file_body()`はContent-Lengthを最初に確定させる必要があるため、ファイルサイズをあらかじめ取得します。送信中にファイルサイズが変わる可能性がある場合は、このAPIには向きません。
 

docs-src/pages/ja/cookbook/c12-timeouts.md

@@ -12,6 +12,8 @@ status: "draft"
 | 読み取りタイムアウト | `set_read_timeout` | 300秒 | レスポンスを受信する際の1回の`recv`待ち時間 |
 | 書き込みタイムアウト | `set_write_timeout` | 5秒 | リクエストを送信する際の1回の`send`待ち時間 |
 
+HTTPSでは、接続タイムアウトがTLSハンドシェイク全体の制限時間にもなります。時間内にハンドシェイクが終わらないと、`Error::SSLConnection`で失敗します。
+
 ## 基本の使い方
 
 ```cpp

docs-src/pages/ja/cookbook/c13-max-timeout.md

@@ -4,7 +4,7 @@ order: 13
 status: "draft"
 ---
 
-[C12. タイムアウトを設定する](../c12-timeouts)で紹介した3種類のタイムアウトは、いずれも「1回の`send`や`recv`」に対するものです。リクエスト全体の所要時間に上限を設けたい場合は、`set_max_timeout()`を使います。
+[C12. タイムアウトを設定する](../c12-timeouts)で紹介した3種類のタイムアウトは、どれも一部の待ち時間にしか効きません。読み取りと書き込みのタイムアウトは「1回の`recv`や`send`」に、接続タイムアウトは接続の確立に対するものです。リクエスト全体の所要時間に上限を設けたい場合は、`set_max_timeout()`を使います。
 
 ## 基本の使い方
 

docs-src/pages/ja/cookbook/c15-compression.md

@@ -29,7 +29,7 @@ std::string big_payload = build_payload();
 auto res = cli.Post("/api/data", big_payload, "application/json");
 ```
 
-`set_compress(true)`を呼んでおくと、POSTやPUTのリクエストボディが圧縮されて送信されます。圧縮方式は、ビルドで有効にしたもののうち、Brotli、gzip、Zstdの順で最初に当てはまるものです。サーバー側もその方式に対応している必要があります。
+`set_compress(true)`を呼んでおくと、POST、PUT、PATCHのリクエストボディが圧縮されて送信されます。圧縮方式は、ビルドで有効にしたもののうち、Brotli、gzip、Zstdの順で最初に当てはまるものです。サーバー側もその方式に対応している必要があります。
 
 ## レスポンスを解凍する
 

docs-src/pages/ja/cookbook/c16-proxy.md

@@ -17,6 +17,8 @@ auto res = cli.Get("/users");
 
 プロキシ経由でリクエストが送られます。HTTPSの場合はCONNECTメソッドでトンネルが張られるので、cpp-httplib側で特別な設定は要りません。
 
+プロキシがトンネルを拒否すると、リクエストは`Error::ProxyConnection`で失敗します。ただし407だけは例外で、レスポンスとして返ってきます。`res`はtruthyで`res->status`は407ですが、`res.error()`は`Error::ProxyConnection`のままです。
+
 ## プロキシに認証を設定する
 
 プロキシ自体が認証を要求する場合は、`set_proxy_basic_auth()`や`set_proxy_bearer_token_auth()`を使います。

docs-src/pages/ja/cookbook/c17-error-codes.md

@@ -4,7 +4,7 @@ order: 17
 status: "draft"
 ---
 
-`cli.Get()`や`cli.Post()`は`Result`型を返します。リクエストが失敗したとき（サーバーに到達できなかった、タイムアウトしたなど）、返り値は「falsy」になります。詳しい原因を知りたい場合は`Result::error()`を使います。
+`cli.Get()`や`cli.Post()`は`Result`型を返します。リクエストが失敗したとき（サーバーに到達できなかった、タイムアウトしたなど）、返り値は「falsy」になります（例外が1つあり、下の表で説明します）。詳しい原因を知りたい場合は`Result::error()`を使います。
 
 ## 基本の判定
 
@@ -27,14 +27,15 @@ if (res) {
 
 | 値 | 意味 |
 | --- | --- |
-| `Error::Connection` | サーバーに接続できなかった |
+| `Error::Connection` | サーバーに接続できなかった。または、使えないURL（authorityにuserinfoやバックスラッシュがある、ポートが不正など）から`Client`を作った。後者の場合は`cli.is_valid()`が`false`になる |
 | `Error::ConnectionTimeout` | 接続タイムアウト（`set_connection_timeout`） |
 | `Error::Read` / `Error::Write` | 送受信中のエラー。`set_read_timeout`や`set_max_timeout`によるタイムアウトも`Error::Read`になる |
 | `Error::Timeout` | `stream::Get()`や`SSEClient`で、ボディの読み取りがタイムアウトした |
 | `Error::ExceedRedirectCount` | リダイレクト回数が上限を超えた |
 | `Error::SSLConnection` | TLSハンドシェイクに失敗 |
 | `Error::SSLServerVerification` | サーバー証明書の検証に失敗 |
-| `Error::Canceled` | 進捗コールバックから`false`が返された |
+| `Error::ProxyConnection` | プロキシがCONNECTのトンネルを拒否した。ただし407は例外で、`res`はtruthyかつ`res->status == 407`になり、`res.error()`は`Error::ProxyConnection`のまま |
+| `Error::Canceled` | 進捗コールバック、`ContentReceiver`、`ResponseHandler`、アップロード用のコンテンツプロバイダのいずれかから`false`が返された |
 
 ## ステータスコードとの使い分け
 

docs-src/pages/ja/cookbook/c18-ssl-errors.md

@@ -17,14 +17,17 @@ if (!res) {
   std::cerr << "error: " << httplib::to_string(err) << std::endl;
 
   if (err == httplib::Error::SSLConnection ||
-      err == httplib::Error::SSLServerVerification) {
+      err == httplib::Error::SSLServerVerification ||
+      err == httplib::Error::Read || err == httplib::Error::Write) {
     std::cerr << "ssl_error: " << res.ssl_error() << std::endl;
     std::cerr << "ssl_backend_error: " << res.ssl_backend_error() << std::endl;
   }
 }
 ```
 
-`ssl_error()`は、どのTLSバックエンドでも共通のエラー種別（`httplib::tls::ErrorCode`）を`int`で返します。`ssl_backend_error()`は、バックエンドが返したエラー値そのものです。OpenSSLなら、ハンドシェイクの失敗では`ERR_get_error()`の値が、証明書検証の失敗では検証結果のコード（`X509_V_ERR_*`）が入ります。
+`ssl_error()`は、どのTLSバックエンドでも共通のエラー種別（`httplib::tls::ErrorCode`）を`int`で返します。`ssl_backend_error()`は、バックエンドが返したエラー値そのものです。OpenSSLなら、ハンドシェイクやその後の読み書きの失敗では`ERR_get_error()`の値が、証明書検証の失敗では検証結果のコード（`X509_V_ERR_*`）が入ります。
+
+ハンドシェイクのあとで失敗したリクエストは、`Error::Read`や`Error::Write`を返します。その場合も、`ssl_error()`と`ssl_backend_error()`には原因となったTLSのエラーが入ります。たとえば、サーバーが要求するクライアント証明書を送らなかった場合、OpenSSLのエラーは「tlsv13 alert certificate required」になります。どちらの値もリクエストごとにリセットされ、TLSのエラーが絡んでいなければ`0`です。
 
 ## OpenSSLのエラーを文字列化する
 

docs-src/pages/ja/cookbook/c19-client-logger.md

@@ -35,7 +35,7 @@ cli.set_error_logger([](const httplib::Error &err, const httplib::Request *req)
 });
 ```
 
-第2引数の`req`はヌルポインタのこともあります。リクエストを組み立てる前の段階で失敗した場合です。使う前に必ずヌルチェックしてください。
+第2引数の`req`はヌルポインタのこともあります。TLSハンドシェイクやCA証明書の読み込み、プロキシのトンネル確立など、接続の準備中にエラーが起きた場合です。使う前に必ずヌルチェックしてください。
 
 ## 両方を組み合わせる
 

docs-src/pages/ja/cookbook/e04-sse-client.md

@@ -55,7 +55,9 @@ sse.on_error([](httplib::Error err) {
 });
 ```
 
-接続確立時やエラー発生時にもフックを挟めます。エラーハンドラが呼ばれても、`SSEClient`は内部で再接続を試みます。ただし、サーバーが204、403、404のいずれかを返したときは再接続しません。
+接続確立時やエラー発生時にもフックを挟めます。エラーハンドラが呼ばれても、`SSEClient`は内部で再接続を試みます。ただし、サーバーが204、403、404のいずれかを返したときや、`set_max_reconnect_attempts()`で決めた回数を使い切ったときは再接続しません。
+
+また、1つのイベントや、まだ改行が来ていない行が`CPPHTTPLIB_SSE_MAX_EVENT_LENGTH`（デフォルトは16MB、0なら無制限）を超えたときも止まります。このときエラーハンドラには`Error::ExceedMaxPayloadSize`が渡されます。イベントストリームには終わりがないので、クライアントの`set_payload_max_length()`はストリーム全体には適用されません。
 
 ## 非同期で動かす
 
@@ -88,6 +90,8 @@ sse.set_max_reconnect_attempts(10);  // 10回まで（0=無制限）
 
 `SSEClient`は受信したイベントの`id`を内部で保持していて、再接続時に`Last-Event-ID`ヘッダーとして送ってくれます。この挙動はサーバー側で`id:`付きイベントを送っていれば自動で有効になります。
 
+空の`id:`を受け取ると、保持しているIDはクリアされます。ヘッダーの値として送れない`id:`（NULなどの制御文字を含むものや、前後に空白があるもの）は無視され、それまでのIDがそのまま残ります。
+
 ```cpp
 std::cout << "last id: " << sse.last_event_id() << std::endl;
 ```

docs-src/pages/ja/cookbook/s03-path-params.md

@@ -44,6 +44,8 @@ svr.Get(R"(/users/(\d+))", [](const httplib::Request &req, httplib::Response &re
 
 パターンに括弧を使うと、マッチした部分が`req.matches`に入ります。`req.matches[0]`はパス全体、`req.matches[1]`以降がキャプチャです。
 
+正規表現のルートは、`CPPHTTPLIB_REGEX_ROUTE_PATH_MAX_LENGTH`（デフォルトは256）より長いパスには適用されず、マッチしなかったものとして扱われます。長い入力で`std::regex`がスタックを使い果たさないための制限です。もっと長いパスを扱いたい場合は、このマクロに大きな値を定義してください。
+
 ## どちらを使うか
 
 - 単純なIDやスラッグなら`:name`でじゅうぶん。読みやすく、型が自明です

docs-src/pages/ja/cookbook/s04-static-files.md

@@ -10,12 +10,19 @@ HTML、CSS、画像などの静的ファイルを配信したいときは、`set
 
 ```cpp
 httplib::Server svr;
-svr.set_mount_point("/", "./public");
+if (!svr.set_mount_point("/", "./public")) {
+  // ./publicが存在しない
+  return 1;
+}
 svr.listen("0.0.0.0", 8080);
 ```
 
+`set_mount_point()`はディレクトリが存在しないと`false`を返すので、戻り値を確認しておきましょう。
+
 `./public/index.html`には`http://localhost:8080/index.html`で、`./public/css/style.css`には`http://localhost:8080/css/style.css`でアクセスできます。ディレクトリ構造がそのままURLに反映されます。
 
+ディレクトリへのリクエストには、その中の`index.html`を返します。末尾のスラッシュがないリクエスト（`/docs`）は、`/docs/`へリダイレクト（301）されます。マウントしたディレクトリの外を指すシンボリックリンクには403を返します。
+
 ## 複数のマウントポイント
 
 マウントポイントは複数登録できます。

docs-src/pages/ja/cookbook/s07-multipart-reader.md

@@ -48,22 +48,30 @@ svr.Post("/upload",
      const httplib::ContentReader &content_reader) {
     std::ofstream ofs;
 
-    content_reader(
+    auto ok = content_reader(
       [&](const httplib::FormData &file) {
-        if (!file.filename.empty()) {
-          ofs.open("uploads/" + file.filename, std::ios::binary);
-        }
-        return static_cast<bool>(ofs);
+        if (ofs.is_open()) { ofs.close(); }         // 前のファイルを閉じる
+        if (file.filename.empty()) { return true; } // 普通のフィールドは読み飛ばす
+
+        auto name = httplib::sanitize_filename(file.filename);
+        if (name.empty()) { return false; }         // 安全でない名前は拒否
+
+        ofs.open("uploads/" + name, std::ios::binary);
+        return ofs.is_open();
       },
       [&](const char *data, size_t len) {
+        if (!ofs.is_open()) { return true; }        // ファイルのパートではない
         ofs.write(data, len);
         return static_cast<bool>(ofs);
       });
 
+    if (!ok) { return; } // ステータスは設定済み
     res.set_content("uploaded", "text/plain");
   });
 ```
 
+ヘッダーのコールバックはパートごとに呼ばれるので、次のファイルを開く前に前のファイルを閉じています。`file.filename`はクライアントが送ってきた値そのままなので、必ず`httplib::sanitize_filename()`を通してください。空文字列が返ったら、安全でない名前です。
+
 メモリには常に小さなチャンクしか載らないので、ギガバイト級のファイルでも扱えます。
 
 ## パート数は自分で数える

docs-src/pages/ja/cookbook/s09-pre-routing.md

@@ -16,7 +16,7 @@ svr.set_pre_routing_handler(
   });
 ```
 
-Pre-routingハンドラは、**ルーティングよりも前**に呼ばれます。どのハンドラにもマッチしないリクエストも含めて、すべてのリクエストを捕まえられます。
+Pre-routingハンドラは、**ルーティングよりも前**に呼ばれます。どのハンドラにもマッチしないリクエストも含めて、すべてのリクエストを捕まえられます。ただし、リクエストラインやヘッダーの解析中に拒否されたリクエスト（不正なリクエストの400、長すぎるURIの414、不正な`Range`の416）には、このハンドラが呼ばれる前にサーバーが応答します。
 
 戻り値の`HandlerResponse`がポイントです。
 

docs-src/pages/ja/cookbook/s10-post-routing.md

@@ -38,6 +38,8 @@ svr.Options("/.*", [](const auto &req, auto &res) {
 });
 ```
 
+`/.*`は正規表現のルートなので、`CPPHTTPLIB_REGEX_ROUTE_PATH_MAX_LENGTH`（デフォルトは256）より長いパスには適用されません。パスがそれより長くなりうるなら、pre-routingハンドラで`OPTIONS`を処理してください。
+
 ## セキュリティヘッダーをまとめて付ける
 
 ブラウザ向けのセキュリティヘッダーを一箇所で管理できます。

docs-src/pages/ja/cookbook/s11-pre-request.md

@@ -17,6 +17,8 @@ Pre-requestハンドラなら、`req.matched_route`に「マッチしたパタ
 
 Pre-requestハンドラが呼ばれる時点ではボディがまだ読まれていないので、認証に失敗したリクエストなどを、（巨大かもしれない）ボディを読み込む前に拒否できます。その代わり、`req.body`やボディから解析されるフォームフィールドはこの時点では参照できません。ヘッダ・パス・クエリパラメータ・`req.matched_route`を使って判断してください。
 
+Pre-requestハンドラが呼ばれるのは、ルートにマッチしたリクエストだけです。`set_mount_point()`で配信するファイルはルートのマッチングより前に返されるので、静的ファイルを守りたいときはPre-routingハンドラでチェックしてください。
+
 ## ルートごとに認証を切り替える
 
 ```cpp
@@ -39,6 +41,8 @@ svr.set_pre_request_handler(
 
 `svr.WebSocket()`で登録したルートでも、Pre-requestハンドラは呼ばれます。呼ばれるのは`101 Switching Protocols`を返す前なので、`Handled`を返すとそのHTTPレスポンス（403など）がそのまま返り、WebSocketへのアップグレードは行われません。
 
+サーバーはどの`Origin`からのハンドシェイクも受け付けます。ブラウザは別のサイトが始めたハンドシェイクにもCookieを付けて送るので、Cookieで接続を認証している場合は、`req.get_header_value("Origin")`が自分のオリジンかどうかもここで確認してください。
+
 ## 戻り値の意味
 
 Pre-routingハンドラと同じく、`HandlerResponse`を返します。

docs-src/pages/ja/cookbook/s13-error-handler.md

@@ -4,7 +4,7 @@ order: 32
 status: "draft"
 ---
 
-404や500のような**ハンドラが返したエラーレスポンス**を加工したいときは、`set_error_handler()`を使います。デフォルトの味気ないエラーページを、独自のHTMLやJSONに差し替えられます。
+404や500のような**ハンドラが返したエラーレスポンス**を加工したいときは、`set_error_handler()`を使います。エラーレスポンスのボディはデフォルトでは空ですが、エラーハンドラで独自のHTMLやJSONを入れられます。
 
 ## 基本の使い方
 

docs-src/pages/ja/cookbook/s15-server-logger.md

@@ -4,7 +4,7 @@ order: 34
 status: "draft"
 ---
 
-サーバーが受け取ったリクエストと返したレスポンスをログに残したいときは、`Server::set_logger()`を使います。各リクエストの処理が完了するたびに呼ばれるので、アクセスログやメトリクス収集の土台になります。
+サーバーが受け取ったリクエストと返したレスポンスをログに残したいときは、`Server::set_logger()`を使います。リクエストごとに、レスポンスを書き出す直前に呼ばれるので、アクセスログやメトリクス収集の土台になります。
 
 ## 基本の使い方
 
@@ -18,6 +18,8 @@ svr.set_logger([](const httplib::Request &req, const httplib::Response &res) {
 
 ログコールバックには`Request`と`Response`が渡ります。メソッド、パス、ステータスコード、クライアントIP、ヘッダー、ボディなど、好きな情報を取り出せます。
 
+`req.path`はパーセントデコード済みなので、CR/LFのような制御文字を含むことがあります。ログファイルに書き出す前にエスケープしてください。そうしないと、細工したリクエストでログの行を偽造されてしまいます。
+
 ## アクセスログ風のフォーマット
 
 Apache / Nginxのアクセスログに似た形式で残す例です。
@@ -38,6 +40,8 @@ svr.set_logger([](const auto &req, const auto &res) {
 });
 ```
 
+マウントポイントから配信するファイルのように、コンテンツプロバイダで送るレスポンスでは、この時点の`res.body`は空なので、サイズは`0B`になります。
+
 ## 処理時間を測る
 
 ログで処理時間を出したいときは、pre-routingハンドラで開始時刻を`res.user_data`に保存しておき、ロガーで差分を取ります。
@@ -59,6 +63,8 @@ svr.set_logger([](const httplib::Request &req, const httplib::Response &res) {
 });
 ```
 
+ロガーはレスポンスを書き出す前に呼ばれるので、この時間にボディの送信時間は含まれません。
+
 `user_data`の使い方は[S12. `res.user_data`でハンドラ間データを渡す](../s12-user-data)も参照してください。
 
-> **Note:** ロガーはリクエスト処理と同じスレッドで同期的に呼ばれます。重い処理を直接入れると全体のスループットが落ちるので、必要ならキューに流して非同期で処理しましょう。
+> **Note:** ロガーはリクエスト処理と同じスレッドで同期的に呼ばれ、サーバー内のすべてのロガー呼び出しが1つのロックを共有します。重い処理を直接入れると全体のスループットが落ちるので、必要ならキューに流して非同期で処理しましょう。

docs-src/pages/ja/cookbook/s19-graceful-shutdown.md

@@ -55,3 +55,5 @@ int main() {
 `stop()`を呼ぶと、新しい接続は受け付けなくなりますが、すでに動いているハンドラは**最後まで実行**されます。ただし、ストリーミングのようにコンテンツプロバイダで送っている途中のレスポンスは、その場で打ち切られます。その後、スレッドプールのワーカーが順次終了し、`listen()`から戻ってきます。これがグレースフルシャットダウンと呼ばれる理由です。
 
 > **Warning:** `stop()`を呼んでから`listen()`が戻るまでには、処理中のリクエストが終わるのを待つ時間がかかります。タイムアウトを強制したい場合は、シャットダウン用のタイマーを別途用意するなど、アプリケーション側の工夫が必要です。
+
+> **Note:** `stop()`はWebSocketハンドラを中断しません。`read()`をループで回しているハンドラは相手がつながっている限り動き続け、それが終わるまで`listen()`も戻りません。開いているWebSocket接続を記録しておき、シャットダウン時に`close()`（`CloseStatus::GoingAway`など）で閉じてください。

docs-src/pages/ja/cookbook/s20-keep-alive.md

@@ -52,6 +52,6 @@ svr.set_keep_alive_max_count(1000);
 
 ## スレッドプールとの関係
 
-Keep-Aliveでつながりっぱなしの接続は、その間ずっとワーカースレッドを1つ占有します。接続数 × 同時リクエスト数がスレッドプールのサイズを超えると、新しいリクエストが待たされます。スレッド数の調整は[S21. マルチスレッド数を設定する](../s21-thread-pool)を参照してください。
+Keep-Aliveでつながりっぱなしの接続は、その間ずっとワーカースレッドを1つ占有します。スレッドプールは負荷に応じて最大スレッド数（デフォルトはベースの4倍）までスレッドを増やしますが、開いている接続数がそれを超えると、新しい接続はどれかが閉じるまでキューで待たされます。スレッド数の調整は[S21. マルチスレッド数を設定する](../s21-thread-pool)を参照してください。
 
 > **Note:** クライアント側の挙動は[C14. 接続の再利用とKeep-Aliveの挙動を理解する](../c14-keep-alive)を参照してください。サーバーがタイムアウトで接続を切っても、クライアントは自動で再接続します。

docs-src/pages/ja/cookbook/s21-thread-pool.md

@@ -66,4 +66,4 @@ svr.new_task_queue = [] { return new MyTaskQueue(12); };
 #include <httplib.h>
 ```
 
-> **Note:** WebSocket接続はその生存期間中ずっと1スレッドを占有します。大量の同時WebSocket接続を扱うなら、動的スケーリングを有効にしておきましょう（`ThreadPool(8, 64)`のように）。
+> **Note:** WebSocket接続はその生存期間中ずっと1スレッドを占有します。大量の同時WebSocket接続を扱うなら、最大スレッド数を引き上げておきましょう（`ThreadPool(8, 64)`のように）。

docs-src/pages/ja/cookbook/t01-tls-backends.md

@@ -46,4 +46,4 @@ wolfSSLには商用ライセンスとサポートがあります。製品に組
 - [T03. SSL/TLSサーバーを立ち上げる](../t03-ssl-server)
 - [T05. サーバー側でピア証明書を参照する](../t05-peer-cert)
 
-> **Note:** macOSでは、OpenSSL系のバックエンドを使う場合、システムのキーチェーンからルート証明書を自動で読む設定（`CPPHTTPLIB_USE_CERTS_FROM_MACOSX_KEYCHAIN`）がデフォルトで有効です。無効にしたい場合は`CPPHTTPLIB_DISABLE_MACOSX_AUTOMATIC_ROOT_CERTIFICATES`を定義してください。
+> **Note:** macOSでは、3つのどのバックエンドを使う場合でも、システムのキーチェーンからルート証明書を自動で読む設定（`CPPHTTPLIB_USE_CERTS_FROM_MACOSX_KEYCHAIN`）がデフォルトで有効です。無効にしたい場合は`CPPHTTPLIB_DISABLE_MACOSX_AUTOMATIC_ROOT_CERTIFICATES`を定義してください。

docs-src/pages/ja/cookbook/t02-cert-verification.md

@@ -19,6 +19,8 @@ auto res = cli.Get("/");
 
 第1引数がCA証明書ファイル、第2引数がCA証明書ディレクトリ（省略可）です。OpenSSLバックエンドなら、`set_ca_cert_store()`で`X509_STORE*`を直接渡すこともできます。
 
+独自のCAを指定すると、クライアントはそのCAだけを信頼し、OSの証明書ストアは読みません。両方を信頼したい場合は、`cli.enable_system_ca(true)`も呼んでください。CA証明書はクライアントの最初の接続で一度だけ読み込まれるので、これらの設定は最初のリクエストより前に済ませておきましょう。
+
 ## 証明書検証を無効にする（非推奨）
 
 開発用のサーバーや自己署名証明書にアクセスしたいときは、検証を無効にできます。
@@ -46,7 +48,7 @@ cli.enable_server_hostname_verification(false);
 
 ## OSの証明書ストアをそのまま使う
 
-多くのLinuxディストリビューションでは、`/etc/ssl/certs/ca-certificates.crt`などにルート証明書がまとまっています。cpp-httplibは起動時にOSのデフォルトストアを自動で読みにいくので、普通のサーバーならとくに設定不要です。
+多くのLinuxディストリビューションでは、`/etc/ssl/certs/ca-certificates.crt`などにルート証明書がまとまっています。cpp-httplibはクライアントの最初の接続でOSのデフォルトストアを自動で読みにいくので、普通のサーバーならとくに設定不要です。
 
 > mbedTLSやwolfSSLバックエンドでも同じAPIが使えます。バックエンドの選び方は[T01. OpenSSL・mbedTLS・wolfSSLの選択指針](../t01-tls-backends)を参照してください。
 

docs-src/pages/ja/cookbook/t05-peer-cert.md

@@ -44,7 +44,7 @@ for (const auto &san : sans) {
 }
 ```
 
-ホスト名がSANに含まれるかを確認するヘルパーもあります。
+証明書がホスト名をカバーしているかを確認するヘルパーもあります。TLSのホスト名検証と同じ規則で、IPアドレスはIPアドレスのSANと、ホスト名はDNS名のSANと照合し、CNはDNS名のSANがないときだけ使います。
 
 ```cpp
 if (cert.check_hostname("alice.corp.example.com")) {
@@ -81,7 +81,7 @@ Pre-requestハンドラと組み合わせれば、共通の認可ロジックを
 
 ## SNI（Server Name Indication）
 
-クライアントが指定してきたサーバー名は、cpp-httplibが自動で処理します。同じサーバーで複数のドメインをホストする場合にSNIが使われますが、通常はハンドラ側で意識する必要はありません。
+SNIはクライアントが自動で送ります。サーバー側では、`req.sni()`でクライアントが指定したサーバー名を取得できます。ただし`SSLServer`はその名前に関係なく同じ証明書を提示するので、1つのサーバーで複数のドメインをホストするなら、すべてのドメインをカバーする証明書を使ってください。名前ごとに証明書を切り替えたい場合は、TLSバックエンドの機能を直接使います。たとえばOpenSSLなら、コンテキストのセットアップ用コールバックを受け取る`SSLServer`のコンストラクタで、servernameコールバックを設定します。
 
 > **Warning:** `req.peer_cert()`は、mTLSが有効で、かつクライアントが証明書を提示した場合のみ有効な値を返します。通常のTLS接続では空の`PeerCert`が返ります。使う前に必ず`bool`チェックしてください。
 

docs-src/pages/ja/cookbook/w01-websocket-echo.md

@@ -21,7 +21,12 @@ int main() {
       if (result == httplib::ws::ReadResult::Fail) {
         break;
       }
-      ws.send(msg); // 受け取った内容をそのまま返す
+      // 受け取った内容を同じフレームタイプでそのまま返す
+      if (result == httplib::ws::ReadResult::Binary) {
+        ws.send(msg.data(), msg.size());
+      } else {
+        ws.send(msg);
+      }
     }
   });
 
@@ -29,7 +34,7 @@ int main() {
 }
 ```
 
-`svr.WebSocket()`でWebSocket用のハンドラを登録します。ハンドラが呼ばれた時点で、すでにWebSocketのハンドシェイクは完了しています。ループの中で`ws.read()`して`ws.send()`するだけで、エコー動作が完成します。
+`svr.WebSocket()`でWebSocket用のハンドラを登録します。ハンドラが呼ばれた時点で、すでにWebSocketのハンドシェイクは完了しています。ループの中で`ws.read()`して`ws.send()`するだけで、エコー動作が完成します。バイナリメッセージは`data()`と`size()`を渡すオーバーロードで返すので、バイナリのまま届きます（詳しくは後述）。
 
 `read()`の返り値は`ReadResult`列挙値で、次の4種類です。
 
@@ -76,7 +81,7 @@ ws.send(binary_data, binary_data_size);  // バイナリフレーム
 
 ## スレッドとの関係
 
-WebSocket接続はハンドラが終わるまで生き続けるので、1接続につきワーカースレッドを1つ占有します。同時接続数が多い場合は、スレッドプールを動的スケーリングに設定しましょう。
+WebSocket接続はハンドラが終わるまで生き続けるので、1接続につきワーカースレッドを1つ占有します。デフォルトのスレッドプールも負荷に応じてベースの4倍まで増えますが、同時接続数が多い場合は、その最大スレッド数を引き上げましょう。
 
 ```cpp
 svr.new_task_queue = [] {

docs-src/pages/ja/cookbook/w02-websocket-ping.md

@@ -43,7 +43,7 @@ cli.connect();
 
 ## Pingへの応答（Pong）
 
-WebSocketプロトコルでは、PingフレームにはPongフレームで応答することが決まっています。cpp-httplibは受信したPingに自動でPongを返すので、アプリケーションコード側で気にする必要はありません。
+WebSocketプロトコルでは、PingフレームにはPongフレームで応答することが決まっています。cpp-httplibは受信したPingに`read()`の中で自動でPongを返すので、`read()`を呼び続けている限り、アプリケーションコード側で気にする必要はありません。
 
 ## Pingの間隔をどう決めるか
 

docs-src/pages/ja/cookbook/w03-websocket-close.md

@@ -67,7 +67,7 @@ cli.close(httplib::ws::CloseStatus::Normal);
 ws.close(httplib::ws::CloseStatus::GoingAway, "server restarting");
 ```
 
-クライアント側はこのステータスを見て、再接続を試みるかどうかを判断できます。
+クライアント側の`read()`は`Fail`を返すだけで、受け取ったステータスや理由は取り出せません。再起動による切断をほかの切断と見分けたい場合は、先にメッセージ（`ws.send("restarting")`など）を送ってから`close()`を呼びましょう。
 
 ## サンプル: 簡単なチャット終了
 

docs-src/pages/ja/cookbook/w04-websocket-binary.md

@@ -85,4 +85,4 @@ if (cli.read(buf) == httplib::ws::ReadResult::Binary) {
 
 テキストとバイナリを混ぜて送ることもできます。たとえば「制御メッセージはJSON、データ本体はバイナリ」といったプロトコルを組み立てると、メタデータと生データを効率よく扱えます。
 
-> **Note:** WebSocketのフレームサイズには上限がないわけではありません。巨大なデータを送るときは、アプリケーション側で分割して送るのが安全です。cpp-httplibのデフォルトでは大きなフレームもそのまま処理されますが、メモリを一気に使う点は変わりません。
+> **Note:** 受信できるメッセージの大きさは`CPPHTTPLIB_WEBSOCKET_MAX_PAYLOAD_LENGTH`（デフォルトは16MB、0なら無制限）までです。これを超えると`read()`は`Fail`を返し、接続は終了します。上限以内でもメッセージはまるごとメモリに載るので、巨大なデータを送るときは、アプリケーション側で分割して送るのが安全です。

docs-src/pages/ja/cookbook/w05-websocket-tls.md

@@ -26,6 +26,8 @@ if (ws.connect()) {
 
 証明書検証そのものを無効にしたい場合は`enable_server_certificate_verification(false)`が使えます。挙動の詳細は[T02. SSL証明書の検証を制御する](../t02-cert-verification)を参照してください。
 
+`WebSocketClient`には、独自の検証に使う`set_server_certificate_verifier()`と`set_session_verifier()`や、プロキシ用のセッター（`set_proxy()`、`set_proxy_basic_auth()`、`set_proxy_bearer_token_auth()`、`set_proxy_digest_auth()`、`set_no_proxy()`）もあります。CA証明書は最初の`connect()`で読み込まれるので、それより前に設定してください。
+
 ## クライアント証明書を使う（mTLS）
 
 `ws::WebSocketClient`には`PemMemory`構造体を受け取るコンストラクタがあり、`wss://`接続でクライアント証明書を提示できます。

docs-src/pages/ja/index.md

@@ -9,7 +9,7 @@ C++でちょっとしたHTTPサーバーやクライアントが必要になっ
 
 APIはラムダ式をベースにした直感的な設計で、C++11以降のコンパイラーがあればどこでも動きます。Windows、macOS、Linux — お使いの環境をそのまま使えます。
 
-HTTPSも使えます。OpenSSLやmbedTLSをリンクするだけで、サーバー・クライアントの両方がTLSに対応します。Content-Encoding（gzip, brotli等）、ファイルアップロードなど、実際の開発で必要になる機能もひと通り揃っています。WebSocketもサポートしています。
+HTTPSも使えます。OpenSSL、Mbed TLS、wolfSSLのいずれかをリンクするだけで、サーバー・クライアントの両方がTLSに対応します。Content-Encoding（gzip, brotli等）、ファイルアップロードなど、実際の開発で必要になる機能もひと通り揃っています。WebSocketもサポートしています。
 
 内部的にはブロッキングI/Oとスレッドプールを使っています。大量の同時接続を捌くような用途には向きませんが、APIサーバーやツールの組み込みHTTP、テスト用のモックサーバーなど、多くのユースケースで十分な性能を発揮します。
 

docs-src/pages/ja/llm-app/ch04-model-management.md

@@ -76,7 +76,7 @@ endif()
 
 ## 4.2 モデル一覧を定義する
 
-アプリが扱えるモデルの一覧を定義します。翻訳タスクで検証済みの4モデルを用意しました。
+アプリが扱えるモデルの一覧を定義します。翻訳タスクで検証済みの3モデルを用意しました。
 
 ```cpp
 struct ModelInfo {

docs-src/pages/ja/llm-app/ch05-web-ui.md

@@ -875,6 +875,7 @@ modelSelect.addEventListener("change", async () => {
 #include <filesystem>
 #include <fstream>
 #include <iostream>
+#include <mutex>
 
 using json = nlohmann::json;
 
@@ -1006,6 +1007,7 @@ int main() {
     std::cout << std::endl;
   }
   auto llm = llamalib::Llama{path};
+  std::mutex llm_mutex; // モデル切り替え中のアクセスを保護する
 
   svr.set_logger([](const auto &req, const auto &res) {
     std::cout << req.method << " " << req.path << " -> " << res.status
@@ -1020,6 +1022,7 @@ int main() {
 
   svr.Post("/translate",
            [&](const httplib::Request &req, httplib::Response &res) {
+    // JSONパース・バリデーション（詳細は2章を参照）
     auto input = json::parse(req.body, nullptr, false);
     if (input.is_discarded()) {
       res.status = 400;
@@ -1043,6 +1046,7 @@ int main() {
                   ". Output only the translation, nothing else.\n\n" + text;
 
     try {
+      std::lock_guard<std::mutex> lock(llm_mutex);
       auto translation = llm.chat(prompt);
       res.set_content(json{{"translation", translation}}.dump(),
                       "application/json");
@@ -1081,6 +1085,7 @@ int main() {
     res.set_chunked_content_provider(
         "text/event-stream",
         [&, prompt](size_t, httplib::DataSink &sink) {
+          std::lock_guard<std::mutex> lock(llm_mutex);
           try {
             llm.chat(prompt, [&](std::string_view token) {
               sink.os << "data: "
@@ -1168,8 +1173,11 @@ int main() {
 
           // モデルをロードして切り替え
           send({{"status", "loading"}});
-          llm = llamalib::Llama{path};
-          selected_model = model.filename;
+          {
+            std::lock_guard<std::mutex> lock(llm_mutex);
+            llm = llamalib::Llama{path};
+            selected_model = model.filename;
+          }
 
           send({{"status", "ready"}});
           sink.done();

docs-src/pages/ja/llm-app/ch06-desktop-app.md

@@ -675,9 +675,10 @@ int main() {
 5章からの変更点をまとめると:
 
 - `#include <csignal>` → `#include <thread>`, `<cpp-embedlib-httplib.h>`, `"WebAssets.h"`, `"webview/webview.h"`
-- `signal_handler`関数を削除
+- `signal_handler`関数を削除し、`svr`を`main()`の中に移動
 - `svr.set_mount_point("/", "./public")` → `httplib::mount(svr, Web::FS)`
 - `svr.listen("127.0.0.1", 8080)` → `bind_to_any_port` + `listen_after_bind` + WebViewのイベントループ
+- macOS用に`setup_macos_edit_menu()`と`<objc/objc-runtime.h>`のインクルードを追加
 
 ハンドラのコードは1行も変わっていません。5章まで作ってきたREST API・SSEストリーミング・モデル管理がそのまま動きます。
 

docs-src/pages/ja/llm-app/ch07-code-reading.md

@@ -59,7 +59,7 @@ response = client.chat.completions.create(
 
 ## 7.3 同時リクエスト処理
 
-私たちのサーバーはリクエストを1つずつ処理します。翻訳中に別のリクエストが来ると、前の推論が終わるまで待ちます。1人で使うデスクトップアプリなら問題ありませんが、複数人で共有するサーバーでは困ります。
+私たちのサーバーは推論を1リクエストずつ実行します。翻訳中に別のリクエストが来ると、前の推論が終わるまで待ちます。1人で使うデスクトップアプリなら問題ありませんが、複数人で共有するサーバーでは困ります。
 
 `llama-server`は**スロット**という仕組みで同時リクエストを処理します。
 
@@ -67,7 +67,7 @@ response = client.chat.completions.create(
 
 ポイントは、各スロットのトークンを**1つずつ順番に**ではなく、**まとめて1回のバッチ**で推論することです。GPUは並列処理が得意なので、2人分を同時に処理しても1人分とほとんど変わらない時間で済みます。これを「連続バッチ処理（continuous batching）」と呼びます。
 
-私たちのサーバーではcpp-httplibのスレッドプールが各リクエストに1スレッドを割り当てますが、推論自体は`llm.chat()`の中でシングルスレッドです。`llama-server`はこの推論部分を共有のバッチ処理ループに集約しています。
+私たちのサーバーではcpp-httplibのスレッドプールが接続ごとにワーカースレッドを1つ割り当てるので、別々の接続から来たリクエストは並行して処理されます。ただし推論は`llm_mutex`で直列化されるので、`llm.chat()`は一度に1つしか実行されません。`llama-server`はこの推論部分を共有のバッチ処理ループに集約しています。
 
 ## 7.4 SSEフォーマットの違い
 

docs-src/pages/ja/tour/09-whats-next.md

@@ -21,7 +21,9 @@ if (result) {
 }
 ```
 
-`Get()`に`content_receiver`コールバックを渡す方法もあります。こちらはKeep-Aliveと併用できます。
+なお、`stream::Get()`で読めるボディの大きさは、クライアントの`set_payload_max_length()`の上限（デフォルトは100MB）までです。もっと大きなファイルをダウンロードするなら、上限を引き上げるか、0を指定して無制限にしてください。
+
+`Get()`に`content_receiver`コールバックを渡す方法もあります。こちらはKeep-Aliveと併用でき、`set_payload_max_length()`で上限を設定しない限りサイズの制限もありません。
 
 ```cpp
 httplib::Client cli("http://localhost:8080");

docs-util/llm-app/test_book.sh

@@ -4,8 +4,9 @@ set -euo pipefail
 # =============================================================================
 # test_book.sh — LLM App Tutorial (Ch1–Ch5) E2E Test
 #
-# Code is extracted from the doc markdown files (<!-- test:full-code --> and
-# <!-- test:cmake --> markers), so tests always stay in sync with the docs.
+# Code is extracted from the ja doc markdown files (the code block after each
+# <summary data-file="..."> line; see extract_code.sh), so tests always stay
+# in sync with the docs.
 # =============================================================================
 
 SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"