După ce Beast citește antetul răspunsului CONNECT al unui proxy, inspectează atât starea răspunsului, cât și bufferul dinamic. Operația de citire poate aduce octeți dincolo de terminarea antetului și îi poate păstra în bufferul furnizat. Dacă pornești TLS cu o supraîncărcare care citește doar socketul, acei octeți păstrați rămân în afara căii de intrare TLS.

Pentru un flux WebSocket a cărui următoare strat este fluxul SSL, folosește supraîncărcarea de handshake cu buffer. Într-o sesiune yield_context existentă, păstrând buffer viu pe durata tuturor operațiilor:

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

Returnările timpurii sunt ieșirile de eșec ale sesiunii; atașează acolo raportarea obișnuită a erorilor și curățarea. Doar un răspuns CONNECT reușit stabilește tunelul. O pagină de respingere nu trebuie să devină intrare TLS.

Supraîncărcarea cu buffer se încheie cu un cod de eroare și un număr de octeți. Acel număr descrie câți octeți a consumat din bufferele furnizate. După finalizare, elimină exact acel prefix cu consume(used). Nu goli bufferul înainte de începerea operației, nu modifica stocarea lui cât timp handshake-ul este în așteptare și nu presupune că operația a consumat fiecare octet furnizat.

La TLS obișnuit inițiat de client imediat după CONNECT, bufferul poate fi gol. Supraîncărcarea tratează și acest caz. Scopul ei este să păstreze limitele fluxului; nu transformă date proxy arbitrare ulterioare în TLS valid. Păstrează verificarea numelui de gazdă destinație și configurația SNI pe stratul SSL înainte de handshake și începe upgrade-ul WebSocket doar după ce TLS reușește.

Articole similare