Repository navigation
Conversation
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.
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.
Http11Probe — Compliance Comparison
✅ Baseline PassedCompliance
Smuggling
Malformed Input
Header Normalization
Commit: 3fd5355 |
… 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.
|
|
Re-pinned to the library's Measured locally with this entry's own The two remaining scored ❌ are deliberate leniency, not oversights — The |



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.