Tłumaczenie żądania SOCKS5 na tunel HTTP
Zakończ wymianę CONNECT z rodzicem, zwróć klientowi odpowiedź SOCKS i dopiero potem przekazuj bajty aplikacji.
Frontend SOCKS5 może używać proxy HTTP jako swojego dalszego transportu. Działa jako serwer SOCKS wobec klienta i jako klient HTTP CONNECT wobec rodzica. Obie wymiany sterujące kończą się, zanim zacznie się strumień aplikacji.
Żądanie SOCKS CONNECT już podaje host lub adres docelowy oraz port. Dla przykładowej wymiany HTTP/1.1 z rodzicem:
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
Przetłumacz wynik na granicy
Adapter wykonuje wszelkie wymagane uwierzytelnienie u rodzica i czeka na wynik CONNECT. Udana odpowiedź 2xx ustanawia tunel do rodzica. Dopiero potem powinien zwrócić odpowiednią odpowiedź sukcesu SOCKS klientowi poniżej.
Jeśli rodzic odrzuci operację, wyślij zdefiniowaną odpowiedź błędu SOCKS, a następnie natychmiast zakończ połączenie klienta. SOCKS5 wymaga tego zamknięcia w ciągu dziesięciu sekund od wykrycia błędu. Zachowaj status HTTP rodzica jako informację diagnostyczną dla adaptera. Przekazanie tego wiersza statusu jako danych aplikacji umieściłoby komunikat sterujący HTTP w strumieniu, którego klient oczekuje ramkowania SOCKS.
Przed udanym wynikiem CONNECT rodzic wciąż mówi po HTTP, łącznie z ramkowaniem każdej odpowiedzi wyzwania lub błędu. Po separatorze nagłówków udanego wyniku połączenie staje się tunelem; nie ma najpierw żadnego ciała odpowiedzi HTTP do skonsumowania.
Zachowaj bajty po nagłówkach
Jeden odczyt może zawierać koniec nagłówków rodzica i bajty z celu jednocześnie. Zachowaj te dodatkowe bajty dla aplikacji poniżej. Protokoły, w których serwer mówi pierwszy, mogą przywitać się natychmiast po otwarciu połączenia.
Po wysłaniu odpowiedzi sukcesu SOCKS przekazuj strumień aplikacji w obu kierunkach. Adapter nie musi przeplatać jednej wiadomości klienta z jedną wiadomością serwera ani rozumieć rekordów TLS, aby je przekazać. Jego pracą protokolarną było ustanowienie i przetłumaczenie obu negocjacji tunelu.