Afatet kohore të CONNECT në proxy pas një lidhjeje TCP të suksesshme
Gjeni afatin kohor aktiv gjatë CONNECT në vend që të supozoni se një lidhje TCP e përfunduar ka përfunduar edhe konfigurimin e tunelit.
Afati kohor i lidhjes TCP e ka bërë punën e tij sapo klienti lidhet me proxy-n. Pritja tjetër—marrja e një përgjigjeje të plotë CONNECT—mund të qeveriset nga një kohëmatës tjetër.
Prox-y mund të jetë ende duke u lidhur në rrjedhën e sipërme, duke shkëmbyer mesazhe vërtetimi ose duke pritur një shërbim tjetër. Përgjigja e zakonshme e faqes nuk ka filluar ende.
| Hapi i fundit i përfunduar | Çfarë pritet ende? |
|---|---|
| TCP i lidhur me proxy-n | Shtrëngimi i duarve i proxy-t, përfshirë pranimin e CONNECT |
| CONNECT i pranuar | TLS i destinacionit, kur objektivi e përdor |
| Kërkesa drejt destinacionit e dërguar | Përgjigja e destinacionit |
Gjeni kohëmatësin që është aktiv ndërsa lidhësi lexon dhe shkruan atë shtrëngim duarsh. Një veti e quajtur “response timeout” mund të hyjë në fuqi vetëm pasi të vendoset rruga. Në HttpClient 5, dalloni ConnectionConfig dhe afatin e tij kohor të socket-it, konfigurimin e shtrëngimit të duarve TLS dhe afatin kohor të përgjigjes në nivel kërkese. Zbatoni konfigurimin përkatës të lidhjes përmes menaxherit që përdor klienti aktual. Gjeneratat e vjetra të Apache HttpClient përdorin API të ndryshme, prandaj një fragment më i vjetër nuk është hartë e besueshme e këtyre përgjegjësive.
Mbajeni refuzimin përfundimtar të CONNECT si përgjigje të proxy-t. Një përgjigje e suksesshme e ndjekur nga një ngecje TLS është një fazë tjetër dështimi. „TCP i lidhur; asnjë përgjigje e plotë CONNECT përpara afatit të konfigurimit“ e përshkruan problemin më saktë sesa një afat kohor i përgjithshëm i proxy-t.
Një afat kohor i përgjithshëm mund të kufizojë pritjen e thirrësit përbri këtyre kufijve të fazave. Kur skadon, anuloni ose mbyllni operacionin përmes ciklit të jetës që mbështet klienti, përpara se një provë tjetër të konsumojë kapacitetin e lidhjes.