Adjust the readme for GenHTTP 11 - #889
Draft
Kaliumhexacyanoferrat wants to merge 10 commits into
Draft
Conversation
Kaliumhexacyanoferrat
force-pushed
the
version-11-readme
branch
from
September 3, 2026 14:37
0f5937a to
ccacee4
Compare
Updated dependencies and monitoring tools in the README.
MDA2AV
added a commit
that referenced
this pull request
Sep 3, 2026
…and samples for each The engine had grown a layout that no longer described it. Protocol/ held a folder called Multiplexed - a word that says how HTTP/2 and HTTP/3 differ from HTTP/1.1 without saying which of them anything serves - while Http1/ held a driver alongside its types and the other two folders held a driver alone. ConnectionDriver dispatched TCP connections without TCP appearing in its name, and TlsRegistry was TCP-only for the same unstated reason. The protocol layer is now laid out by what a file does rather than which protocol reaches it, because the protocol is already in every name: Protocol/Drivers/Tcp TcpDriver, Http1Driver, Http2Driver Protocol/Drivers/Quic Http3Driver Protocol/Requests the request model HTTP/2 and HTTP/3 share Protocol/Responses Http1Responder, StreamedResponder, Http1DateHeader Protocol/Sinks where bytes land, for all three That sharing is structural rather than incidental, which is why it survives the move intact. Normalised with protocol names substituted out, Http2Driver and Http3Driver differ only in their entry signature, where their options object is built, and a log string: HTTP/3 was specified to keep HTTP/2's semantics and change the transport, so the six shared types branch on protocol in exactly one ternary. They are named Streamed* now; their HTTP/1.1 counterparts carry an Http1 prefix, so a folder mixing both still reads. Certificate types move to Certificates/ but keep the root namespace, so no consumer needs a new using. QuicTransportOptions splits out of Http3Options along the same line ioxide itself draws. Five of those settings are QUIC or UDP and reach QuicEngine, QuicOptions and UdpOptions; the two QPACK ones are HTTP/3 and reach Nghttp3Options. EngineOptions now reads Reactor / Tcp / Quic / Http3, which makes the transport pair symmetric. Defaults are unchanged, so only a caller that set one of the five has to move it. Http1Responder's body writer folds into WriteAsync - one state machine instead of two on every response with a body - and gains a try/finally, so content is disposed on a HEAD, on a zero-length body, and when the write throws. The streamed path already did that; the TCP path did not, and neither does Shared's ResponseHandler, so this engine is now the outlier in the safe direction. Four more state machines go from the streamed stream adapters, which sat on the per-write path of every HTTP/2 and HTTP/3 body: three pass-throughs on StreamedSink.FlushingStream and one on PullStream. Http1WriterStream was already written this way. Comments were rewritten rather than trimmed: a one-line summary on all 46 types, a line above every method saying what it does, and seventeen inline notes kept for what the code cannot say - why Flush is deliberately a no-op, why the reactors are stopped and then joined, why a chain is built for its elements and its verdict discarded, and why four files in Protocol/Sinks are not the equivalents in Engine.Shared (WritingStream's Flush blocks on FlushAsync, which on a reactor thread waits for a pipe that same thread completes). Playground/Samples/Ioxide carries nine samples in the shape PR #889 uses: one file each for HTTP/1.1, HTTP/2, HTTP/3, TLS, kernel TLS, SNI, rotation, the three-protocol arrangement, and a showcase that is what Program.cs used to be. Program.cs is now the runner. Each sample was started and probed rather than only compiled; kernel TLS could only be checked as far as startup, this machine having no tls module in tcp_available_ulp. Benchmarked against the branch point on the same ioxide 0.7.211, four reactors pinned away from wrk, eight interleaved runs each: 646k req/s against 643k, a 0.44% difference inside a 2% run-to-run spread. No regression.
Kaliumhexacyanoferrat
pushed a commit
that referenced
this pull request
Sep 4, 2026
…and samples for each The engine had grown a layout that no longer described it. Protocol/ held a folder called Multiplexed - a word that says how HTTP/2 and HTTP/3 differ from HTTP/1.1 without saying which of them anything serves - while Http1/ held a driver alongside its types and the other two folders held a driver alone. ConnectionDriver dispatched TCP connections without TCP appearing in its name, and TlsRegistry was TCP-only for the same unstated reason. The protocol layer is now laid out by what a file does rather than which protocol reaches it, because the protocol is already in every name: Protocol/Drivers/Tcp TcpDriver, Http1Driver, Http2Driver Protocol/Drivers/Quic Http3Driver Protocol/Requests the request model HTTP/2 and HTTP/3 share Protocol/Responses Http1Responder, StreamedResponder, Http1DateHeader Protocol/Sinks where bytes land, for all three That sharing is structural rather than incidental, which is why it survives the move intact. Normalised with protocol names substituted out, Http2Driver and Http3Driver differ only in their entry signature, where their options object is built, and a log string: HTTP/3 was specified to keep HTTP/2's semantics and change the transport, so the six shared types branch on protocol in exactly one ternary. They are named Streamed* now; their HTTP/1.1 counterparts carry an Http1 prefix, so a folder mixing both still reads. Certificate types move to Certificates/ but keep the root namespace, so no consumer needs a new using. QuicTransportOptions splits out of Http3Options along the same line ioxide itself draws. Five of those settings are QUIC or UDP and reach QuicEngine, QuicOptions and UdpOptions; the two QPACK ones are HTTP/3 and reach Nghttp3Options. EngineOptions now reads Reactor / Tcp / Quic / Http3, which makes the transport pair symmetric. Defaults are unchanged, so only a caller that set one of the five has to move it. Http1Responder's body writer folds into WriteAsync - one state machine instead of two on every response with a body - and gains a try/finally, so content is disposed on a HEAD, on a zero-length body, and when the write throws. The streamed path already did that; the TCP path did not, and neither does Shared's ResponseHandler, so this engine is now the outlier in the safe direction. Four more state machines go from the streamed stream adapters, which sat on the per-write path of every HTTP/2 and HTTP/3 body: three pass-throughs on StreamedSink.FlushingStream and one on PullStream. Http1WriterStream was already written this way. Comments were rewritten rather than trimmed: a one-line summary on all 46 types, a line above every method saying what it does, and seventeen inline notes kept for what the code cannot say - why Flush is deliberately a no-op, why the reactors are stopped and then joined, why a chain is built for its elements and its verdict discarded, and why four files in Protocol/Sinks are not the equivalents in Engine.Shared (WritingStream's Flush blocks on FlushAsync, which on a reactor thread waits for a pipe that same thread completes). Playground/Samples/Ioxide carries nine samples in the shape PR #889 uses: one file each for HTTP/1.1, HTTP/2, HTTP/3, TLS, kernel TLS, SNI, rotation, the three-protocol arrangement, and a showcase that is what Program.cs used to be. Program.cs is now the runner. Each sample was started and probed rather than only compiled; kernel TLS could only be checked as far as startup, this machine having no tls module in tcp_available_ulp. Benchmarked against the branch point on the same ioxide 0.7.211, four reactors pinned away from wrk, eight interleaved runs each: 646k req/s against 643k, a 0.44% difference inside a 2% run-to-run spread. No regression.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.