yhirose
9bfd2ddf1c
Bring the READMEs and the docs pages (en and ja) in line with the current header: - Fix the client sample that does not compile, the Transfer-Encoding statement for default headers, the verifier callback comment, the thread pool spawn rule, the sanitize_filename description, and the inverted Accept-Encoding sentence. - Describe recent behaviour: TLS errors behind Read/Write failures, Host validation, Connection: close for a body without length, content_reader rules, refused CONNECT, WebSocketClient proxies, CPPHTTPLIB_INTERIM_RESPONSE_MAX_COUNT, the SSE event size limit, and the payload limit of the Stream API. - Complete the API references of WebSocket, WebSocketClient and the stream:: helpers, and the SSE reconnect rules. - Fix cookbook pages: keychain loading on every backend, received Close status, a multipart sample that trusted the client's file name, an echo sample that sent binary as text, SNI, pre-request handler scope, stop() with WebSocket handlers, and the thread pool notes. - Restore the mutex in the LLM app's Chapter 5 code.
2.7 KiB
title, order, status
| title | order | status |
|---|---|---|
| W03. Handle Connection Close | 54 | draft |
A WebSocket ends when either side closes it explicitly, or when the network drops. Handle close cleanly, and your cleanup and reconnect logic stays tidy.
Detect a closed connection
When ws.read() returns ReadResult::Fail, the connection is gone — either cleanly or with an error. Break out of the loop and the handler will finish.
svr.WebSocket("/chat", [](const httplib::Request &req, httplib::ws::WebSocket &ws) {
std::string msg;
while (ws.is_open()) {
auto result = ws.read(msg);
if (result == httplib::ws::ReadResult::Fail) {
std::cout << "disconnected" << std::endl;
break;
}
handle_message(ws, msg);
}
// cleanup runs once we're out of the loop
cleanup_user_session(req);
});
You can also check ws.is_open() — it's the same signal from a different angle.
Close from the server side
To close explicitly, call close().
ws.close(httplib::ws::CloseStatus::Normal, "bye");
The first argument is the close status; the second is an optional reason. Common CloseStatus values:
| Value | Meaning |
|---|---|
Normal (1000) |
Normal closure |
GoingAway (1001) |
Server is shutting down |
ProtocolError (1002) |
Protocol violation detected |
UnsupportedData (1003) |
Received data that can't be handled |
PolicyViolation (1008) |
Violated a policy |
MessageTooBig (1009) |
Message too large |
InternalError (1011) |
Server-side error |
Close from the client side
The client API is identical.
cli.close(httplib::ws::CloseStatus::Normal);
Destroying the client also closes the connection, but calling close() explicitly makes the intent clearer.
Graceful shutdown
To notify in-flight clients that the server is going down, use GoingAway.
ws.close(httplib::ws::CloseStatus::GoingAway, "server restarting");
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
svr.WebSocket("/chat", [](const auto &req, auto &ws) {
std::string msg;
while (ws.is_open()) {
if (ws.read(msg) == httplib::ws::ReadResult::Fail) break;
if (msg == "/quit") {
ws.send("goodbye");
ws.close(httplib::ws::CloseStatus::Normal, "user quit");
break;
}
ws.send("echo: " + msg);
}
});
Note: On a sudden network drop,
read()returnsFailwith no chance to callclose(). Put your cleanup at the end of the handler, and both paths — clean close and abrupt disconnect — end up in the same place.