Beast ၏ CONNECT buffer ကို TLS handshake ထဲသို့ သယ်ဆောင်ပါ
CONNECT တုံ့ပြန်မှုပြီးနောက် ကျန်ရှိသော byte များကို Asio ၏ buffer ပါသော TLS handshake သို့ ပို့ပြီး သူအသုံးပြုခဲ့သည့် ပမာဏအတိအကျကို သုံးစွဲပါ။
Beast သည် proxy ၏ CONNECT တုံ့ပြန်မှု header ကို ဖတ်ပြီးနောက် တုံ့ပြန်မှု အခြေအနေနှင့် dynamic buffer နှစ်ခုလုံးကို စစ်ဆေးပါ။ ဖတ်ခြင်း လုပ်ဆောင်ချက်သည် header အဆုံးကို ကျော်လွန်သော byte များ ကို ယူပြီး ပေးထားသော buffer တွင် သိမ်းထားနိုင်သည်။ socket ကိုသာ ဖတ်သော overload ဖြင့် TLS စတင်ပါက ထိုသိမ်းထားသော byte များသည် TLS input လမ်းကြောင်း၏ အပြင်ဘက်တွင် ကျန်ရစ်သည်။
နောက်ထပ် အလွှာသည် SSL stream ဖြစ်သော WebSocket stream အတွက် buffer ပါသော handshake overload ကို အသုံးပြုပါ။ ရှိပြီးသား yield_context session တွင် 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);
အစောပိုင်း return များသည် session ၏ မအောင်မြင်မှု ထွက်ပေါက်များ ဖြစ်သည်; ထိုနေရာတွင် ပုံမှန် error အစီရင်ခံမှုနှင့် ရှင်းလင်းရေးကို ချိတ်ဆက်ပါ။ အောင်မြင်သော CONNECT တုံ့ပြန်မှုကသာ tunnel ကို တည်ဆောက်သည်။ ငြင်းပယ်သည့် စာမျက်နှာသည် TLS input မဖြစ်ရပါ။
buffer ပါသော overload သည် error code နှင့် byte အရေအတွက်ဖြင့် ပြီးဆုံးသည်။ ထို အရေအတွက်သည် ပေးထားသော buffer များမှ မည်မျှ byte သုံးစွဲခဲ့သည်ကို ဖော်ပြသည်။ ပြီးဆုံးပြီးနောက် ထို prefix ကို consume(used) ဖြင့် အတိအကျ ဖယ်ရှားပါ။ လုပ်ဆောင်ချက် မစတင်မီ buffer ကို မရှင်းပါနှင့်၊ handshake စောင့်နေစဉ် ၎င်း၏ သိုလှောင်မှုကို မပြောင်းပါနှင့်၊ လုပ်ဆောင်ချက်သည် ပေးထားသော byte တိုင်းကို သုံးစွဲခဲ့သည်ဟု မယူဆပါနှင့်။
CONNECT ပြီးနောက် ချက်ချင်း client က စတင်သော ပုံမှန် TLS တွင် buffer သည် အလွတ် ဖြစ်နိုင်သည်။ overload သည် ထို အခြေအနေကိုလည်း ကိုင်တွယ်သည်။ ၎င်း၏ ရည်ရွယ်ချက်မှာ stream နယ်နိမိတ်များကို ထိန်းသိမ်းရန် ဖြစ်သည်; မည်သည့် နောက်ဆက်တွဲ proxy ဒေတာကိုမျှ တရားဝင် TLS မဖြစ်စေပါ။ handshake မတိုင်မီ SSL အလွှာတွင် ဦးတည် host အမည် စစ်ဆေးမှုနှင့် SNI ဖွဲ့စည်းမှုကို ထားရှိပြီး TLS အောင်မြင်ပြီးမှသာ WebSocket upgrade ကို စတင်ပါ။