CONNECT-Handler in Node.js müssen den head-Puffer bewahren
Behandeln Sie den CONNECT-Socket und den head-Puffer von Node an der Grenze zwischen HTTP und Tunnel und bewahren Sie die bereits über die Header hinaus gelesenen Bytes.
Ein Node-HTTP-Server verarbeitet eine gewöhnliche Proxy-Anfrage über seinen Request-Callback. CONNECT nimmt einen anderen Weg: Der Server gibt connect zusammen mit der Anfrage, dem Client-Socket und einem head-Puffer aus.
Dieses Ereignis ist die Übergabe zwischen HTTP-Parsing und einem Tunnel. Es gibt kein gewöhnliches ServerResponse-Objekt, das für den tunnelierten Verkehr weiterverwendet werden kann.
| Argument | Was es trägt |
|---|---|
req | Die CONNECT-Anfrage einschließlich ihrer Zielautorität und Header |
clientSocket | Die Verbindung zurück zum Client |
head | Tunneldaten, die Node bereits über die HTTP-Header hinaus gelesen hat, möglicherweise leer |
Schließen Sie die HTTP-Entscheidung ab, bevor Bytes weitergeleitet werden
Validieren Sie den angeforderten Host und Port, wenden Sie die Zugriffs- und Authentifizierungsrichtlinie des Proxys an und stellen Sie die Upstream-Verbindung her. CONNECT identifiziert eine Autorität wie service.example:443; parsen Sie diese Form mit Blick auf IPv6-Autoritäten, anstatt blind an jedem Doppelpunkt zu trennen.
Wenn der Tunnel akzeptiert wird, senden Sie die erfolgreiche HTTP-Antwort gefolgt von ihrer abschließenden Leerzeile. Leiten Sie dann alle head-Bytes upstream weiter, bevor Sie mit späteren Bytes vom Client-Socket fortfahren. Das Anhängen eines neuen Daten-Listeners kann einen Puffer nicht wiederherstellen, der dem Handler bereits separat übergeben wurde.
Nodes offizielles Tunnelbeispiel führt diese Übergabe mit serverSocket.write(head) durch, bevor die beiden Streamrichtungen verbunden werden. Sein kleines Beispiel veranschaulicht den Übergang; ein bereitgestellter Proxy benötigt außerdem begrenzte Verbindungsversuche, Zugriffskontrollen und Lebenszyklusverwaltung.
Nach dem Erfolg gehören die Bytes zum Dienstprotokoll
Eine erfolgreiche CONNECT-Antwort verwandelt die Verbindung in einen Bytestrom. Wenn das Ziel eine HTTPS-Website ist, findet ihr TLS-Austausch innerhalb dieses Stroms statt. Das bloße Tunneln erfordert nicht, dass der Proxy ein Ersatz-Website-Zertifikat ausstellt.
Vor der Annahme von CONNECT kann ein HTTP-Fehler erklären, warum abgelehnt wurde. Nach der Annahme würde das Schreiben einer HTTP 500 in den Strom Bytes in das tunnelierte Protokoll einspeisen. Beenden oder zerstören Sie stattdessen die entsprechenden Verbindungen bei späteren Fehlern.
Verbinden Sie beide Richtungen mit gegendruckbewusste Stream-Verarbeitung, und entscheiden Sie, wie end-, error- und close-Ereignisse den Peer beenden. Bewahren Sie den anfänglichen head-Puffer als Teil desselben Eigentumsmodells; er ist Anwendungsdaten, keine übrig gebliebenen HTTP-Header, die verworfen werden dürfen.