Beast ਦੇ CONNECT ਬਫ਼ਰ ਨੂੰ 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) ਨਾਲ ਬਿਲਕੁਲ ਉਹੀ ਪ੍ਰੀਫ਼ਿਕਸ ਹਟਾਓ। ਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬਫ਼ਰ ਸਾਫ਼ ਨਾ ਕਰੋ, ਹੈਂਡਸ਼ੇਕ ਬਕਾਇਆ ਹੋਣ ਵੇਲੇ ਇਸਦਾ ਭੰਡਾਰ ਨਾ ਬਦਲੋ, ਅਤੇ ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਕਿਰਿਆ ਨੇ ਦਿੱਤਾ ਹਰ ਬਾਈਟ ਖਪਤ ਕੀਤਾ ਹੈ।

CONNECT ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਕਲਾਇੰਟ ਵੱਲੋਂ ਸ਼ੁਰੂ ਕੀਤੇ ਆਮ TLS ਵਿੱਚ ਬਫ਼ਰ ਖਾਲੀ ਹੋ ਸਕਦਾ ਹੈ। ਓਵਰਲੋਡ ਉਹ ਸਥਿਤੀ ਵੀ ਸੰਭਾਲਦਾ ਹੈ। ਇਸਦਾ ਉਦੇਸ਼ ਸਟ੍ਰੀਮ ਸੀਮਾਵਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣਾ ਹੈ; ਇਹ ਕਿਸੇ ਵੀ ਵਾਧੂ ਪ੍ਰੌਕਸੀ ਡੇਟਾ ਨੂੰ ਵੈਧ TLS ਨਹੀਂ ਬਣਾਉਂਦਾ। ਹੈਂਡਸ਼ੇਕ ਤੋਂ ਪਹਿਲਾਂ SSL ਪਰਤ ’ਤੇ ਟਾਰਗਿਟ ਹੋਸਟਨਾਮ ਪੁਸ਼ਟੀ ਅਤੇ SNI ਸੰਰਚਨਾ ਰੱਖੋ, ਅਤੇ TLS ਸਫਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ WebSocket ਅਪਗ੍ਰੇਡ ਸ਼ੁਰੂ ਕਰੋ।