Beast CONNECT buferini TLS qoʻl berishuviga oʻtkazing

Beast proksi CONNECT javob sarlavhasini oʻqigach, ham javob holatini, ham dinamik buferni tekshiring. Oʻqish amali sarlavha tugagandan keyingi baytlarni olib, ularni berilgan buferda saqlashi mumkin. Agar TLS ni faqat soketni oʻqiydigan variant bilan boshlasangiz, bu saqlangan baytlar TLS kirish yoʻlidan tashqarida qoladi.

Keyingi qatlami SSL oqimi boʻlgan WebSocket oqimi uchun buferli qoʻl berishuv variantidan foydalaning. Mavjud yield_context sessiyasida buffer ni barcha amallar davomida tirik saqlab:

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

Erta qaytishlar sessiyaning muvaffaqiyatsizlik chiqishlari; u yerda odatiy xato hisoboti va tozalashni ulang. Tunnelni faqat muvaffaqiyatli CONNECT javobi oʻrnatadi. Rad etish sahifasi TLS kirishiga aylanmasligi kerak.

Buferli variant xato kodi va baytlar soni bilan tugaydi. Bu son berilgan buferlardan qancha bayt sarflanganini bildiradi. Tugagach, aynan oʻsha prefiksni consume(used) bilan olib tashlang. Amal boshlanishidan oldin buferni tozalamang, qoʻl berishuv kutilayotganda uning omborini oʻzgartirmang va amal berilgan har bir baytni sarfladi deb oʻylamang.

CONNECT dan soʻng darhol klient boshlagan oddiy TLS da bufer boʻsh boʻlishi mumkin. Variant bu holatni ham koʻrib chiqadi. Uning maqsadi oqim chegaralarini saqlash; u ixtiyoriy keyingi proksi maʼlumotlarini haqiqiy TLS ga aylantirmaydi. Qoʻl berishuvdan oldin SSL qatlamida maqsad xost nomini tekshirish va SNI sozlamasini saqlang, WebSocket yangilanishini faqat TLS muvaffaqiyatli boʻlgandan keyin boshlang.