الخلاصة

  • يعرّف draft-ietf-httpbis-connect-tcp-14 خدمة الوكيل بقالب URI يحتوي target_host وtarget_port، ويصبح URI الناتج مورداً لاتصال connect-tcp.
  • يختار القالب أصل الوكيل والمسار ونطاق الحماية ومكان تطبيق سياسة الوجهة؛ لذلك تصبح جهة توفير القالب جزءاً من دليل التفويض.
  • تنتهي Last Call لدى IETF في 1 أكتوبر 2026. ما يزال النص Internet-Draft، وليس RFC معتمداً ولا دليلاً على التنفيذ أو النشر.

سلسلة الإعداد أصبحت تختار البوابة

يعرض CONNECT التقليدي اسم المضيف والمنفذ المستهدفين. أما المراجعة 14 فتبدأ بقالب URI لدى العميل، ثم تُدخل فيه قيمتا المضيف والمنفذ ويرسل الطلب إلى المورد الناتج عند أصل الوكيل.

هذا الاختيار يحدد أين تصل بيانات الاعتماد، وأي مسار تعالجه بوابة HTTP، وإلى أي أصل ترتبط HSTS وAlt-Svc وملفات الارتباط. لذلك لا يكون القالب مجرد صيغة كتابة؛ من يسيطر عليه يحدد الحارس الذي يسبق النفق.

يستعير المشروع شروط RFC 9298. يجب أن يكون القالب مطلقاً، وأن يضم scheme وauthority وpath غير فارغة، وأن تبقى المتغيرات في path أو query، وأن يتضمن متغيرَي الوجهة، مع منع بعض عمليات التوسيع. إذا اكتشف العميل مخالفة فعليه رفض الإعداد قبل إرسال الطلب.

يثبت هذا الفحص أن البنية مسموحة. لكنه لا يثبت من وزع القالب، ولا أن له صلاحية تغيير مسار الخروج، ولا أن الأصل تابع للخدمة الإدارية المقصودة. يمكن لإعداد مخترق أن يكون صحيحاً تماماً من منظور المحلل.

لكل استجابة HTTP معنى محدود

في HTTP/1.1 يرسل العميل GET إلى URI الموسع ويطلب Upgrade: connect-tcp. إذا كان الطلب سليماً ومسموحاً، يحاول الوكيل إنشاء اتصال TCP قبل الرد النهائي. النجاح يؤدي إلى 101 Switching Protocols، ولا يجوز تبديل البروتوكول إذا لم ينشأ الاتصال.

في HTTP/2 وHTTP/3 يعلن الوكيل دعم extended CONNECT. يستخدم العميل :protocol = connect-tcp، ويضع أصل الوكيل في :authority، ويأخذ المسار وscheme من القالب. بعد رد CONNECT ناجح يحمل التدفق الكبسولات.

يفصل Expect: 100-continue مرحلة أسبق. تعني 100 أن الوكيل استلم الطلب ولم يرفضه فوراً؛ ولا تنتظر نجاح المصافحة مع الوجهة. أما 101 أو نجاح extended CONNECT فيضيف أن الوكيل أفاد بقيام TCP. لا يثبت ذلك هوية التطبيق البعيد أو قبول شهادة TLS أو وصول الحمولة أو تنفيذ المهمة.

لهذا يجب ألا تختصر المراقبة المراحل بكلمة «نجح». رفض السياسة قبل المحاولة، وفشل إنشاء TCP، وفشل التطبيق داخل نفق قائم هي حالات مختلفة ولها جهات مسؤولية مختلفة.

بيانات الاعتماد تخص نطاق حماية الوكيل

لأن للوكيل أصلاً واضحاً، تستخدم المصادقة عادة 401 وWWW-Authenticate وAuthorization. لا يستخدم المشروع حقول 407 التقليدية لأنها لا تعبر بوابات HTTP العادية. وتُعامل الموارد الناتجة عن قالب واحد عادة على أنها ضمن protection space واحد، كما يمكن استخدام شهادة TLS للعميل.

يمكن للمشغل بذلك إعادة استخدام التوجيه حسب المسار، والحماية من DDoS، وتنقية الطلب، وتفويض المستخدم. وقد يخفي مسار عالي العشوائية أو concealed authentication الخدمة عن المسح غير المصرح.

لكن بيانات اعتماد صحيحة تجيب سؤالاً واحداً: هل استوفى هذا الطرف مخطط المصادقة الخاص بنطاق حماية الوكيل؟ سياسة أخرى تسمح بالمضيف والمنفذ أو تمنعهما. DNS يختار عنواناً. TLS عند الوجهة يتحقق من هوية أخرى. والتطبيق يقرر إن كان الفعل التجاري مسموحاً.

يحذر RFC 9110 من أن CONNECT المفتوح إلى منافذ عشوائية قد يحول الوكيل إلى مرحّل لبروتوكولات غير مقصودة. قالب URI لا يلغي الخطر، بل يمنح السياسة موضعاً أوضح.

DATA تحفظ الترتيب وFINAL_DATA تحفظ الإغلاق الاتجاهي

تنتقل حمولة TCP في كبسولات DATA. ويمكن لـ FINAL_DATA أن تحمل آخر البايتات وأن تعني أيضاً FIN لذلك الاتجاه. بعدها لا يجوز إرسال DATA أو FINAL_DATA أخرى. يجب تحويل FIN القادم من TCP إلى FINAL_DATA، وتحويل FINAL_DATA الصالحة إلى FIN نحو TCP.

لا تتطابق حدود الكبسولات بالضرورة مع مقاطع TCP أو سجلات TLS أو إطارات HTTP أو رسائل التطبيق. يستطيع الوسيط دمج الكبسولات المتعاقبة أو تقسيمها إذا حافظ على ترتيب البايتات وعلى نوع الكبسولة الأخيرة.

إذن يحفظ العقد المشترك التسلسل ونصف الإغلاق، لا معنى العمل. قد يكون العميل كتب في تدفق HTTP بينما ما يزال الوكيل يحتفظ بالبيانات المتفائلة. وقد يكتب الوكيل في socket من دون أن يعالج التطبيق شيئاً. وقد تنقل FINAL_DATA إشارة FIN فيما ينتهي الاتجاه العكسي بقطع مفاجئ.

في HTTP/2 وHTTP/3 يجب تخزين optimistic data حتى يصبح اتصال TCP المختار قابلاً للكتابة، ثم حذفها إذا فشل. وعند سباق عدة عناوين لا يجوز إرسال الحمولة إلى الاتصالات الخاسرة. لذلك تفصل السجلات بين مصدر القالب، وشهادة الوكيل، والمصادقة، والسياسة، وDNS، ومحاولة TCP، وحالة HTTP، وترتيب DATA/FINAL_DATA، وTLS عند الوجهة، والبايتات، والإغلاق، والنتيجة المرصودة.

Last Call ليست دليلاً على التشغيل

تطلب رسالة IESG التعليقات حتى 1 أكتوبر. ويسجل Datatracker المراجعة 14 كمسودة نشطة مقدمة إلى IESG ومرشحة لحالة Proposed Standard.

قد يتغير النص أو يُستبدل أو تنتهي صلاحيته. وحتى صدور RFC لاحقاً سيثبت عقد توافق، لا وجود الشفرة في المنتجات ولا توافق البوابات ولا صحة half-close ولا سياسة تشغيل آمنة.

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

يستطيع الوكيل السماح بالنفق. لكنه لا يستطيع أن يشهد بالنيابة عن كل ما يقع بعده.

المصادر