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 কনফিগারেশন রাখুন, এবং TLS সফল হওয়ার পরেই WebSocket আপগ্রেড শুরু করুন।