AIKIDO-2026-967860

TL;DR

The HTTP/1 dispatch loop in src/proto/h1/dispatch.rs can keep re-polling without making progress when a peer half-closes the connection while an outgoing request body is still open. The can_write_again check only confirms that a body channel exists, and the write-continuation path treats an always-ready poll_flush as progress, so the connection task never parks. A remote peer that sends FIN without responding while the client streams a request body leaves the client task spinning at full CPU on that core until the next body frame is produced. The fix re-checks write readiness safely and requires the connection to still be in a body-writing state before continuing the loop.