CONNECT-time-outs van de proxy na een geslaagde TCP-verbinding
Bepaal welke time-out actief is tijdens CONNECT in plaats van aan te nemen dat een voltooide TCP-verbinding ook de tunnelopzet heeft afgerond.
Een TCP-verbindingstime-out heeft zijn werk gedaan zodra de client verbinding maakt met de proxy. Het volgende wachten—een volledig CONNECT-antwoord ontvangen—kan door een andere timer worden beheerd.
De proxy maakt mogelijk nog verbinding met de upstream, wisselt authenticatieberichten uit of wacht op een andere dienst. Het gewone antwoord van de website is nog niet begonnen.
| Laatst voltooide stap | Waar wordt nog op gewacht? |
|---|---|
| TCP verbonden met de proxy | De proxy-handshake, inclusief de acceptatie van CONNECT |
| CONNECT geaccepteerd | TLS van de bestemming, wanneer het doel die gebruikt |
| Verzoek aan de bestemming verzonden | Het antwoord van de bestemming |
Zoek de timer die actief is terwijl de connector die handshake leest en schrijft. Een eigenschap met de naam “response timeout” wordt mogelijk pas van kracht na het tot stand brengen van de route. Bij HttpClient 5 onderscheidt u ConnectionConfig en de socket-time-out ervan, de TLS-handshakeconfiguratie en de time-out voor antwoorden op verzoekniveau. Pas de relevante verbindingsconfiguratie toe via de manager die de daadwerkelijke client gebruikt. Oudere generaties Apache HttpClient gebruiken andere API's, dus een ouder fragment is geen betrouwbare kaart van deze verantwoordelijkheden.
Blijf een definitieve CONNECT-afwijzing als een antwoord van de proxy beschouwen. Een geslaagd antwoord gevolgd door een TLS-stilstand is een andere faalfase. „TCP verbonden; geen volledig CONNECT-antwoord vóór de opzetdeadline” beschrijft het probleem nauwkeuriger dan een generieke proxy-time-out.
Een totale deadline kan het wachten van de aanroeper naast deze fasegrenzen beperken. Wanneer die verloopt, annuleert of sluit u de bewerking via de levenscyclus die de client ondersteunt, voordat een nieuwe poging verbindingscapaciteit verbruikt.