Beast کا CONNECT بفر TLS ہینڈ شیک میں لے جائیں

Beast کے ذریعے پراکسی کا CONNECT جواب ہیڈر پڑھنے کے بعد جواب کی حالت اور متحرک بفر دونوں جانچیں۔ پڑھنے کا عمل ہیڈر کے اختتام سے آگے کے بائٹس لا سکتا ہے اور انہیں دیے گئے بفر میں رکھ سکتا ہے۔ اگر صرف ساکٹ پڑھنے والے اوور لوڈ سے TLS شروع کریں تو وہ رکھے گئے بائٹس TLS اِن پٹ راستے سے باہر رہتے ہیں۔

جس WebSocket اسٹریم کی اگلی پرت SSL اسٹریم ہے، اس کے لیے بفر والا ہینڈ شیک اوور لوڈ استعمال کریں۔ موجودہ 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) سے ٹھیک وہی سابقہ ہٹائیں۔ کارروائی شروع کرنے سے پہلے بفر صاف نہ کریں، ہینڈ شیک زیرِ التوا ہونے کے دوران اس کا ذخیرہ نہ بدلیں، اور یہ نہ سمجھیں کہ کارروائی نے ہر دیا گیا بائٹ استعمال کیا ہے۔

CONNECT کے فوراً بعد کلائنٹ کے شروع کردہ عام TLS میں بفر خالی ہو سکتا ہے۔ اوور لوڈ اس صورت حال کو بھی سنبھالتا ہے۔ اس کا مقصد اسٹریم کی حدود کو محفوظ رکھنا ہے؛ یہ کسی بھی اضافی پراکسی ڈیٹا کو درست TLS نہیں بناتا۔ ہینڈ شیک سے پہلے SSL پرت پر منزل کے ہوسٹ نام کی تصدیق اور SNI ترتیب برقرار رکھیں، اور WebSocket اپ گریڈ صرف TLS کامیاب ہونے کے بعد شروع کریں۔