Préserver les données tamponnées après une réponse HTTP CONNECT
Évitez un handshake HTTP CONNECT bloqué en trouvant la limite des en-têtes de réponse et en conservant les octets qui arrivent après elle.
Un petit wrapper de proxy peut fonctionner pour HTTPS puis se bloquer lorsqu'il est réutilisé pour un protocole dont le serveur parle en premier. La ligne suspecte est souvent celle qui attend que le tampon de réception se termine par \r\n\r\n.
TCP fournit un flux au client. Un appel de réception peut renvoyer la moitié d'une ligne de statut HTTP, une réponse CONNECT complète, ou cette réponse immédiatement suivie de données de tunnel. Rien ne garantit qu'une lecture s'arrête à la fin des en-têtes.
Trouver la limite à l'intérieur du tampon
Pour un échange HTTP/1.1 CONNECT, accumulez les octets jusqu'à ce que le terminateur d'en-têtes apparaisse n'importe où dans le tampon. Coupez à sa première occurrence. Analysez la ligne de statut et les en-têtes depuis la première partie ; conservez séparément tout ce qui suit la limite. Appliquez une limite de taille d'en-têtes et un délai d'attente pendant l'attente, et traitez une lecture de socket vide comme une connexion fermée plutôt que comme une nouvelle invitation à boucler.
Une réponse 2xx finale réussie fait passer la connexion en mode tunnel immédiatement après ces en-têtes. Les octets qui la suivent sont déjà des octets de tunnel. Ne les jetez pas, n'attendez pas de corps de réponse CONNECT, et n'interprétez pas un champ Content-Length comme l'autorisation de consommer une partie du nouveau protocole. Les réponses informatives, si elles existent, doivent être traitées avant cette réponse finale.
Le wrapper doit transmettre ses restes
Ne renvoyer que la socket sous-jacente perd les octets que l'analyseur de handshake en a déjà extraits. Le lecteur suivant a besoin d'un flux tamponné qui restitue d'abord la fin sauvegardée puis reprend les lectures sur la socket. Pour un protocole où le serveur parle en premier, perdre ce salut initial peut laisser les deux côtés attendre indéfiniment.
Inversement, les octets d'une réponse CONNECT échouée ne sont pas un salut de tunnel. Un 407 appartient toujours à l'échange proxy et exige une gestion de l'authentification ; un autre statut non réussi nécessite un chemin d'erreur approprié.
Cela compte particulièrement lors de l'adaptation d'un client FTP ou SSH via un proxy HTTP. Le proxy doit aussi autoriser le port de destination demandé, et FTP peut avoir besoin de connexions de données supplémentaires. Une analyse correcte des en-têtes résout la transmission du flux ; elle ne peut ni accorder l'autorisation CONNECT ni fournir le second canal de FTP.