Lleva el búfer CONNECT de Beast al handshake TLS

Pasa los bytes retenidos tras una respuesta CONNECT al handshake TLS con búfer de Asio y consume exactamente la cantidad que haya usado.

Después de que Beast lea la cabecera de respuesta CONNECT de un proxy, inspecciona tanto el estado de la respuesta como el búfer dinámico. La operación de lectura puede obtener bytes más allá del terminador de la cabecera y retenerlos en el búfer suministrado. Iniciar TLS con una sobrecarga que solo lee el socket deja esos bytes retenidos fuera de la ruta de entrada de TLS.

Para un flujo WebSocket cuya capa siguiente es el flujo SSL, usa la sobrecarga de handshake con búfer. En una sesión yield_context existente, manteniendo buffer vivo durante todas las operaciones:

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

Los retornos tempranos son las salidas de fallo de la sesión; allí se enlazan el informe de errores y la limpieza habituales. Solo una respuesta CONNECT correcta establece el túnel. Una página de rechazo no debe convertirse en entrada de TLS.

La sobrecarga con búfer termina con un código de error y un recuento de bytes. Ese recuento describe cuántos bytes consumió de los búferes suministrados. Tras completarse, elimina exactamente ese prefijo con consume(used). No vacíes el búfer antes de empezar la operación, no modifiques su almacenamiento mientras el handshake está pendiente y no supongas que la operación consumió todos los bytes suministrados.

Con el TLS habitual iniciado por el cliente justo después de CONNECT, el búfer puede estar vacío. La sobrecarga también maneja ese caso. Su propósito es preservar los límites de flujo; no convierte datos de proxy arbitrarios posteriores en TLS válido. Mantén la verificación del nombre de host de destino y la configuración de SNI en la capa SSL antes del handshake, y comienza la actualización a WebSocket solo después de que TLS tenga éxito.

Artículos relacionados