Flytta Beasts CONNECT-buffert in i TLS-handskakningen

När Beast har läst ett proxys CONNECT-svarhuvud, kontrollera både svarsstatusen och den dynamiska bufferten. Läsoperationen kan hämta byte bortom huvudets slut och behålla dem i den medskickade bufferten. Om du startar TLS med en överlagring som bara läser socketen, hamnar de behållna byten utanför TLS-indatavägen.

För en WebSocket-ström vars nästa lager är SSL-strömmen, använd den buffrade handskakningsöverlagringen. I en befintlig yield_context-session, med buffer vid liv genom alla operationer:

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);

Tidiga returer är sessionens felutgångar; koppla den vanliga felrapporteringen och städningen där. Endast ett lyckat CONNECT-svar upprättar tunneln. En avvisningssida får inte bli TLS-indata.

Den buffrade överlagringen avslutas med en felkod och ett byteantal. Det antalet beskriver hur många byte den förbrukade från de medskickade buffertarna. Ta bort exakt det prefixet med consume(used) efter avslutet. Töm inte bufferten innan operationen börjar, ändra inte dess lagring medan handskakningen väntar och anta inte att operationen förbrukade varje medskickad byte.

Vid vanlig klientinitierad TLS direkt efter CONNECT kan bufferten vara tom. Överlagringen hanterar även det fallet. Syftet är att bevara strömgänser; den gör inte godtyckliga efterföljande proxy-data till giltig TLS. Behåll värdnamnsverifieringen för målet och SNI-konfigurationen på SSL-lagret före handskakningen och starta WebSocket-uppgraderingen först efter att TLS har lyckats.