Os handlers CONNECT do Node.js devem preservar o buffer head
Trate o socket CONNECT e o buffer head do Node na fronteira entre HTTP e túnel, preservando os bytes já lidos além dos cabeçalhos.
Um servidor HTTP Node trata uma solicitação de proxy comum por meio de seu callback de solicitação. O CONNECT segue outro caminho: o servidor emite connect com a solicitação, o socket do cliente e um buffer head.
Esse evento é a entrega entre a análise HTTP e um túnel. Não há um objeto ServerResponse comum para continuar usando no tráfego tunelado.
| Argumento | O que ele carrega |
|---|---|
req | A solicitação CONNECT, incluindo sua autoridade de destino e cabeçalhos |
clientSocket | A conexão de volta ao cliente |
head | Dados do túnel que o Node já leu além dos cabeçalhos HTTP, possivelmente vazios |
Conclua a decisão HTTP antes de repassar bytes
Valide o host e a porta solicitados, aplique a política de acesso e autenticação do proxy e estabeleça a conexão upstream. O CONNECT identifica uma autoridade como service.example:443; analise esse formato considerando as autoridades IPv6 em vez de dividir cegamente a cada dois-pontos.
Quando o túnel é aceito, envie a resposta HTTP bem-sucedida seguida de sua linha em branco final. Em seguida, repasse quaisquer bytes head para upstream antes de continuar com os bytes posteriores do socket do cliente. Anexar um novo listener de dados não consegue recuperar um buffer já entregue separadamente ao handler.
O exemplo oficial de tunelamento do Node realiza essa entrega com serverSocket.write(head) antes de conectar as duas direções do fluxo. Seu pequeno exemplo ilustra a transição; um proxy implantado também precisa de tentativas de conexão limitadas, controles de acesso e gerenciamento do ciclo de vida.
Após o sucesso, os bytes pertencem ao protocolo do serviço
Uma resposta CONNECT bem-sucedida transforma a conexão em um fluxo de bytes. Se o destino for um site HTTPS, sua troca TLS ocorre dentro desse fluxo. Apenas tunelar não exige que o proxy emita um certificado de site substituto.
Antes de aceitar CONNECT, um erro HTTP pode explicar por que foi recusado. Após a aceitação, escrever um HTTP 500 no fluxo injetaria bytes no protocolo tunelado. Em vez disso, encerre ou destrua as conexões apropriadas em falhas posteriores.
Conecte as duas direções com tratamento de fluxo consciente de contrapressão, e decida como os eventos end, error e close encerram o par. Preserve o buffer head inicial como parte desse mesmo modelo de propriedade; são dados da aplicação, não cabeçalhos HTTP excedentes a descartar.