
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 test 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 quanto effettivamente richiesto dalle RFC 9110 e RFC 9112. Questi sono i casi scomodi come i finali di riga LF nudi, il line folding obsoleto, lo smuggling di richieste CL/TE, i trucchi di chunk-framing, le intestazioni sovradimensionate e i byte NUL, dove un parser rigoroso e uno indulgente iniziano a divergere.
Gli stessi 215 test vengono eseguiti su 41 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 terminologia MUST/SHOULD/MAY della specifica e contrassegnato come Pass, Fail o Warn. Un Warn significa semplicemente che la 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 è indipendente dal target. Testa qualsiasi server HTTP/1.1 già in ascolto su --host:--port e non c'è un flag per scegliere un framework. Avvia prima il server (oppure lascia che probe-local.sh ne avvii uno per te), quindi punta il probe verso di esso.
dotnet run --project src/Http11Probe.Cli -- --host localhost --port 8080
| Flag | Descrizione | Predefinito |
|---|---|---|
--host | Nome host 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 ID test specifici, senza distinzione tra maiuscole e minuscole (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 eseguire il probe di uno dei server inclusi in 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 sia attivo, lo sonda, poi lo smantella.
# 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
Il valore di --server è il nome della directory (ActixServer), non il nome visualizzato (Actix). Se il tuo demone Docker richiede root, aggiungi --docker-sudo per non dover eseguire l'intero script con sudo:
scripts/probe-local.sh --server ActixServer --docker-sudo
| Flag | Descrizione |
|---|---|
--server <Dir> | Esegue il probe di un singolo server tramite il nome della directory in src/Servers/ (es. NginxServer) |
--all | Esegue il probe di ogni server in src/Servers/*/probe.json |
--port <Port> | Porta di destinazione (predefinita: 8080) |
--skip-build | Salta dotnet build (presuppone che esista già una build Release) |
--verbose | Passa --verbose alla CLI |
--docker-sudo | Esegue i comandi Docker tramite sudo (permette di eseguire lo script senza sudo) |
-h, --help | Mostra 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 manualmente, ad esempio per mantenere un server attivo durante più esecuzioni del probe, costruisci ed esegui il container da solo, poi punta il probe verso di esso. Esegui questi comandi dalla root del repository, poiché è il contesto di build di 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 qualsiasi server HTTP/1.1 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 su pull request e workflow_dispatch. Costruisce l'immagine Docker di ogni server, la sonda e pubblica una tabella di confronto come commento della PR.