https #6
2026-07-28
test(https): give the TLS tests ports of their own
The new tests reused ports the existing suite already binds — 8095 with ShouldSurviveAbuseHTTP1, and 8097/8098 with ShouldFallbackUnknownRoutes' plaintext and HTTP/3 listeners. SO_REUSEADDR does not let two live listeners share a port, so under the parallel runner whichever bound second failed, and which test that was came down to scheduling. Move the TLS tests to 8110-8114, which nothing else uses. That collision also showed up as a SIGABRT rather than a reported error, so harden the path it took: ~ListenerHTTP1 calls Stop(), which joins threads and touches sockets and can therefore throw. A second listener failing to bind unwinds past a live first one, and a throw out of its destructor mid-unwind terminates the process — turning a diagnosable bind failure into a crash. Swallow it there, where there is nothing left to report it to. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
docs: describe HTTPS, the TLS layer, and its system dependency
The HTTP/1.1 section promised the opposite of what the code now does — a "No TLS" heading stating there was no plan to link a TLS stack into this path. Replace it with what to actually pass, and lead with the part that gets deployed wrong: verifying the chain without the hostname is not a check, and a private trust anchor is the answer for a self-signed peer rather than insecureNoServerValidation. Also document :Stream and :TLS as modules in their own right — TLSStream is a ByteStream over any descriptor, not something only HTTP can use — and record libssl as a system dependency, including why it is not vendored the way msquic is. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
fix(tls): stop a peer that closed first from killing the process
OpenSSL's socket BIO writes with write(2) rather than send(2), so unlike PlainStream it cannot pass MSG_NOSIGNAL. Writing to a peer that is gone therefore raised SIGPIPE, and with the default disposition that takes the whole process down. This is not an edge case. It fires on any teardown where the far side closed first, because SSL_shutdown still tries to put a close_notify on the wire — which is exactly what ShouldSendRecieveHTTPS1 does when it drops a client whose certificate check failed. The test died on SIGPIPE with every assertion passing. Installing a process-wide SIG_IGN would fix it by changing how the caller's own writes report failure, which a library has no business doing. SIGPIPE from write(2) is delivered to the writing thread, so block it for that thread across each OpenSSL call instead and drain any pending instance before unblocking. A caller who already blocks SIGPIPE is left untouched — a pending signal there may be theirs to consume. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
test(https): cover the TLS transport from three angles
ShouldSendRecieveHTTPS1 replays the plaintext round-trip over TLS, so a
regression in the transport shows up as an HTTP failure rather than
nothing at all, and adds what only exists under TLS: ALPN, scheme=https
reaching handlers, a body spanning many records, and the two ways
verification must fail — an untrusted self-signed certificate, and a
trusted certificate presented for the wrong name. A plaintext peer
knocking on the TLS port is asserted to be counted and shrugged off.
ShouldInteropCurlHTTPS1 puts real implementations on the other end, since
two OpenSSL peers can agree on a mistake. curl verifies our certificate
with --cacert rather than --insecure, and an h2-only curl is asserted to
be refused rather than mis-served. python3's http.server behind
ssl.wrap_socket answers HTTP/1.0 with Connection: close, which frames the
body by close_notify — the path a reader is most likely to get wrong.
ShouldRequireClientCertificateHTTPS1 covers mutual TLS both ways, and
drives TLSStream directly with hand-written HTTP/1.1 to keep the :TLS
layer honest as something usable without :ClientHTTP1 on top.
Also fix a delegation that `{}` no longer disambiguates now that a
three-argument TLS constructor exists alongside the fallback one.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
feat(tls): add a libssl TLS transport and an https:// HTTP/1.1 stack
HTTP/1.1 was plaintext-only, which left `https://` to either an HTTP/3
listener or a terminating proxy in front. Neither helps the callers this
stack exists for — curl scripts, CI tooling, old proxies — so wrap the
transport in libssl instead.
Two new partitions:
:Stream a ByteStream with per-call deadlines on both directions, plus
the plaintext socket implementation. The HTTP/1.1 client and
listener now hold a ByteStream& and never learn which
transport they have, which is what lets one code path serve
both schemes.
:TLS TLSContext/TLSStream over OpenSSL 3, with credentials for both
roles: chain and hostname verification on by default, private
trust anchors, client certificates, mutual TLS, ALPN, and an
in-process self-signed certificate for development.
Both descriptors go non-blocking and every read and write is driven by
poll() against a deadline. That is required for TLS — a blocking
descriptor cannot express a handshake timeout — and it means a plaintext
write can now time out too, instead of parking forever against a peer
that stopped reading.
ClientHTTP1 and ListenerHTTP1 gain credential-taking constructors; the
existing ones still speak http://. The listener handshakes on the
connection's own thread, so a peer that stalls mid-handshake costs one
thread rather than the accept loop, and a failed handshake is counted
rather than logged — on a public port it is ordinary traffic.
MessageParser gains SetDefaultScheme so origin-form targets report the
scheme the transport actually used; handlers shared with ListenerHTTP now
see the same "https" they would over HTTP/3.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>