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 संरचना ठेवा, आणि TLS यशस्वी झाल्यावरच WebSocket अपग्रेड सुरू करा.