Conservar os datos almacenados tras unha resposta HTTP CONNECT

Un pequeno envoltorio de proxy pode funcionar para HTTPS e despois quedar colgado cando se reutiliza para un protocolo cuxo servidor fala primeiro. A liña sospeitosa adoita ser a que espera a que o búfer de recepción remate con \r\n\r\n.

TCP dálle ao cliente un fluxo. Unha chamada de recepción pode devolver media liña de estado HTTP, unha resposta CONNECT completa, ou esa resposta seguida inmediatamente de datos de túnel. Non hai garantía de que unha lectura se deteña ao final das cabeceiras.

Atopar o límite dentro do búfer

Para un intercambio HTTP/1.1 CONNECT, acumula bytes ata que o terminador de cabeceiras apareza en calquera punto do búfer. Divide na súa primeira aparición. Analiza a liña de estado e as cabeceiras da primeira parte; conserva por separado todo o que hai despois do límite. Aplica un límite de tamaño de cabeceiras e un tempo de espera mentres agardas, e trata unha lectura de socket baleira como unha conexión pechada en vez de como outra invitación a repetir o bucle.

Unha resposta 2xx final correcta cambia a conexión a modo túnel inmediatamente despois desas cabeceiras. Os bytes que a seguen xa son bytes de túnel. Non os descartes, non agardes un corpo de resposta CONNECT, nin interpretes un campo Content-Length como permiso para consumir parte do novo protocolo. As respostas informativas, se existen, deben xestionarse antes desa resposta final.

O envoltorio debe pasar os seus restos

Devolver só o socket subxacente perde os bytes que o analizador do saúdo xa extraeu del. O seguinte lector necesita un fluxo con búfer que entregue primeiro a cola gardada e despois retome as lecturas do socket. Para un protocolo no que o servidor fala primeiro, perder ese saúdo inicial pode deixar ambas as partes esperando indefinidamente.

Pola contra, os bytes dunha resposta CONNECT fallida non son un saúdo de túnel. Un 407 segue pertencendo ao intercambio co proxy e necesita xestión de autenticación; outro estado non correcto necesita unha ruta de erro axeitada.

Isto importa especialmente ao adaptar un cliente FTP ou SSH a través dun proxy HTTP. O proxy tamén ten que permitir o porto de destino solicitado, e FTP pode necesitar conexións de datos adicionais. Unha análise correcta das cabeceiras resolve a transferencia do fluxo; non pode conceder permiso CONNECT nin fornecer a segunda canle de FTP.