يجب على معالجات CONNECT في Node.js الحفاظ على مخزن head المؤقت
تعامل مع مقبس CONNECT ومخزن head المؤقت في Node عند حدود HTTP إلى النفق، مع الحفاظ على البايتات المقروءة بالفعل بعد الترويسات.
يتعامل خادم Node HTTP مع طلب وكيل عادي عبر دالة رد النداء الخاصة بالطلب. أما CONNECT فيسلك مسارًا آخر: يصدر الخادم connect مع الطلب ومقبس العميل ومخزن head مؤقت.
هذا الحدث هو تسليم المسؤولية بين تحليل HTTP والنفق. لا يوجد كائن ServerResponse عادي يمكن الاستمرار في استخدامه لحركة النفق.
| الوسيط | ما يحمله |
|---|---|
req | طلب CONNECT، بما في ذلك جهة الوجهة والترويسات |
clientSocket | الاتصال العائد إلى العميل |
head | بيانات النفق التي قرأها Node بالفعل بعد ترويسات HTTP، وقد تكون فارغة |
أتمّ قرار HTTP قبل تمرير البايتات
تحقق من المضيف والمنفذ المطلوبين، وطبّق سياسة الوصول والمصادقة الخاصة بالوكيل، وأنشئ اتصال المنبع. يحدد CONNECT جهة مثل service.example:443؛ حلّل هذا الشكل مع مراعاة جهات IPv6 بدلًا من التقسيم الأعمى عند كل نقطتين.
عند قبول النفق، أرسل استجابة HTTP الناجحة متبوعة بالسطر الفارغ الذي ينهيها. ثم مرّر أي بايتات head إلى المنبع قبل المتابعة بالبايتات اللاحقة من مقبس العميل. لا يمكن لإرفاق مستمع بيانات جديد استعادة مخزن مؤقت سُلّم بالفعل على نحو منفصل إلى المعالج.
يؤدي مثال النفق الرسمي في Node ذلك التسليم باستخدام serverSocket.write(head) قبل وصل اتجاهي التدفق. يوضح مثاله الصغير الانتقال؛ ويحتاج الوكيل المنشور أيضًا إلى محاولات اتصال محدودة وضوابط وصول وإدارة دورة حياة.
بعد النجاح، تنتمي البايتات إلى بروتوكول الخدمة
تحوّل استجابة CONNECT الناجحة الاتصال إلى تدفق بايتات. إذا كان الهدف موقع HTTPS، فإن تبادل TLS يجري داخل ذلك التدفق. مجرد تمريره في نفق لا يتطلب من الوكيل إصدار شهادة موقع بديلة.
قبل قبول CONNECT، يمكن لخطأ HTTP أن يوضح سبب الرفض. بعد القبول، فإن كتابة HTTP 500 في التدفق ستحقن بايتات في بروتوكول النفق. أنهِ الاتصالات المناسبة أو أتلفها عند الأعطال اللاحقة بدلًا من ذلك.
اربط الاتجاهين بمعالجة تدفق تراعي الضغط العكسي عبر معالجة التدفق الواعية بالضغط العكسي، وحدد كيف تنهي أحداث end وerror وclose النظير. احتفظ بمخزن head الأولي كجزء من نموذج الملكية نفسه؛ فهو بيانات تطبيق وليس ترويسات HTTP فائضة تُهمل.