Portu la CONNECT-bufron de Beast en la TLS-manpremon

Post kiam Beast legas la CONNECT-respondan kaplinion de prokurilo, kontrolu kaj la respondan statuson kaj la dinamikan bufron. La lega operacio povas preni bajtojn preter la kaplinifino kaj reteni ilin en la donita bufro. Se vi startas TLS per ŝarĝaĵo, kiu legas nur la ingon, tiuj retenitaj bajtoj restas ekster la TLS-eniga vojo.

Por WebSocket-fluo, kies sekva tavolo estas la SSL-fluo, uzu la bufritan manpreman ŝarĝaĵon. En ekzistanta yield_context-sesio, tenante buffer viva dum ĉiuj operacioj:

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

La fruaj revenoj estas la fiaskaj eliroj de la sesio; aldonu tie la kutiman erar-raportadon kaj purigadon. Nur sukcesa CONNECT-respondo starigas la tunelon. Rifuza paĝo ne rajtas fariĝi TLS-enigo.

La bufrita ŝarĝaĵo finiĝas per erarkodo kaj bajtokvanto. Tiu kvanto priskribas kiom da bajtoj ĝi konsumis el la donitaj bufroj. Post la fino forigu ĝuste tiun prefikson per consume(used). Ne malplenigu la bufron antaŭ la operacio, ne ŝanĝu ĝian konservejon dum la manpremo atendas, kaj ne supozu, ke la operacio konsumis ĉiun donitan bajton.

Ĉe ordinara klient-iniciatita TLS tuj post CONNECT, la bufro povas esti malplena. La ŝarĝaĵo traktas ankaŭ tiun kazon. Ĝia celo estas konservi fluajn limojn; ĝi ne faras arbitrajn postajn prokurilajn datumojn valida TLS. Konservu la kontrolon de la celloka gastigantnomo kaj la SNI-agordon sur la SSL-tavolo antaŭ la manpremo, kaj komencu la WebSocket-ĝisdatigon nur post sukcesa TLS.