mirror of
https://github.com/yhirose/cpp-httplib.git
synced 2026-10-01 05:02:29 +07:00
metsw24-maxandyhirose
0480ff77b8
* reject ambiguously framed responses in client read paths * Accept non-chunked Transfer-Encoding responses in the client framing guard RFC 9112 §6.3 treats requests and responses differently when the final transfer coding is not chunked: a request's body length cannot be determined and the server must answer 400, but a response's body simply runs until the server closes the connection. read_content() and the open_stream() body reader already do that, so such a response is not ambiguous and rejecting it broke valid responses such as "Transfer-Encoding: gzip" followed by a close. Keep rejecting a Transfer-Encoding paired with a non-zero Content-Length, which is the actual ambiguity, and drop the non-chunked clause from both client read paths. Tests: check that rejection surfaces as Error::Read, that a non-chunked Transfer-Encoding response is read until close on both paths, and that HEAD, 204 and 304 responses with both framing headers are not rejected. Claude-Session: https://claude.ai/code/session_01JYPWKpbp4a881EdpEf2xSi * Share the framing check and reuse existing test helpers Factor "Transfer-Encoding with a non-zero Content-Length" into detail::has_conflicting_content_length() next to is_chunked_transfer_encoding(), and call it from the server request guard and both client read paths so the rule and its RFC 9112 §6.3 rationale live in one place. In the tests, drop the POSIX-only raw socket helper in favour of the existing serve_single_response() and read_all(), which also lets the tests run on Windows. Fold the stream-only test into the buffered one so each case checks both Get() and open_stream(), and cover the HEAD/204/304 exclusion on the open_stream() path too. Claude-Session: https://claude.ai/code/session_01JYPWKpbp4a881EdpEf2xSi --------- Co-authored-by: yhirose <yuji.hirose.bug@gmail.com>
