
Eine offene Testplattform, die HTTP/1.1-Server auf RFC 9110/9112-Anforderungen, Smuggling Vectors und die Verarbeitung fehlerhafter Eingaben überprüft. Fügen Sie Ihr Framework hinzu und erhalten Sie automatisch Compliance-Ergebnisse.
Http11Probe ist ein Compliance- und Sicherheitstester für HTTP/1.1-Server. Es sendet fehlerhafte, mehrdeutige und überdimensionierte Anfragen über rohe TCP-Sockets an einen Server und prüft, wie dieser auf die tatsächlichen Anforderungen von RFC 9110 und RFC 9112 reagiert. Dabei handelt es sich um die kniffligen Fälle wie bare LF-Zeilenenden, veraltete Zeilenfaltung, CL/TE-Request-Smuggling, Chunk-Framing-Tricks, überdimensionierte Header und NUL-Bytes, bei denen ein strikter und ein großzügiger Parser anfangen, sich zu unterscheiden.
Dieselben 215 Tests werden gegen 41 Referenzserver ausgeführt, die in 12 Sprachen geschrieben sind, von Nginx, Apache und Envoy bis zu Kestrel, Gin, Actix und den integrierten Servern in Node, Bun und Deno. Jedes Ergebnis wird anhand der MUST/SHOULD/MAY-Formulierungen in der Spezifikation bewertet und als Bestanden, Fehlgeschlagen oder Warnung markiert. Eine Warnung bedeutet lediglich, dass der RFC sowohl das strikte als auch das großzügige Verhalten erlaubt, sodass keines von beiden falsch ist.
Die vollständige Dokumentation, ein testbezogenes Glossar mit RFC-Zitaten und die Live-Ergebnismatrix für jeden Server finden Sie unter http-probe.com.
Der Probe ist zielunabhängig. Er testet jeden HTTP/1.1-Server, der bereits auf --host:--port lauscht, und es gibt kein Flag zur Auswahl eines Frameworks. Starten Sie zuerst den Server (oder lassen Sie probe-local.sh einen für Sie hochfahren) und richten Sie dann den Probe darauf aus.
dotnet run --project src/Http11Probe.Cli -- --host localhost --port 8080
| Flag | Beschreibung | Standard |
|---|---|---|
--host | Zielhostname oder IP-Adresse | localhost |
--port | Zielportnummer | 8080 |
--category | Nur Tests in dieser Kategorie ausführen (Compliance, Smuggling, MalformedInput, Normalization, Cookies, Capabilities) | alle |
--test | Nur bestimmte Test-IDs ausführen (Groß-/Kleinschreibung nicht beachtet, wiederholbar) | alle |
--timeout | Verbindungs- und Lese-Timeout in Sekunden pro Test | 5 |
--output | JSON-Ergebnisse in Datei schreiben | keine |
--verbose, -v | Rohe Serverantwort für jeden Test ausgeben | aus |
dotnet run --project src/Http11Probe.Cli -- --host localhost --port 8080 --output results.json
Bestimmte Tests ausführen:
dotnet run --project src/Http11Probe.Cli -- --test SMUG-CL-TE-BOTH --test SMUG-DUPLICATE-CL
Die Ergebnisse werden nach Abschluss jedes Tests auf der Konsole ausgegeben, mit einer Zusammenfassung am Ende:
Punktzahl: 97/97 19 Warnungen (146 Tests, 35,5s)
Der Probe sendet nur Anfragen, er startet keine Server. Um einen der gebündelten Server unter src/Servers/ zu testen, verwenden Sie scripts/probe-local.sh. Er macht dasselbe wie die CI-Pipeline: das Docker-Image des Servers erstellen, es mit --network host ausführen, warten, bis es bereit ist, es testen und dann abbauen.
# Probe one server by its directory name under src/Servers/, e.g. ActixServer
scripts/probe-local.sh --server ActixServer
# Probe every bundled server
scripts/probe-local.sh --all
Der Wert von --server ist der Verzeichnisname (ActixServer), nicht der Anzeigename (Actix). Wenn Ihr Docker-Daemon Root-Rechte benötigt, fügen Sie --docker-sudo hinzu, damit Sie nicht das gesamte Skript mit sudo ausführen müssen:
scripts/probe-local.sh --server ActixServer --docker-sudo
| Flag | Beschreibung |
|---|---|
--server <Dir> | Einen einzelnen Server anhand seines Verzeichnisnamens unter src/Servers/ testen (z.B. NginxServer) |
--all | Jeden Server unter src/Servers/*/probe.json testen |
--port <Port> | Zielport (Standard: 8080) |
--skip-build | dotnet build überspringen (geht von einem bereits vorhandenen Release-Build aus) |
--verbose | --verbose an die CLI übergeben |
--docker-sudo | Docker-Befehle mit sudo ausführen (ermöglicht die Ausführung des Skripts ohne sudo) |
-h, --help | Hilfe anzeigen |
Es schreibt probe-<ServerDir>.json (eines pro Server) sowie probe-data.js und docs/static/probe/data.js für die lokale Darstellung. Sie benötigen jq, docker, curl, python3 und das .NET 10 SDK.
probe-local.sh ist nur ein praktischer Wrapper. Wenn Sie es lieber manuell machen möchten, z.B. um einen Server über mehrere Testläufe hinweg laufen zu lassen, erstellen und starten Sie den Container selbst und richten Sie dann den Probe darauf aus. Führen Sie diese Befehle aus dem Repository-Stammverzeichnis aus, da dies der Docker-Build-Kontext ist:
docker build -t probe-actix -f src/Servers/ActixServer/Dockerfile .
docker run -d --name probe-target --network host probe-actix
dotnet run --project src/Http11Probe.Cli -- --host localhost --port 8080
docker rm -f probe-target
Sie können den Probe auch auf einen bereits laufenden HTTP/1.1-Server ausrichten:
dotnet run --project src/Http11Probe.Cli -- --host localhost --port 9000
Erfordert das .NET 10 SDK.
dotnet build Http11Probe.slnx
Der Probe-Workflow wird bei Pull-Requests und workflow_dispatch ausgeführt. Er erstellt das Docker-Image jedes Servers, testet es und veröffentlicht eine Vergleichstabelle als PR-Kommentar.