Combien de temps un tunnel CONNECT peut-il rester ouvert ?
Distinguez la durée de vie d'un tunnel établi de la réutilisation des réponses HTTP, des politiques d'inactivité de l'intermédiaire et de la session propre à l'application de destination.
CONNECT ne promet pas un tunnel ouvert indéfiniment. Après un échange réussi, la connexion transporte un flux d'octets continu vers l'hôte et le port demandés. Elle peut transporter plusieurs échanges au sein d'une session TLS de destination tant que les participants et le réseau la gardent ouverte.
Deux limites du proxy se comportent différemment : le trafic peut empêcher l'expiration d'une minuterie d'inactivité, mais il ne peut pas prolonger une limite de durée de vie absolue. Le protocole de destination a aussi son mot à dire. Un client HTTP interne peut fermer sa connexion ; une application WebSocket peut terminer sa session. Le proxy ne peut pas maintenir cette session de destination en vie ensuite.
Un tunnel est lié à sa cible. Une fois les octets du tunnel en circulation, la connexion n'est plus un canal de requêtes HTTP ordinaire sur lequel émettre un autre CONNECT vers une destination sans rapport. Le client a besoin d'une autre connexion ou d'un autre tunnel géré par sa bibliothèque.
Pour un flux persistant, prévoyez des reconnexions avec les mécanismes de vitalité et de connexion pris en charge par le client. S'il se ferme après un silence, une politique d'inactivité est une piste utile ; s'il se ferme au bout d'une durée fixe malgré le trafic, cherchez plutôt une limite absolue. Pour un flux WebSocket, restaurez aussi l'état de l'application après reconnexion.