Przenieś bufor CONNECT Beast do uzgadniania TLS

Gdy Beast odczyta nagłówek odpowiedzi CONNECT serwera proxy, sprawdź zarówno status odpowiedzi, jak i bufor dynamiczny. Operacja odczytu może pobrać bajty poza końcem nagłówka i zatrzymać je w dostarczonym buforze. Rozpoczęcie TLS przeciążeniem, które czyta tylko gniazdo, pozostawia te zatrzymane bajty poza ścieżką wejścia TLS.

Dla strumienia WebSocket, którego następną warstwą jest strumień SSL, użyj buforowanego przeciążenia uzgadniania. W istniejącej sesji yield_context, utrzymując buffer przy życiu przez cały czas trwania operacji:

http::response_parser<http::empty_body> response;
http::async_read_header(
    beast::get_lowest_layer(ws), buffer, response, yield[ec]);
if (ec) return;

auto status = response.get().result_int();
if (status < 200 || status >= 300) return;

std::size_t used = ws.next_layer().async_handshake(
    ssl::stream_base::client, buffer.data(), yield[ec]);
if (ec) return;
buffer.consume(used);

Wczesne powroty to wyjścia awaryjne sesji; dołącz tam zwykłe raportowanie błędów i sprzątanie. Tylko udana odpowiedź CONNECT ustanawia tunel. Strona odmowy nie może stać się wejściem TLS.

Buforowane przeciążenie kończy się kodem błędu i liczbą bajtów. Liczba ta opisuje, ile bajtów zużyło z dostarczonych buforów. Po zakończeniu usuń dokładnie ten prefiks za pomocą consume(used). Nieczyść bufora przed rozpoczęciem operacji, nie zmieniaj jego magazynu, gdy uzgadnianie trwa, i nie zakładaj, że operacja zużyła każdy dostarczony bajt.

Przy zwykłym TLS uruchamianym przez klienta zaraz po CONNECT bufor może być pusty. Przeciążenie obsługuje także ten przypadek. Jego celem jest zachowanie granic strumienia; nie czyni dowolnych kolejnych danych proxy prawidłowym TLS. Zachowaj weryfikację nazwy hosta docelowego i konfigurację SNI na warstwie SSL przed uzgadnianiem, a aktualizację WebSocket rozpocznij dopiero po powodzeniu TLS.