CONNECT-tidsavbrudd i proxy etter vellykket TCP-tilkobling
Finn tidsavbruddet som er aktivt under CONNECT i stedet for å anta at en fullført TCP-tilkobling også har fullført tunneloppsettet.
Et TCP-tilkoblingstidsavbrudd har gjort jobben sin når klienten kobler til proxyen. Den neste ventingen—å motta et fullstendig CONNECT-svar—kan styres av en annen timer.
Proxyen kobler kanskje fortsatt til oppstrøms, utveksler autentiseringsmeldinger eller venter på en annen tjeneste. Nettstedets vanlige svar har ikke begynt ennå.
| Siste fullførte trinn | Hva ventes det fortsatt på? |
|---|---|
| TCP koblet til proxyen | Proxyens håndtrykk, inkludert godkjenning av CONNECT |
| CONNECT godkjent | TLS til destinasjonen, når målet bruker det |
| Forespørsel til destinasjonen sendt | Destinasjonens svar |
Finn timeren som er aktiv mens tilkobleren leser og skriver dette håndtrykket. En egenskap kalt «response timeout» trer kanskje først i kraft etter at ruten er etablert. Med HttpClient 5 må du skille mellom ConnectionConfig og dets socket-tidsavbrudd, TLS-håndtrykkskonfigurasjonen og tidsavbruddet for svar på forespørselsnivå. Bruk den relevante tilkoblingskonfigurasjonen gjennom behandleren den faktiske klienten bruker. Eldre generasjoner av Apache HttpClient bruker andre API-er, så en eldre kodesnutt er ikke et pålitelig kart over disse ansvarene.
Behold en endelig CONNECT-avvisning som et svar fra proxyen. Et vellykket svar etterfulgt av en TLS-stans er en annen feilfase. «TCP tilkoblet; ingen fullstendig CONNECT-svar før oppsettsfristen» beskriver problemet mer presist enn et generisk proxy-tidsavbrudd.
En samlet frist kan begrense den kallendes venting sammen med disse fasegrensene. Når den utløper, avbryt eller lukk operasjonen gjennom livssyklusen klienten støtter, før et nytt forsøk bruker tilkoblingskapasitet.