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-ის წარმატების შემდეგ.