CONNECT-tidsavbrot i proxy etter vellukka TCP-tilkopling
Finn tidsavbrotet som er aktivt under CONNECT i staden for å gå ut frå at ei fullført TCP-tilkopling også har fullført tunneloppsettet.
Eit TCP-tilkoplingstidsavbrot har gjort jobben sin når klienten koplar til proxyen. Den neste ventinga—å ta imot eit fullstendig CONNECT-svar—kan styrast av ein annan timer.
Proxyen koplar kanskje framleis til oppstraums, byter autentiseringsmeldingar eller ventar på ei anna teneste. Det vanlege svaret frå nettstaden har ikkje byrja enno.
| Siste fullførte steg | Kva vert det framleis venta på? |
|---|---|
| TCP kopla til proxyen | Handtrykket til proxyen, inkludert godkjenning av CONNECT |
| CONNECT godkjend | TLS til destinasjonen, når målet brukar det |
| Førespurnad til destinasjonen send | Svaret frå destinasjonen |
Finn timeren som er aktiv medan tilkoplinga les og skriv dette handtrykket. Ein eigenskap kalla «response timeout» trer kanskje først i kraft etter at ruta er etablert. Med HttpClient 5 må du skilje mellom ConnectionConfig og socket-tidsavbrotet til det, TLS-handtrykkskonfigurasjonen og tidsavbrotet for svar på førespurnadsnivå. Bruk den relevante tilkoplingsoppsettet gjennom behandlaren som den faktiske klienten brukar. Eldre generasjonar av Apache HttpClient brukar andre API-ar, så ein eldre kodesnutt er ikkje eit påliteleg kart over desse ansvara.
Hald ei endeleg CONNECT-avvising som eit svar frå proxyen. Eit vellukka svar etterfølgd av ein TLS-stans er ein annan feilfase. «TCP tilkopla; ingen fullstendig CONNECT-svar før oppsettsfristen» skildrar problemet meir presist enn eit generisk proxy-tidsavbrot.
Ein samla frist kan avgrense ventinga til den kallande saman med desse fasegrensene. Når han går ut, avbryt eller lukk operasjonen gjennom livssyklusen klienten støttar, før eit nytt forsøk brukar tilkoplingsevne.