نقل مخزن CONNECT الخاص بـ Beast إلى مصافحة TLS

مرّر البايتات المتبقية بعد استجابة CONNECT إلى مصافحة TLS المخزّنة في Asio، ثم استهلك المقدار الذي استخدمته بالضبط.

بعد أن يقرأ 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) بعد الاكتمال. لا تفرّغ المخزن قبل بدء العملية، ولا تغيّر مساحته التخزينية والمصافحة معلّقة، ولا تفترض أن العملية استهلكت كل بايت ممرَّر.

مع TLS العادي الذي يبدأه العميل فورًا بعد CONNECT، قد يكون المخزن فارغًا. وتتعامل النسخة مع هذه الحالة أيضًا. غرضها حفظ حدود التدفق؛ وهي لا تجعل أي بيانات وسيط عابرة لاحقة TLS صالحًا. أبقِ التحقق من اسم المضيف الوجهة وإعداد SNI على طبقة SSL قبل المصافحة، وابدأ ترقية WebSocket فقط بعد نجاح TLS.

مقالات ذات صلة