د Beast CONNECT بفر TLS handshake ته وړئ

وروسته له دې چې Beast د یوه پراکسي د CONNECT ځواب سرلیک ولولي، هم د ځواب حالت او هم متحرک بفر وڅېړئ. د لوستلو عملیات کولای شي د سرلیک له پای څخه هاخوا بایټونه راوړي او په ورکړل شوي بفر کې یې وساتي. که TLS د هغه اورلوډ سره پیل کړئ چې یوازې ساکټ لولي، هغه ساتل شوي بایټونه د TLS د ننوتلو لارې څخه بهر پاتې کېږي.

د هغه WebSocket جریان لپاره چې بل پوړ یې SSL جریان دی، د بفر لرونکی handshake اورلوډ وکاروئ. په موجوده yield_context غونډه کې، buffer د ټولو عملیاتو په اوږدو کې ژوندی ساتل:

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

لومړني راستنېدل د غونډې د ناکامۍ وتلې دي؛ هلته عادي د تېروتنو راپور او پاکوالی ونښلوئ. یوازې بریالی CONNECT ځواب تونل جوړوي. د رد پاڼه باید د TLS ننوتنه نه شي.

بفر لرونکی اورلوډ د تېروتنې کوډ او د بایټونو شمېر سره بشپړېږي. هغه شمېر څرګندوي چې له ورکړل شوو بفرونو څخه یې څو بایټونه مصرف کړي. له بشپړېدو وروسته هغه مخکښ په سمه توګه د consume(used) په مرسته لرې کړئ. بفر د عملیاتو له پیل مخکې تش نه کړئ، د handshake د انتظار په وخت کې یې زېرمه مه بدلوئ، او مه فکر کوئ چې عملیات هر ورکړل شوی بایټ مصرف کړی دی.

د CONNECT وروسته سمدلاسه د کلاینټ پیل شوي عادي TLS په صورت کې بفر کېدای شي تش وي. اورلوډ هغه حالت هم سمبالوي. هدف یې د جریان د پولو ساتل دي؛ دا هر ډول اضافي پراکسي ډاټا د اعتبار وړ TLS نه جوړوي. د handshake مخکې په SSL پوړ کې د موخې هوسټ نوم تایید او SNI ترتیب وساتئ، او د WebSocket لوړول یوازې د TLS له بریالیتوب وروسته پیل کړئ.