Leva o búfer CONNECT de Beast ao handshake TLS

Despois de que Beast lea a cabeceira de resposta CONNECT dun proxy, inspecciona tanto o estado da resposta como o búfer dinámico. A operación de lectura pode obter bytes máis alá do terminador da cabeceira e retelos no búfer subministrado. Se inicias TLS cunha sobrecarga que só le o socket, eses bytes retidos quedan fóra do camiño de entrada de TLS.

Para un fluxo WebSocket cuxa capa seguinte é o fluxo SSL, usa a sobrecarga de handshake con búfer. Nunha sesión yield_context existente, mantendo buffer vivo durante todas as operacións:

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

Os retornos temperáns son as saídas de fallo da sesión; engade alí a notificación de erros e a limpeza habituais. Só unha resposta CONNECT correcta establece o túnel. Unha páxina de rexeitamento non debe converterse en entrada de TLS.

A sobrecarga con búfer remata cun código de erro e un reconto de bytes. Ese reconto indica cantos bytes consumiu dos búfers subministrados. Despois de rematar, elimina exactamente ese prefixo con consume(used). Non baleires o búfer antes de comezar a operación, non modifiques o seu almacenamento mentres o handshake está pendente e non asumas que a operación consumiu todos os bytes subministrados.

Co TLS habitual iniciado polo cliente xusto despois de CONNECT, o búfer pode estar baleiro. A sobrecarga tamén xestiona ese caso. O seu propósito é preservar as fronteiras do fluxo; non converte datos de proxy arbitrarios en TLS válido. Mantén a verificación do nome de host de destino e a configuración SNI na capa SSL antes do handshake, e inicia a actualización a WebSocket só despois de que TLS teña éxito.