Programy obsługi CONNECT w Node.js muszą zachować bufor head
Obsłuż gniazdo CONNECT i bufor head Node'a na granicy HTTP i tunelu, zachowując bajty już odczytane poza nagłówkami.
Serwer HTTP Node obsługuje zwykłe żądanie proxy przez swoje wywołanie zwrotne żądania. CONNECT idzie inną drogą: serwer emituje connect wraz z żądaniem, gniazdem klienta i buforem head.
To zdarzenie jest przekazaniem między analizą HTTP a tunelem. Nie ma zwykłego obiektu ServerResponse, którego można by dalej używać dla ruchu tunelowanego.
| Argument | Co przenosi |
|---|---|
req | Żądanie CONNECT, wraz z jego autorytetem docelowym i nagłówkami |
clientSocket | Połączenie z powrotem do klienta |
head | Dane tunelu, które Node już odczytał poza nagłówkami HTTP, być może puste |
Zakończ decyzję HTTP, zanim przekażesz bajty
Sprawdź żądany host i port, zastosuj politykę dostępu i uwierzytelniania proxy oraz nawiąż połączenie z serwerem nadrzędnym. CONNECT identyfikuje autorytet taki jak service.example:443; analizuj tę postać z myślą o autorytetach IPv6, zamiast dzielić na ślepo na każdym dwukropku.
Gdy tunel zostanie zaakceptowany, wyślij udaną odpowiedź HTTP, a po niej kończący ją pusty wiersz. Następnie przekaż wszelkie bajty head w górę, zanim przejdziesz do późniejszych bajtów z gniazda klienta. Dołączenie nowego nasłuchiwacza danych nie odzyska bufora, który został już osobno przekazany programowi obsługi.
Oficjalny przykład tunelowania w Node wykonuje to przekazanie za pomocą serverSocket.write(head) przed połączeniem obu kierunków strumienia. Jego mały przykład ilustruje przejście; wdrożone proxy potrzebuje też ograniczonych prób połączenia, kontroli dostępu i zarządzania cyklem życia.
Po sukcesie bajty należą do protokołu usługi
Udana odpowiedź CONNECT zamienia połączenie w strumień bajtów. Jeśli celem jest witryna HTTPS, jej wymiana TLS odbywa się wewnątrz tego strumienia. Samo tunelowanie nie wymaga, aby proxy wystawiło zastępczy certyfikat witryny.
Przed akceptacją CONNECT błąd HTTP może wyjaśnić powód odmowy. Po akceptacji zapisanie HTTP 500 w strumieniu wstrzyknęłoby bajty do protokołu tunelu. Zamiast tego zakończ lub zniszcz odpowiednie połączenia przy późniejszych awariach.
Połącz oba kierunki za pomocą obsługa strumienia świadoma przeciwdziałania i zdecyduj, jak zdarzenia end, error i close kończą drugą stronę. Zachowaj początkowy bufor head jako część tego samego modelu własności; to dane aplikacji, a nie zbędne nagłówki HTTP do wyrzucenia.