bef278e0d2
Samples that did not compile or run as shown: - res.user_data.get<T>() inside a generic lambda needs the `template` keyword; use explicit parameter types (tour 09, cookbook s15). - listen() on a Unix domain socket fails with port 0 (tour 09, s22). - "*.dev.local" is not a NO_PROXY pattern (c16). - ssl_backend_error() holds a verify result, not an ERR_get_error() value, after a verification failure; decode each with the matching OpenSSL function (c18). - The content provider's `length` is everything that remains, so the sample read the whole file in one call (s05). Statements corrected: - Client keep-alive is off by default; c14 is rewritten around set_keep_alive(true). - Mounted files are looked up before GET handlers (tour 04, s04). - Params keep insertion order, and to_string(Error::Connection) reads "Could not establish connection" (tour 02). - A chunked provider ends with sink.done(), and post_routing_handler runs before the response is sent (tour 09). - Timeouts surface as Error::Read; Error::Timeout comes from the stream API (c17). The max timeout cuts off the wait for the response only (c13). The progress callback needs Content-Length (c11). - Encoding selection follows q-values, then Brotli, gzip, Zstd (s08), and the client compresses with the first of those it was built with (c15). - stop() cuts a provider-driven response short (s19); a rejected content_reader already gets 400 or 413 (s07); user_data values must be copyable (s12); Client accepts a client certificate too (t04); on_message() is the fallback for every unhandled event and 204/403/404 end reconnection (e04); the pong timeout takes two to three intervals and ends a waiting read() (w02). In the LLM app tutorial, an uncaught exception does not crash the server, so say what it does instead. Drop the server and client timeout settings whose stated purpose, covering inference and download time, they do not serve: those timeouts bound a single socket wait. Update the llama.cpp server layout in chapter 7.
3.4 KiB
title, order, status
| title | order | status |
|---|---|---|
| S07. Receive Multipart Data as a Stream | 26 | draft |
A naive upload handler puts the whole request into req.body, which blows up memory for large files. Use HandlerWithContentReader to receive the body chunk by chunk.
Basic usage
svr.Post("/upload",
[](const httplib::Request &req, httplib::Response &res,
const httplib::ContentReader &content_reader) {
if (req.is_multipart_form_data()) {
content_reader(
// headers of each part
[&](const httplib::FormData &file) {
std::cout << "name: " << file.name
<< ", filename: " << file.filename << std::endl;
return true;
},
// body of each part (called multiple times)
[&](const char *data, size_t len) {
// write to disk here, for example
return true;
});
} else {
// plain request body
content_reader([&](const char *data, size_t len) {
return true;
});
}
res.set_content("ok", "text/plain");
});
The content_reader has two call shapes. For multipart data, pass two callbacks (one for headers, one for body). For plain bodies, pass just one.
Write directly to disk
Here's how to stream an uploaded file to disk.
svr.Post("/upload",
[](const httplib::Request &req, httplib::Response &res,
const httplib::ContentReader &content_reader) {
std::ofstream ofs;
content_reader(
[&](const httplib::FormData &file) {
if (!file.filename.empty()) {
ofs.open("uploads/" + file.filename, std::ios::binary);
}
return static_cast<bool>(ofs);
},
[&](const char *data, size_t len) {
ofs.write(data, len);
return static_cast<bool>(ofs);
});
res.set_content("uploaded", "text/plain");
});
Only a small chunk sits in memory at any moment, so gigabyte-scale files are no problem.
Count the parts yourself
There is a cap on the number of parts, CPPHTTPLIB_MULTIPART_FORM_DATA_FILE_MAX_COUNT (1024 by default), but it only applies to the buffered path, where every part is accumulated into req.form. The ContentReader keeps nothing on the library side, so the cap does not apply here.
If you want an upper bound, count the parts yourself and return false from the header callback. The parser stops right there.
svr.Post("/upload",
[](const httplib::Request &req, httplib::Response &res,
const httplib::ContentReader &content_reader) {
size_t count = 0;
auto ok = content_reader(
[&](const httplib::FormData &file) {
if (++count > 100) { return false; } // stop here
return true;
},
[&](const char *data, size_t len) {
return true;
});
if (!ok) {
res.status = httplib::StatusCode::BadRequest_400;
return;
}
res.set_content("ok", "text/plain");
});
When content_reader returns false, the response status becomes 400 (413 if the body exceeded the size limit). Set it yourself if you want a different one. The rest of the body is left unread and the connection is closed, so a client that is still sending sees the connection drop.
Warning: When you use
HandlerWithContentReader,req.bodystays empty. Handle the body yourself inside the callbacks.
For the client side of multipart uploads, see C07. Upload a file as multipart form data.