Os xestores CONNECT de Node.js deben conservar o búfer head
Xestione o socket CONNECT e o búfer head de Node na fronteira entre HTTP e o túnel, conservando os bytes xa lidos máis alá das cabeceiras.
Un servidor HTTP de Node xestiona unha solicitude de proxy ordinaria mediante a súa función de retorno de solicitude. CONNECT segue outro camiño: o servidor emite connect coa solicitude, o socket do cliente e un búfer head.
Ese evento é a entrega entre a análise HTTP e un túnel. Non hai ningún obxecto ServerResponse ordinario que seguir usando para o tráfico do túnel.
| Argumento | Que transporta |
|---|---|
req | A solicitude CONNECT, incluída a súa autoridade de destino e as súas cabeceiras |
clientSocket | A conexión de volta ao cliente |
head | Datos do túnel que Node xa leu máis alá das cabeceiras HTTP, posiblemente baleiros |
Remate a decisión HTTP antes de retransmitir bytes
Valide o host e o port solicitados, aplique a política de acceso e autenticación do proxy e estableza a conexión ascendente. CONNECT identifica unha autoridade como service.example:443; analice esa forma tendo en conta as autoridades IPv6 en lugar de dividir a cegas en cada dous puntos.
Cando se acepta o túnel, envía a resposta HTTP correcta seguida da súa liña en branco final. Despois reenvíe os bytes head ascendentes antes de continuar cos bytes posteriores do socket do cliente. Engadir un novo oínte de datos non pode recuperar un búfer xa entregado por separado ao xestor.
O exemplo oficial de túnel de Node realiza esa entrega con serverSocket.write(head) antes de conectar as dúas direccións do fluxo. O seu pequeno exemplo ilustra a transición; un proxy despregado tamén necesita intentos de conexión limitados, controis de acceso e xestión do ciclo de vida.
Tras o éxito, os bytes pertencen ao protocolo do servizo
Unha resposta CONNECT correcta converte a conexión nun fluxo de bytes. Se o destino é un sitio HTTPS, o seu intercambio TLS viaxa dentro dese fluxo. Só tunelizalo non require que o proxy emita un certificado de sitio web substituto.
Antes de aceptar CONNECT, un erro HTTP pode explicar por que se rexeitou. Tras a aceptación, escribir un HTTP 500 no fluxo inxectaría bytes no protocolo do túnel. No seu lugar, remate ou destrúa as conexións axeitadas en fallos posteriores.
Conecte ambas as direccións con xestión de fluxo consciente da contrapresión, e decida como os eventos end, error e close rematan o par. Conserve o búfer head inicial como parte dese mesmo modelo de propiedade; son datos da aplicación, non cabeceiras HTTP sobrantes que descartar.