Add buffer_response for return to client images from buffer#368
Add buffer_response for return to client images from buffer#368akrabad wants to merge 1 commit intoetr:masterfrom
Conversation
The existing string_response already supports binary content (std::string can hold arbitrary bytes), but this was not documented or demonstrated anywhere. This gap caused users to believe a new response type was needed (see PR #368). - Add a note to the README's string_response description clarifying binary data support - Add a new "Serving binary data from memory" section with inline example - Add examples/binary_buffer_response.cpp as a complete, buildable example that serves a PNG image from an in-memory buffer - Register the new example in examples/Makefile.am https://claude.ai/code/session_01S3BvBrSoNvUhpYTyhPYCjJ
|
Hi @akrabad, thank you for opening this PR and surfacing this use case! Serving binary data (like camera frames) directly from memory without disk I/O is a completely valid need. That said, the fact that this wasn’t obvious is entirely a documentation gap on our side — the docs and examples only ever showed text usage, so your assumption that a new class was needed was very reasonable. |
The existing string_response already supports binary content (std::string can hold arbitrary bytes), but this was not documented or demonstrated anywhere. This gap caused users to believe a new response type was needed (see PR #368). - Add a note to the README's string_response description clarifying binary data support - Add a new "Serving binary data from memory" section with inline example - Add examples/binary_buffer_response.cpp as a complete, buildable example that serves a PNG image from an in-memory buffer - Register the new example in examples/Makefile.am https://claude.ai/code/session_01S3BvBrSoNvUhpYTyhPYCjJ
* Migrate to libmicrohttpd 1.0.0 API with new features Raise minimum libmicrohttpd requirement to 1.0.0 and migrate all deprecated APIs to their v3 replacements: - Basic Auth: MHD_basic_auth_get_username_password3, MHD_queue_basic_auth_required_response3 with UTF-8 support - Digest Auth: MHD_digest_auth_check3, MHD_digest_auth_check_digest3, MHD_queue_auth_required_response3 with SHA-512/256, userhash, nonce binding, and structured digest_auth_result enum Add new response types: empty_response, pipe_response, iovec_response. Add external event loop integration (run, run_wait, get_fdset, get_timeout, add_connection), daemon management (quiesce, get_listen_fd, get_active_connections, get_bound_port), and numerous new daemon options (listen_backlog, address_reuse, tcp_fastopen_queue_size, turbo, etc.). Add conditional WebSocket support via libmicrohttpd_ws. Add utility functions: reason_phrase, is_feature_supported, get_mhd_version. * Update README with all new MHD 1.0 features and options Document WebSocket support, new response types (empty, iovec, pipe), external event loop integration, daemon introspection methods, new server configuration options (turbo, no_listen_socket, suppress_date_header, etc.), enhanced TLS options, updated digest authentication API with SHA-256/SHA-512/256 and fine-grained result codes, and new http_utils utility methods. * Add examples for new MHD 1.0 features and document them in README New example files: - empty_response_example: 204 No Content and HEAD-only responses - iovec_response_example: scatter-gather response from multiple buffers - pipe_response_example: streaming response from a pipe fd - websocket_echo: WebSocket echo server with on_open/on_message/on_close - daemon_info: daemon introspection (bound port, listen fd, http_utils) - external_event_loop: driving the server with run_wait() and quiesce() - turbo_mode: high-performance config with turbo, suppressed date header, TCP Fast Open, and listen backlog All examples are added to the Other Examples section of the README with inline code, test commands, and links to the source files. * Cleaned-up validation issues * fix codacy warnings * Add documentation and example for serving binary data from memory The existing string_response already supports binary content (std::string can hold arbitrary bytes), but this was not documented or demonstrated anywhere. This gap caused users to believe a new response type was needed (see PR #368). - Add a note to the README's string_response description clarifying binary data support - Add a new "Serving binary data from memory" section with inline example - Add examples/binary_buffer_response.cpp as a complete, buildable example that serves a PNG image from an in-memory buffer - Register the new example in examples/Makefile.am https://claude.ai/code/session_01S3BvBrSoNvUhpYTyhPYCjJ * Fix CI: add ChangeLog entry and missing include <utility> Add ChangeLog entry for the binary buffer example to satisfy the ChangeLog Check workflow. Add missing #include <utility> for std::move to fix cpplint warning. https://claude.ai/code/session_01S3BvBrSoNvUhpYTyhPYCjJ * Migrate to libmicrohttpd 1.0.0 API with new features Raise minimum libmicrohttpd requirement to 1.0.0 and migrate all deprecated APIs to their v3 replacements: - Basic Auth: MHD_basic_auth_get_username_password3, MHD_queue_basic_auth_required_response3 with UTF-8 support - Digest Auth: MHD_digest_auth_check3, MHD_digest_auth_check_digest3, MHD_queue_auth_required_response3 with SHA-512/256, userhash, nonce binding, and structured digest_auth_result enum Add new response types: empty_response, pipe_response, iovec_response. Add external event loop integration (run, run_wait, get_fdset, get_timeout, add_connection), daemon management (quiesce, get_listen_fd, get_active_connections, get_bound_port), and numerous new daemon options (listen_backlog, address_reuse, tcp_fastopen_queue_size, turbo, etc.). Add conditional WebSocket support via libmicrohttpd_ws. Add utility functions: reason_phrase, is_feature_supported, get_mhd_version. * Fix Codacy CWE-126: replace strlen with std::char_traits::length Replace strlen(s) with std::char_traits<char>::length(s) in unescaper_func to silence Codacy static analysis warning about potential over-read on non-null-terminated strings. The MHD API guarantees s is null-terminated, but using the C++ equivalent avoids false positives from C-focused analyzers. * libmicro to v1.0.3 * libmicrohttpd to 1.0.3 in codeql checks * Fix CI: cpplint errors, external event loop test, and Windows pipe build - Add missing #include <utility> and <string> in headers and examples - Reorder includes in webserver.cpp to satisfy cpplint include order - Add NOLINT(runtime/int) for curl API's long parameters - Add EXTERNAL_SELECT start method (MHD_USE_AUTO without internal threading) for proper external event loop support - Fix daemon_info test and external_event_loop example to use EXTERNAL_SELECT instead of INTERNAL_SELECT with run_wait() - Fix pipe_response_example to compile on Windows (_pipe + <io.h>) * Fix Windows build for new_response_types test Test file was missed in d4808b4 which fixed the same pattern in pipe_response_example.cpp. MinGW64 has _pipe, not pipe. * Silence cpplint readability/braces on Windows-guarded class cpplint's brace check gets confused by the #if/#else/#endif inside pipe_resource::render_GET, matching the existing NOLINT in examples/pipe_response_example.cpp. * Fix Windows external_event_loop test: drop no_thread_safety() On Windows/MSYS2, MHD_start_daemon rejects the combination of MHD_USE_AUTO (EXTERNAL_SELECT) and MHD_USE_NO_THREAD_SAFETY, causing daemon_info.exe test #6 to fail with "Unable to connect daemon to port: 8080". Drop no_thread_safety() from both the test and the matching example; the default thread-safe daemon is still drivable from a single thread via MHD_run_wait. * Fix Windows port leak in quiesce_does_not_crash test MHD_quiesce_daemon transfers the listen socket to the caller. On Windows, MHD sockets are Winsock SOCKETs and POSIX close() from <unistd.h> does not close them, so the prior version leaked the socket and left port 8080 bound. The next test in the same binary (external_event_loop) then failed MHD_start_daemon with "Unable to connect daemon to port: 8080". Use closesocket() on Windows and close() elsewhere. --------- Co-authored-by: Claude <noreply@anthropic.com>
Description of the Change
libhttpserver can fill responce with image from file on disk. But not from buffer.
I read from camera jpeg file that stored in buffer. I don't want to save this file to disk and read from disk. To many read/write operations (>5 per/sec)
Possible Drawbacks
Nothing. Use template of nullptr 0 size byte response (if file on disk dosent exist)
Verification Process
Read data from camera. Store it to my buffer. And read from buffer if get request for image