Zachowaj dane w buforze po odpowiedzi HTTP CONNECT
Uniknij zawieszonego uzgadniania HTTP CONNECT, znajdując granicę nagłówków odpowiedzi i zachowując bajty, które przychodzą po niej.
Mały wrapper proxy może działać dla HTTPS, a potem zawieszać się, gdy jest ponownie używany dla protokołu, którego serwer mówi pierwszy. Podejrzana linia to często ta, która czeka, aż bufor odbiorczy zakończy się sekwencją \r\n\r\n.
TCP daje klientowi strumień. Jedno wywołanie odbioru może zwrócić połowę wiersza stanu HTTP, pełną odpowiedź CONNECT albo tę odpowiedź natychmiast poprzedzoną danymi tunelu. Nie ma gwarancji, że odczyt zatrzyma się na końcu nagłówków.
Znajdź granicę w buforze
W wymianie HTTP/1.1 CONNECT gromadź bajty, aż terminator nagłówków pojawi się w dowolnym miejscu bufora. Podziel przy jego pierwszym wystąpieniu. Przeanalizuj wiersz stanu i nagłówki z pierwszej części; wszystko po granicy zachowaj osobno. Zastosuj limit rozmiaru nagłówków i limit czasu podczas oczekiwania, a pusty odczyt gniazda traktuj jako zamknięte połączenie, a nie kolejne zaproszenie do pętli.
Ostateczna udana odpowiedź 2xx przełącza połączenie w tryb tunelu natychmiast po tych nagłówkach. Bajty po niej są już bajtami tunelu. Nie odrzucaj ich, nie czekaj na treść odpowiedzi CONNECT i nie interpretuj pola Content-Length jako pozwolenia na zużycie części nowego protokołu. Odpowiedzi informacyjne, jeśli występują, trzeba obsłużyć przed tą ostateczną odpowiedzią.
Wrapper musi przekazać swoje resztki
Zwrócenie tylko bazowego gniazda gubi bajty, które parser uzgadniania już z niego wyciągnął. Następny czytelnik potrzebuje buforowanego strumienia, który najpierw wydaje zapisany ogon, a potem wznawia odczyty z gniazda. W protokole, w którym serwer mówi pierwszy, utrata tego początkowego powitania może pozostawić obie strony w nieskończonym oczekiwaniu.
Odwrotnie, bajty z nieudanej odpowiedzi CONNECT nie są powitaniem tunelu. 407 nadal należy do wymiany proxy i wymaga obsługi uwierzytelniania; inny nieudany status wymaga odpowiedniej ścieżki błędu.
Ma to szczególne znaczenie przy dostosowywaniu klienta FTP lub SSH przez proxy HTTP. Proxy musi też zezwolić na żądany port docelowy, a FTP może potrzebować dodatkowych połączeń danych. Poprawne parsowanie nagłówków rozwiązuje przekazanie strumienia; nie może przyznać zgody CONNECT ani zapewnić drugiego kanału FTP.