send_stream kept the status line of a failed streaming request and dropped the reason. It now keeps the body, and three framing defects found while reviewing that change are fixed with it.

Reported and first fixed by @Cloud_Yun in #11/#12; the review is in #14.

The error body of a failed streaming request is kept. Every byte of a non-2xx body reaches HttpResponse::body, bounded at 1 MiB. send() always did this and send_stream() never did, which is the asymmetry the report was about. The success path is unchanged: a 2xx body is the caller's stream and is not captured.

A declared Content-Length is honoured by send_stream. It had no branch for one, so a response that was not chunked was read until the connection closed — and on this library's defaults (keepAlive = true) the server does not close. Measured against a 135-byte error document: 9379 ms at an 8-second read timeout, against 1192 ms now. At the shipped default of 60000 that was a minute.

A chunk size that does not parse is no longer read as a terminal chunk. parse_hex returned what it had accumulated on an unrecognised character and 0 for an empty line — and an empty line is what read_line returns on a timeout or a closed connection, so a truncated stream read as one that ended cleanly. send and send_stream now use parse_chunk_size_line, which #9 added for exactly this and which had reached download_to_file alone.

Content-Length is rejected rather than salvaged. Both readers kept the digits and discarded the rest: "abc" was 0 and indistinguishable from a real zero, "12abc" was 12, "-1" was 1, and "99999999999999999999" wrapped to 7766279631452241919. parse_content_length is exported and tested, as parse_chunk_size_line is.

Six new unit tests over the two parsers; the live test for the error body now runs on the default configuration and asserts the elapsed time, and a chunked 2xx is asserted to leave body empty and return promptly.