Đưa bộ đệm CONNECT của Beast vào bắt tay TLS
Chuyển các byte còn lại sau phản hồi CONNECT cho bắt tay TLS có bộ đệm của Asio, rồi tiêu thụ đúng lượng mà nó đã dùng.
Sau khi Beast đọc tiêu đề phản hồi CONNECT của proxy, hãy kiểm tra cả trạng thái phản hồi và bộ đệm động. Thao tác đọc có thể lấy các byte vượt quá điểm kết thúc tiêu đề và giữ chúng trong bộ đệm được cung cấp. Nếu khởi động TLS bằng một overload chỉ đọc socket, các byte được giữ đó sẽ nằm ngoài đường dẫn đầu vào TLS.
Với luồng WebSocket có lớp kế tiếp là luồng SSL, hãy dùng overload bắt tay có bộ đệm. Trong một phiên yield_context hiện có, giữ buffer sống trong suốt mọi thao tác:
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);
Các lần trả về sớm là lối thoát thất bại của phiên; gắn báo cáo lỗi và dọn dẹp thông thường ở đó. Chỉ một phản hồi CONNECT thành công mới thiết lập đường hầm. Trang từ chối không được trở thành đầu vào TLS.
Overload có bộ đệm kết thúc với mã lỗi và số byte. Con số đó mô tả nó đã tiêu thụ bao nhiêu byte từ các bộ đệm được cung cấp. Sau khi hoàn tất, hãy xóa đúng tiền tố đó bằng consume(used). Đừng xóa bộ đệm trước khi thao tác bắt đầu, đừng thay đổi kho lưu trữ của nó khi bắt tay đang chờ, và đừng cho rằng thao tác đã tiêu thụ mọi byte được cung cấp.
Với TLS thông thường do máy khách khởi động ngay sau CONNECT, bộ đệm có thể trống. Overload cũng xử lý trường hợp đó. Mục đích của nó là giữ ranh giới luồng; nó không biến dữ liệu proxy tùy ý phía sau thành TLS hợp lệ. Giữ việc xác minh tên máy chủ đích và cấu hình SNI trên lớp SSL trước khi bắt tay, và chỉ bắt đầu nâng cấp WebSocket sau khi TLS thành công.