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 अपग्रेड शुरू करें।