Rotations de proxy entre requêtes, connexions et sessions
Vérifiez ce qu'un service de proxy rotatif fait réellement tourner avant d'ajouter Connection: close à chaque requête applicative.
Une deuxième requête via la même passerelle peut légitimement utiliser la même IP publique. Vérifiez quelle durée de vie le service utilise pour sa rotation :
| Unité de rotation | Ce qu'il faut comparer |
|---|---|
| Requête | L'opération applicative suivante et sa sortie observée |
| Connexion | Si le client a réutilisé une connexion compatible ou en a ouvert une autre |
| Session du fournisseur | L'entrée de session collante documentée et sa durée de vie |
Connection: close n'est pas une consigne universelle de passerelle. Pour HTTPS dans CONNECT, l'en-tête de requête du site voyage à l'intérieur du TLS de destination. Il n'indique pas au proxy externe quelle IP publique attribuer. La sémantique propre à la connexion de HTTP/1.1 ne peut pas non plus être reportée à l'identique dans chaque version HTTP ni chaque transport.
Si un service documenté par connexion exige une connexion neuve, utilisez le contrôle de cycle de vie pris en charge par le client et tenez compte des coûts répétés d'établissement TCP/TLS. Si la rotation suit une session du fournisseur, se reconnecter peut conserver à la fois cette session et sa sortie.
Enregistrez séparément l'identifiant de requête, le point de terminaison, la clé de session pertinente et la source observée à la destination. Fermer une connexion n'établit que cet événement de cycle de vie ; vérifiez la sortie choisie pour l'opération suivante au regard du contrat de rotation réel du service.