Når Beast har læst et proxys CONNECT-svarheader, skal du undersøge både svarstatus og den dynamiske buffer. Læseoperationen kan hente bytes ud over headerens afslutning og beholde dem i den medsendte buffer. Hvis du starter TLS med en overbelastning, der kun læser socket’en, bliver de beholdte bytes uden for TLS-inputvejen.

Til en WebSocket-stream, hvis næste lag er SSL-streamen, skal du bruge den bufferede handshake-overbelastning. I en eksisterende yield_context-session, hvor buffer holdes i live gennem alle operationerne:

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

De tidlige returneringer er sessionens fejlundgange; knyt den sædvanlige fejlrapportering og oprydning der. Kun et vellykket CONNECT-svar etablerer tunnelen. En afvisningsside må ikke blive TLS-input.

Den bufferede overbelastning afsluttes med en fejlkode og et byteantal. Det tal angiver, hvor mange bytes den forbrugte fra de medsendte buffere. Fjern præcis det præfiks med consume(used) efter afslutningen. Du må ikke rydde bufferen før operationen starter, ændre dens lager, mens handshaket er i gang, eller antage, at operationen har forbrugt hver medsendt byte.

Ved almindelig klientstartet TLS umiddelbart efter CONNECT kan bufferen være tom. Overbelastningen håndterer også det tilfælde. Dens formål er at bevare streamgrænser; den gør ikke vilkårlige efterfølgende proxy-data til gyldig TLS. Behold programmets værtsnavneverifikation og SNI-konfiguration på SSL-laget før handshaket, og start først WebSocket-opgraderingen, når TLS er lykkedes.

Relaterede artikler