
Una piattaforma di test aperta che sonda i server HTTP/1.1 rispetto ai requisiti RFC 9110/9112, ai vettori di smuggling e alla gestione di input malformati. Aggiungi il tuo framework, ottieni automaticamente i risultati di conformità.
Http11Probe è un tester di conformità e sicurezza per server HTTP/1.1. Invia richieste malformate, ambigue e sovradimensionate a un server tramite socket TCP grezzi e verifica come risponde rispetto a ciò che RFC 9110 e RFC 9112 richiedono effettivamente. Questi sono i casi scomodi come terminazioni di riga con LF singolo, line folding obsoleto, request smuggling CL/TE, trucchi di chunk-framing, header sovradimensionati e byte NUL, dove un parser rigoroso e uno indulgente iniziano a divergere.
Gli stessi 215 test vengono eseguiti su 42 server di riferimento scritti in 12 linguaggi, da Nginx, Apache ed Envoy a Kestrel, Gin, Actix e i server integrati in Node, Bun e Deno. Ogni risultato viene valutato rispetto alla formulazione MUST/SHOULD/MAY nella specifica e contrassegnato come Pass, Fail o Warn. Un Warn significa semplicemente che l'RFC consente sia il comportamento rigoroso che quello indulgente, quindi nessuno dei due è sbagliato.
Troverai la documentazione completa, un glossario per-test con citazioni RFC e la matrice dei risultati live per ogni server su http-probe.com.
Il probe è agnostico rispetto al target. Testa qualunque server HTTP/1.1 sia già in ascolto su --host:--port, e non c'è alcun flag per scegliere un framework. Avvia prima il server (oppure lascia che probe-local.sh ne avvii uno per te), poi punta il probe verso di esso.
dotnet run --project src/Http11Probe.Cli -- --host localhost --port 8080
| Flag | Descrizione | Default |
|---|---|---|
--host | Hostname o indirizzo IP di destinazione | localhost |
--port | Numero di porta di destinazione | 8080 |
--category | Esegui solo i test in questa categoria (Compliance, Smuggling, MalformedInput, Normalization, Cookies, Capabilities) | tutti |
--test | Esegui solo specifici ID di test, case-insensitive (ripetibile) | tutti |
--timeout | Timeout di connessione e lettura in secondi per test | 5 |
--output | Scrivi i risultati JSON su file | nessuno |
--verbose, -v | Stampa la risposta grezza del server per ogni test | off |
dotnet run --project src/Http11Probe.Cli -- --host localhost --port 8080 --output results.json
Esegui test specifici:
dotnet run --project src/Http11Probe.Cli -- --test SMUG-CL-TE-BOTH --test SMUG-DUPLICATE-CL
I risultati vengono trasmessi alla console man mano che ogni test viene completato, con un riepilogo alla fine:
Score: 97/97 19 warnings (146 tests, 35.5s)
Il probe invia solo richieste, non avvia server. Per testare uno dei server inclusi sotto src/Servers/, usa scripts/probe-local.sh. Fa la stessa cosa della pipeline CI: costruisce l'immagine Docker del server, la esegue su --network host, attende che si avvii, la testa, poi la smonta.
# Testa un server tramite il nome della sua directory sotto src/Servers/, ad es. ActixServer
scripts/probe-local.sh --server ActixServer
# Testa ogni server incluso
scripts/probe-local.sh --all
Il valore di --server è il nome della directory (ActixServer), non il nome visualizzato (Actix). Se il tuo daemon Docker richiede root, aggiungi --docker-sudo così non devi eseguire l'intero script con sudo:
scripts/probe-local.sh --server ActixServer --docker-sudo
| Flag | Descrizione |
|---|---|
--server <Dir> | Testa un singolo server tramite il nome della sua directory sotto src/Servers/ (ad es. NginxServer) |
--all | Testa ogni server sotto src/Servers/*/probe.json |
--port <Port> | Porta di destinazione (default: 8080) |
--skip-build | Salta dotnet build (presuppone che esista già una build Release) |
--verbose | Passa --verbose alla CLI |
--docker-sudo | Esegui i comandi Docker tramite sudo (ti permette di eseguire lo script senza sudo) |
-h, --help | Mostra l'aiuto |
Scrive probe-<ServerDir>.json (uno per server), più probe-data.js e docs/static/probe/data.js per il rendering locale. Avrai bisogno di jq, docker, curl, python3 e .NET 10 SDK.
probe-local.sh è solo un wrapper di comodità. Se preferisci farlo a mano, ad esempio per mantenere un server attivo attraverso diverse esecuzioni del probe, costruisci ed esegui il container da solo, poi punta il probe verso di esso. Esegui questi comandi dalla root del repo, dato che è il contesto di build Docker:
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
Puoi anche puntare il probe verso qualunque server HTTP/1.1 che hai già in esecuzione:
dotnet run --project src/Http11Probe.Cli -- --host localhost --port 9000
Richiede .NET 10 SDK.
dotnet build Http11Probe.slnx
Il workflow Probe viene eseguito sulle pull request e su workflow_dispatch. Costruisce l'immagine Docker di ogni server, la testa e pubblica una tabella di confronto come commento alla PR.