Reject incomplete HTTP responses safely

[araxis]

Problem

When a peer closes before its HTTP header or declared body is complete, the client can dereference a missing body, keep reading after EOF, or expose a partial response.

Change

Return a completion result from response collection, reject incomplete responses through target 6 using its existing unavailable status, and release unfinished body collection state. Complete responses keep their current behavior. This does not introduce a deadline policy or change parser framing support.

The regression follows the existing Linux HTTP host-test layout and runs in the existing build workflow. No TLS work or parser dependency update is included. Extracted from #936.

Status and dependency

The connection cleanup fix (#955) is merged. This revision is based on upstream master 04c2831ed6c61efc5e0f6b0c147d8304595597c9. Local preparation and validation are complete.

Review only this fix. The branch refresh preserves the existing commits and review links.

Testing

Tested on October 6, 2026. Host machine: AMD Ryzen 9 9950X PC, x86-64, Ubuntu 26.04.1 LTS under WSL2 on Windows; kernel 6.18.33.2-microsoft-standard-WSL2; GCC/G++ 15.2.0; GNU Make 4.4.1.

These are Linux host regressions using real loopback sockets, not tests running on an Ultimate device. The lifecycle suites and general regression use AddressSanitizer and UndefinedBehaviorSanitizer. The unsigned-char check uses a separate build.

Candidate: c38406f6af5e94ff35aebaf0b12f292b04e2f0c1. Comparison base: 04c2831ed6c61efc5e0f6b0c147d8304595597c9.

Test	Before the fix	After the fix
response-completion	Empty response: undefined-behavior failure from a null body pointer (exit 1). Incomplete header: exceeds the fixed 10-second guard (exit 124).	360 focused checks, zero failures
Cumulative host regressions	Not used as the negative control	1,127 checks, zero failures
Clean U64-II RISC-V management-application build	Not used as the negative control	Passed with xPack GCC 11.3.0 and the existing dependency pins

Focused coverage: Empty response; incomplete header; short fixed-length and chunked bodies; complete and zero-length responses; raw/object paths and recovery.

The negative control uses this candidate's test/build files with only this PR's production changes restored to the exact comparison base. The failure is expected evidence; it is not counted as a successful test run. The green total is 63 body-removal + 201 connection-cleanup + 360 response-completion + 404 general + 99 unsigned-char checks. These are assertion counts, not that many independent scenarios.

Reproduce the green checks from this revision with its pinned submodules:

make -B -C target/pc/linux/test_http_target test-body-removal test-connect-cleanup test-response-completion
(cd target/pc/linux/test_http_target && ./result/response-completion/test_http)
make -B -C target/pc/linux/test_http_target test-integer-widths

The management build covers the U64-II application only. The full CI container, FPGA/controller/updater build and other product builds were not run locally on this revision.

Download the October 6 host-test and build evidence for the exact revisions below, including raw red/green logs, source/dependency identities and artifact hashes.

Hardware coverage

Earlier hardware evidence covers a combined H1-H4 retail backport on a Commodore 64 Ultimate breadbin, not these refreshed upstream commits. That backport passed 47 native HTTP exchanges and three lifecycle checks, plus a separate 13-exchange refusal/recovery profile. Linux packet capture confirmed genuine TCP refusal. Installation identity relied on operator confirmation; no runtime image hash was available.

No refreshed individual branch was installed on hardware. Ultimate 64 Elite and Ultimate II+L have not been tested here. The hardware record is supporting evidence, not a per-branch hardware pass. The existing October 4 evidence archive contains that earlier evidence; it does not contain the October 6 rerun.

[chrisgleissner]

Hi @araxis ,

thanks for this PR, much appreciated. What is left to be done until this can be opened for review?

Also, please include very clear red/green test evidence and mention the machine against which these tests were performed.

I appreciate you alluded to some testing in your PR description, but it would be best if you could describe the testing done in its own paragraph or chapter. Please have a look at past merged PRs by @barryw , @enver-haase or myself.

Thanks

[araxis]

Thanks for the review. I have separated the testing details into their own section, with the exact revisions, host environment and before/after results. The refreshed candidate passes 1,127 host checks and a clean U64-II management-application build. The description also distinguishes the earlier combined Commodore 64 Ultimate hardware run from these host tests. The local refresh and validation are complete, so this can now be reviewed.

The updated testing section includes the results. Raw logs are on the evidence release page: under Assets, choose http-review-evidence-20261006.zip (direct ZIP download).