Преглед на телото на неуспешен одговор на proxy CONNECT со curl

Испратете правилно составен дијагностички CONNECT директно до HTTP прокси и зачувајте ги HTTP-заглавијата и телото на грешката одделно.

Прокси што го одбива CONNECT може да врати HTTP документ за грешка што ја објаснува неговата политика или неуспехот на следната врска. За дозволена дијагностика кон обичен HTTP прокси, curl може да го испрати барањето директно и да го зачува одговорот:

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/

Конечната URL адреса го адресира слушателот на проксито. За дозволена споредба на јавни проксија списокот на HTTP проксија нуди кандидати за таа URL на слушателот. --request го дава токенот на методот; --request-target го дава овластувањето CONNECT. Нивното одвојување дава CONNECT service.example:443 HTTP/1.1.

Празната опција за прокси спречува curl да ја насочи оваа дијагностика низ друг наследен прокси. Командата намерно го испушта --fail за да може да се зачува HTTP документот за грешка.

Обид без автентикација може да застане на 407 пред да го достигне неуспехот што се истражува. Користете го предвидениот распоред за автентикација на проксито кога репродуцирате автентицирано барање.

Ова е за преглед на одговори при неуспех. Ако проксито врати 2xx, врската станува тунел наместо обичен пренос на HTTP тело. Оваа дијагностика со прилагоден метод не го започнува TLS разменувањето на одредиштето и може да го достигне своето временско ограничување на прифатен отворен тунел.

Користете го вообичаениот тек на барања --proxy за вистинско HTTPS преземање. Чувајте го статусот и телото на дијагностиката со нивното конкретно прокси и цел.

Поврзани статии