I gestori CONNECT di Node.js devono preservare il buffer head
Gestisci il socket CONNECT e il buffer head di Node al confine tra HTTP e tunnel, preservando i byte già letti oltre le intestazioni.
Un server HTTP Node gestisce una normale richiesta proxy tramite il suo callback di richiesta. CONNECT segue un'altra strada: il server emette connect con la richiesta, il socket del client e un buffer head.
Quell'evento è la consegna tra l'analisi HTTP e un tunnel. Non c'è un oggetto ServerResponse ordinario da continuare a usare per il traffico tunnellizzato.
| Argomento | Cosa trasporta |
|---|---|
req | La richiesta CONNECT, inclusi la sua autorità di destinazione e le intestazioni |
clientSocket | La connessione di ritorno al client |
head | Dati del tunnel che Node ha già letto oltre le intestazioni HTTP, eventualmente vuoti |
Completa la decisione HTTP prima di inoltrare i byte
Valida l'host e la porta richiesti, applica la politica di accesso e autenticazione del proxy e stabilisci la connessione a monte. CONNECT identifica un'autorità come service.example:443; analizza quella forma tenendo conto delle autorità IPv6 invece di dividere ciecamente a ogni due punti.
Quando il tunnel viene accettato, invia la risposta HTTP riuscita seguita dalla sua riga vuota finale. Poi inoltra gli eventuali byte head a monte prima di continuare con i byte successivi dal socket del client. Collegare un nuovo listener di dati non può recuperare un buffer già consegnato separatamente al gestore.
L'esempio ufficiale di tunnel di Node esegue quella consegna con serverSocket.write(head) prima di collegare le due direzioni del flusso. Il suo piccolo esempio illustra la transizione; un proxy distribuito necessita anche di tentativi di connessione limitati, controlli di accesso e gestione del ciclo di vita.
Dopo il successo, i byte appartengono al protocollo del servizio
Una risposta CONNECT riuscita trasforma la connessione in un flusso di byte. Se la destinazione è un sito HTTPS, il suo scambio TLS viaggia dentro quel flusso. Il solo tunnelling non richiede che il proxy emetta un certificato del sito sostitutivo.
Prima di accettare CONNECT, un errore HTTP può spiegare perché è stato rifiutato. Dopo l'accettazione, scrivere un HTTP 500 nel flusso inietterebbe byte nel protocollo del tunnel. Termina o distruggi invece le connessioni appropriate in caso di errori successivi.
Collega entrambe le direzioni con gestione del flusso consapevole della contropressione, e decidi come gli eventi end, error e close terminano la controparte. Preserva il buffer head iniziale come parte dello stesso modello di proprietà; sono dati dell'applicazione, non intestazioni HTTP in eccesso da scartare.