Los manejadores CONNECT de Node.js deben conservar el búfer head
Gestione el socket CONNECT y el búfer head de Node en la frontera entre HTTP y el túnel, conservando los bytes ya leídos más allá de las cabeceras.
Un servidor HTTP de Node gestiona una solicitud de proxy ordinaria mediante su función de devolución de solicitud. CONNECT sigue otro camino: el servidor emite connect con la solicitud, el socket del cliente y un búfer head.
Ese evento es la entrega entre el análisis HTTP y un túnel. No hay un objeto ServerResponse ordinario que seguir usando para el tráfico del túnel.
| Argumento | Qué transporta |
|---|---|
req | La solicitud CONNECT, incluida su autoridad de destino y sus cabeceras |
clientSocket | La conexión de vuelta al cliente |
head | Datos del túnel que Node ya ha leído más allá de las cabeceras HTTP, posiblemente vacíos |
Termine la decisión HTTP antes de retransmitir bytes
Valide el host y el puerto solicitados, aplique la política de acceso y autenticación del proxy y establezca la conexión ascendente. CONNECT identifica una autoridad como service.example:443; analice esa forma teniendo en cuenta las autoridades IPv6 en lugar de dividir a ciegas en cada dos puntos.
Cuando se acepta el túnel, envíe la respuesta HTTP correcta seguida de su línea en blanco final. Después reenvíe los bytes head ascendentes antes de continuar con los bytes posteriores del socket del cliente. Adjuntar un nuevo oyente de datos no puede recuperar un búfer ya entregado por separado al manejador.
El ejemplo oficial de túnel de Node realiza esa entrega con serverSocket.write(head) antes de conectar las dos direcciones del flujo. Su pequeño ejemplo ilustra la transición; un proxy desplegado también necesita intentos de conexión acotados, controles de acceso y gestión del ciclo de vida.
Tras el éxito, los bytes pertenecen al protocolo del servicio
Una respuesta CONNECT correcta convierte la conexión en un flujo de bytes. Si el destino es un sitio HTTPS, su intercambio TLS viaja dentro de ese flujo. Solo tunelizarlo no exige que el proxy emita un certificado de sitio web sustituto.
Antes de aceptar CONNECT, un error HTTP puede explicar por qué se rechazó. Tras la aceptación, escribir un HTTP 500 en el flujo inyectaría bytes en el protocolo del túnel. En su lugar, termine o destruya las conexiones adecuadas en fallos posteriores.
Conecte ambas direcciones con gestión de flujo consciente de la contrapresión, y decida cómo los eventos end, error y close terminan al par. Conserve el búfer head inicial como parte de ese mismo modelo de propiedad; son datos de la aplicación, no cabeceras HTTP sobrantes que descartar.