Conservar los datos en búfer tras una respuesta HTTP CONNECT
Evite un protocolo de enlace HTTP CONNECT bloqueado localizando el límite de las cabeceras de respuesta y conservando los bytes que llegan después.
Un pequeño envoltorio de proxy puede funcionar con HTTPS y luego quedarse colgado al reutilizarse para un protocolo en el que el servidor habla primero. La línea sospechosa suele ser la que espera que el búfer de recepción termine con \r\n\r\n.
TCP entrega al cliente un flujo. Una sola llamada de recepción puede devolver media línea de estado HTTP, una respuesta CONNECT completa, o esa respuesta seguida de inmediato por datos del túnel. No hay ninguna promesa de que una lectura se detenga al final de las cabeceras.
Encuentre el límite dentro del búfer
Para un intercambio HTTP/1.1 CONNECT, acumule bytes hasta que el terminador de cabeceras aparezca en cualquier punto del búfer. Divida en su primera aparición. Analice la línea de estado y las cabeceras de la primera parte; conserve por separado todo lo que hay después del límite. Aplique un límite de tamaño de cabeceras y un tiempo de espera mientras aguarda, y trate una lectura vacía del socket como una conexión cerrada en lugar de otra invitación a repetir.
Una respuesta 2xx final correcta conmuta la conexión a modo túnel justo después de esas cabeceras. Sus bytes posteriores ya son bytes del túnel. No los descarte, no espere un cuerpo de respuesta CONNECT ni interprete un campo Content-Length como permiso para consumir parte del nuevo protocolo. Las respuestas informativas, si existen, deben gestionarse antes de esa respuesta final.
El envoltorio debe reenviar sus sobras
Devolver solo el socket subyacente pierde los bytes que el analizador del protocolo de enlace ya extrajo de él. El siguiente lector necesita un flujo con búfer que entregue primero la cola guardada y luego reanude las lecturas del socket. En un protocolo donde el servidor habla primero, perder ese saludo inicial puede dejar a ambos lados esperando indefinidamente.
Por el contrario, los bytes de una respuesta CONNECT fallida no son un saludo del túnel. Un 407 sigue perteneciendo al intercambio con el proxy y requiere manejo de autenticación; otro estado no exitoso requiere una ruta de error adecuada.
Esto importa sobre todo al adaptar un cliente FTP o SSH a través de un proxy HTTP. El proxy también debe permitir el puerto de destino solicitado, y FTP puede necesitar conexiones de datos adicionales. El análisis correcto de cabeceras resuelve el traspaso del flujo; no puede conceder permiso CONNECT ni proporcionar el segundo canal de FTP.