Expirări CONNECT ale proxy-ului după o conexiune TCP reușită
Identificați expirarea activă în timpul CONNECT în loc să presupuneți că o conexiune TCP finalizată a terminat și configurarea tunelului.
Expirarea conexiunii TCP și-a făcut treaba în momentul în care clientul se conectează la proxy. Următoarea așteptare—primirea unui răspuns CONNECT complet—poate fi guvernată de un alt temporizator.
Este posibil ca proxy-ul să se conecteze încă în amonte, să schimbe mesaje de autentificare sau să aștepte un alt serviciu. Răspunsul obișnuit al site-ului nu a început încă.
| Ultimul pas finalizat | Ce se mai așteaptă? |
|---|---|
| TCP conectat la proxy | Handshake-ul proxy-ului, inclusiv acceptarea CONNECT |
| CONNECT acceptat | TLS-ul destinației, când ținta îl folosește |
| Cererea către destinație trimisă | Răspunsul destinației |
Găsiți temporizatorul activ în timp ce conectorul citește și scrie acel handshake. O proprietate numită „response timeout” poate intra în vigoare doar după stabilirea rutei. La HttpClient 5, distingeți ConnectionConfig și expirarea sa de socket, configurația handshake-ului TLS și expirarea răspunsului la nivel de cerere. Aplicați configurația de conexiune relevantă prin managerul folosit de clientul real. Generațiile vechi de Apache HttpClient folosesc API-uri diferite, așa că un fragment mai vechi nu este o hartă fiabilă a acestor responsabilități.
Păstrați un refuz final de CONNECT ca răspuns al proxy-ului. Un răspuns reușit urmat de o blocare TLS este o altă etapă de eșec. „TCP conectat; niciun răspuns CONNECT complet înainte de termenul de configurare” descrie problema mai precis decât o expirare generică a proxy-ului.
Un termen global poate limita așteptarea apelantului alături de aceste limite de fază. Când expiră, anulați sau închideți operațiunea prin ciclul de viață acceptat de client înainte ca o nouă încercare să consume capacitate de conexiune.