ioxide: send the FIN when the request asked for Connection: close

[MDA2AV]

The diagnosis in #1289 was wrong

ioxide was disabled as one of twelve entries that "fail 100% of offsets" in the exhaustive fragmentation check. Its parser is fine. It reassembles fragmented requests correctly at every split offset, with and without pauses between the writes, and at 384 concurrent partial connections.

What it never did was close the connection — not even when it put Connection: close in its own response header. Still open twenty seconds later, leaking a descriptor per request.

validate-frag.py reads to EOF and its shapes send connection: close, so it blocked until its own socket timeout and reported:

timeout (server never answered or never closed)

which the sweep recorded as a fragmentation failure across all nine shapes. Worth remembering when reading any 100%-of-offsets result: an entry that answers correctly and never closes looks identical to one that cannot parse at all.

Where the fix belongs

Here, not in ioxide. Connection: close is an HTTP decision and ioxide is a transport that knows nothing about HTTP.

The entry already made the decision correctly — HttpSession sets WantClose from a case-insensitive match and HandleAsync returns on it, which I confirmed: a second request on the same socket is ignored. What it lacked was a way to act on it.

TcpConnection exposes no Close or Shutdown on the pinned 0.4.169 or the current 0.7.210 (conn.Close() does not compile against either; Dispose() compiles and does not close). It does expose the accepted descriptor, which is enough:

int fd = conn.ClientFd;
if (fd >= 0) Shutdown(fd, SHUT_WR);

SHUT_WR rather than close(2) on purpose: the descriptor's lifetime belongs to ioxide's refcount, so closing it here would free a number the reactor still holds and the next accept could hand the same integer to somebody else.

GenHTTP.Engine.Ioxide solves it the same way — its assembly references libc and shutdown — so this is the idiomatic answer for an HTTP layer on ioxide rather than a workaround. An upstream TcpConnection.ShutdownWrite() would still beat every consumer reaching for P/Invoke.

Result

	before	after
fragmentation	0 passed, 9 failed (every offset a timeout)	9 passed, 0 failed

Connection: close is honoured in every casing, whole or split; keep-alive still reuses the socket across requests.

Still disabled

52 other checks fail, in three groups, none related to this:

• TLS is dead. The handshake passes — mounted certificate, TLS 1.3, ALPN — but no HTTP comes back over 8081 or 8443, just Empty reply from server. A pristine build of the entry fails identically, so this is not the shutdown change. It takes json-tls, static-tls, baseline-h2, static-h2 and both h3 profiles with it.
• POST /upload chunked answers 0 rather than counting the body.
• Static files do not follow the disk — replaced files keep serving the old bytes, so the entry is caching at startup rather than reading the mount.

Re-enabling needs those three fixed. This lands the close fix and corrects the record on why it was disabled.

🤖 Generated with Claude Code