Repository navigation
Add Swerver target (Zig HTTP/1.1+2+3 server) - #131
Merged
Merged
Conversation
Swerver is a high-performance HTTP/1.1+2+3 server and API gateway written in Zig 0.16. This adds a probe target that builds swerver from source and serves the root/echo/cookie contract on port 8080. The Dockerfile clones swerver main and builds a small probe app against it (ReleaseFast). config.json points static_root at /app/docroot.
- Run the runtime container as the unprivileged 'nobody' user (mirrors TrilliumServer). Verified PID 1 runs as uid 65534 and the probe still scores 160/161 (io_uring init is unaffected). - Add --proto '=https' --tlsv1.2 to the Zig download curl so a redirect can't downgrade to plaintext. Base stays Debian trixie (documented inline): swerver's HTTP/3 path links OpenSSL 3.5's QUIC TLS API, absent from bookworm's OpenSSL 3.0.
|
Http11Probe — Compliance Comparison
✅ Baseline PassedCompliance
Smuggling
Malformed Input
Header Normalization
Commit: 6e3ccbe |
Antruly
added a commit
to Antruly/Http11Probe
that referenced
this pull request
Oct 10, 2026
Criterion: SonarCloud's automatic analysis must pass the Quality Gate on this PR. Read from the API rather than guessed: the `SonarCloud Code Analysis` check-run on the head commit was `failure`, `Quality Gate failed`, and it named exactly one failed condition -- "C Security Rating on New Code". The three annotations resolve to `docker:S6506` (VULNERABILITY, MAJOR) on the Dockerfile's `curl`: "Not enforcing HTTPS here might allow for redirections to insecure websites", plus `docker:S7018` and `docker:S7026`, both CODE_SMELL MINOR and neither of which gates. `--proto '=https' --proto-redir '=https' --tlsv1.2` is the fix. The repo's only other Dockerfile that downloads an artifact -- SwerverServer, added by MDA2AV#131 -- already carries the same flags, and that PR's analysis is clean: zero unresolved issues on its new code. The package list is sorted as well, clearing `docker:S7018`. `docker:S7026` ("Replace this invocation of curl with the ADD instruction") is deliberately left standing: ADD takes no checksum, so obeying it would drop the sha256 check that is what pins which bytes get built. No server behaviour changes -- server.cpp, the endpoints and the routing are untouched, and the compiled binary is identical. Only the transport of the pinned archive and one comment line are.
MDA2AV
pushed a commit
that referenced
this pull request
Oct 11, 2026
* feat(libuvcpp): add the libuvcpp HTTP framework to the probe Adds src/Servers/LibuvcppServer/ (Dockerfile, probe.json, server.cpp) and docs/content/servers/libuvcpp.md. libuvcpp is a C++11 HTTP framework built on libuv's event loop; its three endpoints are served through `uvcpp_web_app`, the library's documented high-level server, so the catch-all, the HEAD-to-GET fallback and the automatic OPTIONS answer are all the framework's own behaviour rather than a router written for this probe. Criterion: the probe's own suite, run against the entry. Measured locally with this repo's own code, built from this tree (`dotnet run --no-build -c Release --project src/Http11Probe.Cli -- --host 127.0.0.1 --port 8092`): 149/159 -- 132 pass, 17 warn, 10 scored fail, 0 error, 213 tests. Both baseline gates pass, and no response in the run was a 5xx. The ten scored failures are all message-level properties of the library's parser, not of this entry: Host is not validated (missing, duplicate, empty, userinfo, path, comma-separated), obs-fold is accepted, `Transfer-Encoding:` with an empty value is accepted, and HTTP/1.2 is rejected with 400 where the RFC asks for 1.x tolerance. The Dockerfile downloads the pinned v1.6.0 linux-x64 release package and compiles server.cpp against it. The sha256 in the Dockerfile, b64ae68d121b49543e7a37126bbf38adf95a00ac51bff463b11be2dc499a138b, was checked against the published asset before this commit, and the g++ line is the same one used for the local run above. README.md: 41 -> 42 reference servers, since this adds the 42nd server page. * fix(libuvcpp): hold the entry's download to HTTPS, redirects included Criterion: SonarCloud's automatic analysis must pass the Quality Gate on this PR. Read from the API rather than guessed: the `SonarCloud Code Analysis` check-run on the head commit was `failure`, `Quality Gate failed`, and it named exactly one failed condition -- "C Security Rating on New Code". The three annotations resolve to `docker:S6506` (VULNERABILITY, MAJOR) on the Dockerfile's `curl`: "Not enforcing HTTPS here might allow for redirections to insecure websites", plus `docker:S7018` and `docker:S7026`, both CODE_SMELL MINOR and neither of which gates. `--proto '=https' --proto-redir '=https' --tlsv1.2` is the fix. The repo's only other Dockerfile that downloads an artifact -- SwerverServer, added by #131 -- already carries the same flags, and that PR's analysis is clean: zero unresolved issues on its new code. The package list is sorted as well, clearing `docker:S7018`. `docker:S7026` ("Replace this invocation of curl with the ADD instruction") is deliberately left standing: ADD takes no checksum, so obeying it would drop the sha256 check that is what pins which bytes get built. No server behaviour changes -- server.cpp, the endpoints and the routing are untouched, and the compiled binary is identical. Only the transport of the pinned archive and one comment line are. * chore(libuvcpp): pin the entry to v1.6.2, the release that closes the Host/TE holes The entry was pinned to v1.6.0. Upstream cut v1.6.2 (2026-10-11), whose parser is the first to answer 400 to an HTTP/1.1 request with no Host header, with more than one, or with an invalid one (RFC 9112 section 3.2), and to an all-blank Transfer-Encoding (RFC 9112 section 6.1) -- the latter previously fell through to Content-Length framing while keeping the connection alive, which is the smuggling shape. Moving the pin is the whole change: server.cpp is untouched. Measured, not assumed. Downloaded the release asset and hashed it here: GET /repos/Antruly/libuvcpp/releases/assets/629841961 -> 200, 22483830 B sha256sum libuvcpp-1.6.2-linux-x64.zip = 636f07346314d5f5b8fc3dbae34861a6b4441c337fc24a632011c0d7ca72d4fe which is the digest the release API reports for that asset, so the hash in the Dockerfile is a hash of bytes seen, not of bytes promised. The extracted tree is shaped exactly like 1.6.0's (libuvcpp-1.6.2-linux-x64/{include,lib,bindings}, lib/libuvcpp.so and libuvcppd.so), and uvcpp_version.h / uvcpp.pc both read 1.6.2. Then compiled this entry's server.cpp against that package with the Dockerfile's own flags (`g++ -std=c++11 -O2 -DNDEBUG`) and ran the full 213-test probe against the resulting binary on 8080: Score: 157/159 (2 failed, 17 warnings) 54 unscored (213 tests, 54.4s) against 149/159 for the v1.6.0/v1.6.1 packages -- +8, and no previously passing test regressed. Spot-checked directly first: missing Host -> 400, repeated Host -> 400, `Transfer-Encoding:` blank + Content-Length -> 400, a normal GET -> 200. The two remaining scored failures are deliberate leniency, not oversights: RFC9112-5.1-OBS-FOLD section 5.2 lets a server either reject an obs-fold with 400 or fold it to SP; this server folds. Both branches are conformant. COMP-ASTERISK-WITH-GET `GET *` -- section 3.2.4's MUST constrains what a client sends, not what a server must reject. (The third Fail in the report, COMP-HTTP12-VERSION, is unscored: a higher minor version "should" be treated as 1.1, which is a SHOULD in RFC 9110 section 2.5.) Also synced docs/content/servers/libuvcpp.md, which embeds this Dockerfile verbatim -- regenerated the fenced block straight from the file this time, and asserted byte equality, rather than editing both copies by hand.
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
2 participants
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.
Adds a probe target for swerver — a high-performance HTTP/1.1 + HTTP/2 + HTTP/3 server and API gateway written in Zig 0.16 (single-threaded event loop per process — kqueue/epoll/io_uring — with a SO_REUSEPORT fork model).
What's here
src/Servers/SwerverServer/follows the existing target layout:main, builds a small probe app against it withzig build(ReleaseFast), runs it on:8080in a slim runtime image. Build context is the repo root, matching the other targets.{"name": "Swerver", "language": "Zig"}GET /→OK,POST /echoes the body,/echodumps request headers,/cookieparses theCookieheader. Static files served from/app/docroot.Local result
Built and probed the container exactly as
probe-local.shdoes (docker build … && docker run --network host && probe):Adding swerver to the probe surfaced two genuine HTTP/1.1 conformance gaps, both now fixed upstream on swerver
main(so this target builds clean against them):Transfer-Encoding+Content-Lengthconflict (RFC 9112 §6.1 smuggling vector) — now rejected with400and connection close instead of silently droppingContent-Length.400before the header-size limit trips a431.Happy to adjust naming, layout, or the handler contract to match your conventions.