Տեղափոխել 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 կարգավորումը, և WebSocket թարմացումը սկսեք միայն TLS-ի հաջողությունից հետո։