Expirations CONNECT du proxy après une connexion TCP réussie
Identifiez le délai actif pendant CONNECT au lieu de supposer qu'une connexion TCP établie a aussi terminé la mise en place du tunnel.
Un délai de connexion TCP a rempli son rôle dès que le client se connecte au proxy. L'attente suivante—recevoir une réponse CONNECT complète—peut être régie par un autre minuteur.
Le proxy est peut-être encore en train de se connecter en amont, d'échanger des messages d'authentification ou d'attendre un autre service. La réponse ordinaire du site n'a pas encore commencé.
| Dernière étape terminée | Qu'attend-on encore ? |
|---|---|
| TCP connecté au proxy | La poignée de main du proxy, y compris l'acceptation de CONNECT |
| CONNECT accepté | Le TLS de destination, lorsque la cible l'utilise |
| Requête de destination envoyée | La réponse de la destination |
Trouvez le minuteur actif pendant que le connecteur lit et écrit cette poignée de main. Une propriété appelée « response timeout » peut n'entrer en vigueur qu'après l'établissement de la route. Avec HttpClient 5, distinguez ConnectionConfig et son délai de socket, la configuration de la poignée de main TLS et le délai de réponse au niveau de la requête. Appliquez la configuration de connexion pertinente via le gestionnaire utilisé par le client réel. Les anciennes générations d'Apache HttpClient utilisent des API différentes, donc un extrait plus ancien n'est pas une carte fiable de ces responsabilités.
Considérez toujours un refus final de CONNECT comme une réponse du proxy. Une réponse réussie suivie d'un blocage TLS constitue une autre étape de défaillance. « TCP connecté ; aucune réponse CONNECT complète avant l'échéance de configuration » décrit le problème plus précisément qu'un délai de proxy générique.
Une échéance globale peut borner l'attente de l'appelant en plus de ces limites par phase. Lorsqu'elle expire, annulez ou fermez l'opération via le cycle de vie pris en charge par le client avant qu'une nouvelle tentative ne consomme de la capacité de connexion.