Neidat Beast de CONNECT-antwurdkop fan in proxy lêzen hat, ûndersykje sawol de antwurdstatus as de dynamyske buffer. De lêsoperaasje kin bytes foarby de kop-einmarker helje en dy yn de oanlevere buffer hâlde. As jo TLS starte mei in oerlading dy’t allinnich de socket lêst, bliuwe dy bewarre bytes bûten it TLS-ynfierpaad.

Foar in WebSocket-stream wêrfan’t de folgjende laach de SSL-stream is, brûk de buffere handshake-oerlading. Yn in besteande yield_context-sesje, mei buffer libben holden troch alle operaasjes:

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 iere returns binne de flaterútgongen fan ’e sesje; heakje dêr de gewoane flaterrapportaazje en opromming oan. Allinnich in slagge CONNECT-antwurd makket de tunnel. In ôfwizingsside mei gjin TLS-ynfier wurde.

De buffere oerlading einiget mei in flaterkoade en in byte-oantal. Dat oantal beskriuwt hoefolle bytes it út ’e oanlevere buffers ferbrûkt hat. Ferwiderje nei ôfrin krekt dat foarheaksel mei consume(used). Meitsje de buffer net leech foar’t de operaasje begjint, feroarje syn opslach net wylst de handshake wachtet, en nim net oan dat de operaasje elke oanlevere byte ferbrûkt hat.

By gewoane troch de klant begûne TLS fuort nei CONNECT kin de buffer leech wêze. De oerlading behannelet dat gefal ek. It doel is streamgrinzen te behâlden; it makket willekeurige efterfolgjende proxy-gegevens net jildige TLS. Hâld de ferifikaasje fan ’e bestimmingshostnamme en de SNI-konfiguraasje op ’e SSL-laach foar de handshake, en start de WebSocket-opwurdering pas nei’t TLS slagge is.

Relatearre artikelen