Префрлете го CONNECT баферот на Beast во 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). Не го чистите баферот пред почетокот на операцијата, не го менувате неговото складиште додека ракувањето чека и не претпоставувајте дека операцијата ги потрошила сите доставени бајти.

Кај вообичаениот TLS што клиентот го стартува веднаш по CONNECT, баферот може да биде празен. Варијантата го обработува и тој случај. Нејзината цел е да ги зачува границите на текот; таа не прави произволни последователни прокси податоци валиден TLS. Пред ракувањето задржете ја проверката на името на целниот домаќин и SNI конфигурацијата на SSL слојот, а надградбата на WebSocket започнете ја само по успешен TLS.