Hvor du finner CONNECT-svarhodene til en proxy
Se på CONNECT-utvekslingen når et proxy-spesifikt diagnostikkfelt mangler i destinasjonens svarobjekt.
Et diagnostikkfelt i proxyens CONNECT-svar tilhører et annet svar enn nettstedets senere svar. Et destinasjonssvarobjekt på høyt nivå kan bare vise det siste.
| Transportgrensesnitt | Hvor CONNECT-metadata vises |
|---|---|
| Pythons standard-API for HTTP-tilkobling, 3.12+ | get_proxy_response_headers() returnerer CONNECT-svarhodene, eller None når CONNECT ikke ble sendt. |
| libcurls headerinnsamling | CONNECT-hoder kan inkluderes. CURLOPT_SUPPRESS_CONNECT_HEADERS styrer leveringen av dem gjennom de relevante headerutgangsveiene. |
For Guzzles cURL-handler, fang hver svarlokk med on_headers i stedet for å bare se på svaret som returneres. Bruk det støttede grensesnittet til klienten som faktisk gjør forespørselen. Et bibliotek bygget oppå Python viser ikke nødvendigvis tilkoblingsmetoden i svaret sitt, og en separat tilkoblingsinstans kan ikke avsløre denne utvekslingen. Å undertrykke libcurls CONNECT-hoder kan forenkle en parser, men skjuler beviset diagnosen trenger.
Hvis feltet fortsatt mangler, sjekk operatørens dokumenterte betingelser for produkt, metode og resultat. En videresendt forespørsel i klartekst og en ugjennomsiktig HTTPS-tunnel kan vise metadata forskjellig; et leverandørfelt er ikke en obligatorisk del av hvert svar.
Hold definisjonen av feltet sammen med verdien. En returnert IP kan beskrive lytteren, den lokale bindingen, den valgte utgangen eller destinasjonen. Bare formen identifiserer ikke kilden som nettstedet ser.