Une réponse CONNECT réussie n’a pas de corps HTTP
Terminez une réponse CONNECT HTTP/1.1 réussie à la limite des en-têtes, puis relayez les octets du tunnel sans chunk framing ni redémarrage de la connexion.
Une réponse CONNECT HTTP/1.1 réussie se termine après sa section d’en-têtes :
HTTP/1.1 200 Connection Established
Au-delà de cette limite, la même connexion transporte le tunnel. Pour une destination HTTPS, les octets suivants du client commencent normalement l’échange TLS avec la destination.
Le proxy ne doit pas ajouter Transfer-Encoding ni Content-Length à une réponse CONNECT réussie. Il n’y a aucun corps de réponse HTTP à découper en chunks. Ajouter un chunk final vide injecterait au contraire des octets dans le nouveau tunnel.
Le client a lui aussi une exigence : il doit ignorer ces champs de framing s’ils apparaissent dans une réponse CONNECT 2xx. Un émetteur mal formé n’est donc pas une raison de décrire tout client conforme comme attendant un corps découpé.
Gardez la connexion établie ouverte pour le relais. La fermer après 200 détruit le tunnel ; ouvrir une autre connexion n’est pas la continuation de la requête CONNECT acceptée.
Une réponse CONNECT échouée suit un autre traitement et peut porter un corps d’erreur HTTP ordinaire. Séparez cette réponse de la remise réussie lors de l’implémentation ou de la lecture d’une trace de proxy.