នាំយក buffer CONNECT របស់ Beast ចូលទៅក្នុង handshake TLS

បន្ទាប់ពី Beast អាន header នៃការឆ្លើយតប CONNECT ពី proxy សូមពិនិត្យទាំងស្ថានភាពឆ្លើយតប និង buffer ថាមវន្ត។ ប្រតិបត្តិការអានអាចយក byte ហួសពីចុងបញ្ចប់ header ហើយរក្សាវាទុកក្នុង buffer ដែលបានផ្តល់។ ប្រសិនបើអ្នកចាប់ផ្តើម TLS ដោយ overload ដែលអានតែ socket នោះ byte ដែលរក្សាទុកនៅសល់ក្រៅផ្លូវបញ្ចូល TLS។

សម្រាប់ stream WebSocket ដែលស្រទាប់បន្ទាប់គឺ stream SSL សូមប្រើ overload handshake ដែលមាន buffer។ នៅក្នុង session 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);

ការត្រឡប់មកវិញដំបូងគឺជាច្រកចេញបរាជ័យរបស់ session សូមភ្ជាប់ការរាយការណ៍កំហុស និងការសម្អាតធម្មតានៅទីនោះ។ មានតែការឆ្លើយតប CONNECT ជោគជ័យប៉ុណ្ណោះដែលបង្កើត tunnel។ ទំព័របដិសេធមិនត្រូវក្លាយជាការបញ្ចូល TLS ទេ។

overload ដែលមាន buffer បញ្ចប់ដោយលេខកូដកំហុស និងចំនួន byte។ ចំនួននោះពិពណ៌នាថាវាបានប្រើប្រាស់ប៉ុន្មាន byte ពី buffer ដែលបានផ្តល់។ បន្ទាប់ពីបញ្ចប់ សូមដក prefix នោះចេញយ៉ាងជាក់លាក់ដោយ consume(used)។ កុំសម្អាត buffer មុនពេលចាប់ផ្តើមប្រតិបត្តិការ កុំផ្លាស់ប្តូរការផ្ទុករបស់វាខណៈ handshake កំពុងរង់ចាំ ហើយកុំសន្មតថាប្រតិបត្តិការបានប្រើប្រាស់រាល់ byte ដែលបានផ្តល់។

ជាមួយ TLS ធម្មតាដែល client ចាប់ផ្តើមភ្លាមៗបន្ទាប់ពី CONNECT buffer អាចទទេ។ overload ក៏ដោះស្រាយករណីនេះដែរ។ គោលបំណងរបស់វាគឺរក្សាព្រំដែន stream វាមិនធ្វើឱ្យទិន្នន័យ proxy បន្ថែមតាមអំពើចិត្តក្លាយជា TLS ត្រឹមត្រូវទេ។ រក្សាការផ្ទៀងផ្ទាត់ឈ្មោះ host គោលដៅ និងការកំណត់ SNI នៅលើស្រទាប់ SSL មុន handshake ហើយចាប់ផ្តើមការដំឡើង WebSocket តែបន្ទាប់ពី TLS ជោគជ័យប៉ុណ្ណោះ។