Leve o buffer CONNECT do Beast para o handshake TLS

Depois que o Beast lê o cabeçalho da resposta CONNECT de um proxy, inspecione tanto o status da resposta quanto o buffer dinâmico. A operação de leitura pode obter bytes além do terminador do cabeçalho e retê-los no buffer fornecido. Iniciar o TLS com uma sobrecarga que só lê o socket deixa esses bytes retidos fora do caminho de entrada do TLS.

Para um fluxo WebSocket cuja próxima camada é o fluxo SSL, use a sobrecarga de handshake com buffer. Numa sessão yield_context existente, mantendo buffer vivo durante todas as operações:

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 antecipados são as saídas de falha da sessão; anexe ali o relatório de erros e a limpeza habituais. Só uma resposta CONNECT bem-sucedida estabelece o túnel. Uma página de rejeição não deve tornar-se entrada do TLS.

A sobrecarga com buffer termina com um código de erro e uma contagem de bytes. Essa contagem descreve quantos bytes ele consumiu dos buffers fornecidos. Após a conclusão, remova exatamente esse prefixo com consume(used). Não limpe o buffer antes de iniciar a operação, não altere o seu armazenamento enquanto o handshake está pendente e não assuma que a operação consumiu todos os bytes fornecidos.

Com o TLS comum iniciado pelo cliente logo após o CONNECT, o buffer pode estar vazio. A sobrecarga também trata desse caso. O objetivo é preservar as fronteiras do fluxo; ela não torna dados de proxy arbitrários posteriores em TLS válido. Mantenha a verificação do nome do host de destino e a configuração de SNI na camada SSL antes do handshake, e inicie a atualização para WebSocket somente depois que o TLS tiver êxito.