Beast को CONNECT बफर TLS ह्यान्डशेकमा ल्याउनुहोस्

Beast ले प्रोक्सीको CONNECT प्रतिक्रिया हेडर पढेपछि प्रतिक्रियाको स्थिति र गतिशील बफर दुवै जाँच्नुहोस्। पढ्ने कार्यले हेडरको अन्त्यभन्दा परका बाइटहरू ल्याउन सक्छ र तिनीहरूलाई दिइएको बफरमा राख्न सक्छ। केवल सकेट पढ्ने ओभरलोडबाट TLS सुरु गर्दा ती राखिएका बाइटहरू TLS इनपुट मार्गबाहिर रहन्छन्।

जसको अर्को तह SSL स्ट्रिम हो त्यस्तो WebSocket स्ट्रिमका लागि बफर भएको ह्यान्डशेक ओभरलोड प्रयोग गर्नुहोस्। विद्यमान 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 अपग्रेड सुरु गर्नुहोस्।