Tradurre una richiesta SOCKS5 in un tunnel HTTP
Completare lo scambio CONNECT con il parent, restituire la risposta SOCKS al client e solo dopo inoltrare i byte dell'applicazione.
Un front-end SOCKS5 può usare un proxy HTTP come trasporto successivo. Agisce come server SOCKS verso il client e come client HTTP CONNECT verso il parent. I due scambi di controllo terminano prima che inizi il flusso dell'applicazione.
La richiesta SOCKS CONNECT fornisce già l'host o l'indirizzo di destinazione e la porta. Per uno scambio HTTP/1.1 illustrativo con il parent:
client → adapter: SOCKS5 CONNECT service.example.net:443
adapter → parent:
CONNECT service.example.net:443 HTTP/1.1
Host: service.example.net:443
parent → adapter: HTTP/1.1 200 Connection Established
[end of headers]
adapter → client: SOCKS5 success reply
client ↔ adapter ↔ parent ↔ service: application bytes
Tradurre il risultato al confine
L'adattatore completa ogni autenticazione richiesta dal parent e attende il risultato del CONNECT. Una risposta 2xx riuscita stabilisce il tunnel verso il parent. Solo allora deve restituire la corrispondente risposta di successo SOCKS al client a valle.
Se il parent rifiuta l'operazione, inviare una risposta di errore SOCKS definita, quindi terminare subito la connessione del client. SOCKS5 richiede quella chiusura entro dieci secondi dal rilevamento dell'errore. Conservare lo stato HTTP del parent come informazione diagnostica per l'adattatore. Inoltrare quella riga di stato come dati dell'applicazione inserirebbe un messaggio di controllo HTTP in un flusso il cui client si aspetta la strutturazione SOCKS.
Prima di un risultato CONNECT riuscito il parent parla ancora HTTP, compresa la strutturazione di qualsiasi risposta di verifica o di errore. Dopo il delimitatore di intestazioni di un risultato riuscito, la connessione diventa il tunnel; non c'è alcun corpo di risposta HTTP da consumare prima.
Preservare i byte dopo le intestazioni
Una lettura può contenere insieme la fine delle intestazioni del parent e byte provenienti dalla destinazione. Conservare quei byte aggiuntivi per l'applicazione a valle. I protocolli in cui il server parla per primo possono salutare subito dopo l'apertura della connessione.
Una volta inviata la risposta di successo SOCKS, inoltrare il flusso dell'applicazione in entrambe le direzioni. L'adattatore non deve alternare un messaggio del client con un messaggio del server, né deve comprendere i record TLS per inoltrarli. Il suo lavoro di protocollo era stabilire e tradurre le due negoziazioni dei tunnel.