Nepavykusio proxy CONNECT atsakymo turinio tikrinimas su curl

Išsiųskite teisingai sudarytą diagnostinį CONNECT tiesiogiai HTTP proxy serveriui ir atskirai išsaugokite HTTP klaidos antraštes ir turinį.

Proxy, atmetantis CONNECT, gali grąžinti HTTP klaidos dokumentą, paaiškinantį jo politiką arba tolesnio ryšio nesėkmę. Jei diagnozė leidžiama paprastam HTTP proxy, curl gali išsiųsti tą užklausą tiesiogiai ir išsaugoti atsakymą:

curl --proxy '' --http1.1 --max-time 10 \
  --request CONNECT \
  --request-target service.example:443 \
  --header 'Host: service.example:443' \
  --dump-header tunnel.headers \
  --output tunnel.body \
  http://proxy.example:8080/

Paskutinis URL adresuoja proxy klausytoją. Jei leidžiama palyginti viešus proxy, HTTP proxy sąrašas pateikia to klausytojo URL kandidatus. --request pateikia metodo žymę; --request-target pateikia CONNECT įgaliojimą. Juos atskyrus gaunamas CONNECT service.example:443 HTTP/1.1.

Tuščia proxy parinktis neleidžia curl perduoti šios diagnostikos per kitą paveldėtą proxy. Komanda sąmoningai praleidžia --fail, kad HTTP klaidos dokumentas būtų išsaugotas.

Bandymas be autentifikavimo gali sustoti ties 407 dar nepasiekus tiriamos nesėkmės. Atkurdami autentifikuotą užklausą, naudokite proxy numatytą autentifikavimo tvarką.

Tai skirta nesėkmių atsakymams tikrinti. Jei proxy grąžina 2xx, ryšys tampa tuneliu, o ne įprastu HTTP turinio perdavimu. Ši diagnostika su pasirinktiniu metodu nepaleidžia paskirties TLS mainų ir gali pasiekti savo laiko limitą priimtame atvirame tunelyje.

Faktiniam HTTPS gavimui naudokite įprastą --proxy užklausų srautą. Saugokite diagnostikos būseną ir turinį kartu su konkrečiu proxy ir tikslu.

Susiję straipsniai