لنفترض أن east.proxy.example وwest.proxy.example يُحلّان إلى المستمع نفسه للوكيل عبر HTTP العادي. يمكن للعميل الذي يستخدم أيًّا من الاسمين أن يرسل:

GET http://www.example.org/report HTTP/1.1
Host: www.example.org

الطلب يحدد الموقع. وهو لا يحمل الاسم المستعار للوكيل الذي حلّه العميل قبل فتح TCP. لذلك لا يستطيع اسم المضيف المشتق من Host في Express اختيار مسار بناءً على نطاقات الوكيل الفرعية تلك.

إذا كنت تتحكم في العميل والوكيل، فوفّر مُدخل توجيه صريحًا. بالنسبة إلى وكيل يطبّق وسم X-Route:

curl --proxy http://east.proxy.example:8080 \
  --proxy-header 'X-Route: east' \
  https://www.example.org/

--proxy-header يستهدف التواصل مع الوكيل، بما في ذلك CONNECT. أما ترويسة -H العادية على طلب HTTPS فمكانها داخل تبادل HTTP المشفّر الخاص بالوجهة.

على الخادم أن يطبّق سياسة التوجيه ويصرّح بها، ثم يستهلك الوسم دون تمريره إلى الموقع. بدلًا من ذلك، استخدم نقاط استماع أو حسابات وكيل مُهيّأة بشكل منفصل كمدخلات للتوجيه.

بالنسبة إلى وجهات HTTPS، يتلقى Node طلب النفق الأولي عبر حدث connect الخاص بخادم HTTP. ولا تتعامل برمجيات Express الوسيطة العادية مع ذلك الحدث. ولا يزال هدف CONNECT يحدد خادم الوجهة، لا الاسم المستعار للوكيل.

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