Proxy-CONNECT-tydsperrings nadat die TCP-verbinding slaag
Spoor die tydsperring op wat tydens CONNECT aktief is, eerder as om te aanvaar dat 'n voltooide TCP-verbinding ook die tonnelopstelling voltooi het.
'n TCP-verbindingstydsperring het sy werk gedoen sodra die kliënt aan die proxy koppel. Die volgende wag—om 'n volledige CONNECT-antwoord te ontvang—kan deur 'n ander tydhouer beheer word.
Die proxy is dalk nog besig om opstroom te koppel, stawingsboodskappe uit te ruil of op 'n ander diens te wag. Die webwerf se gewone antwoord het nog nie begin nie.
| Laaste voltooide stap | Waarop word nog gewag? |
|---|---|
| TCP aan die proxy gekoppel | Die proxy-handskud, insluitend aanvaarding van CONNECT |
| CONNECT aanvaar | Bestemming-TLS, wanneer die teiken dit gebruik |
| Bestemmingsversoek gestuur | Die bestemming se antwoord |
Vind die tydhouer wat aktief is terwyl die koppelaar daardie handskud lees en skryf. 'n Eienskap genaamd “response timeout” tree dalk eers in werking nadat die roete gevestig is. By HttpClient 5 moet jy ConnectionConfig en sy socket-tydsperring, die TLS-handskudkonfigurasie en die versoekvlak-respons-tydsperring onderskei. Pas die betrokke verbindingskonfigurasie toe via die bestuurder wat die werklike kliënt gebruik. Ou Apache HttpClient-generasies gebruik ander API's, so 'n ouer brokkie is nie 'n betroubare kaart van hierdie verantwoordelikhede nie.
Hou 'n finale CONNECT-verwerping as 'n proxy-antwoord. 'n Geslaagde antwoord gevolg deur 'n TLS-stilstand is 'n ander faset van die mislukking. “TCP gekoppel; geen volledige CONNECT-antwoord voor die opstellingsperdatum nie” beskryf die probleem noukeuriger as 'n generiese proxy-tydsperring.
'n algehele sperdatum kan die oproeper se wag langs hierdie fasegrense beperk. Wanneer dit verstryk, kanselleer of sluit die bewerking deur die lewensiklus wat die kliënt ondersteun, voordat 'n volgende poging verbindingskapasiteit opgebruik.