[Eljees]

The plain HTTP inbound forwards the first informational response and then treats the next response as final. For an origin sending 103 → 103 → 200, the client receives the two 103 headers but loses the final 200 and its body. Multiple Early Hints responses are explicitly permitted by RFC 8297 §2.

Repeat the existing raw-header forwarding until the final response, retaining the status-prefix and adaptive peek from #7298. Treat 101 Switching Protocols as terminal in this helper so it does not wait for another HTTP response or consume the following opaque bytes. This does not add full Upgrade tunneling to the inbound.

Extend the existing test with no interim response, single 100/103, repeated 103, and 100 → 103, checking the exact forwarded bytes, final status and body through iotest.OneByteReader. Add a bounded 101 termination check. The regression tests use no network, timers or goroutines.

Validation:

• The final regression tests fail on the unmodified base in the two multi-response cases and the 101 case; four other cases pass.
• Actual Xray binary with an owned local HTTP origin: baseline loses the final response for 103 → 103 → 200, while three controls pass; all four cases pass after the fix.
• Windows Go 1.27.3: the three affected packages and seven HTTP scenarios pass (23 leaf cases, no skips); scoped go vet, main build and repository format check pass.
• Linux Go 1.27.1: the same 23 leaf cases pass with -race; scoped go vet and main build pass. The scenario harness is race-instrumented; its unchanged helper builds ordinary child Xray binaries.
• Full repository tests and a local macOS runtime run were not performed.

AI assistance: Codex assisted with implementation, tests and review.

[RPRX]

相近修改能一次性放到一个 PR 里吗，不要一会儿蹦一个

[Fangliding]

够用就行了 plain mode 跑这些个应该已经非常少见了