الخلاصة

  • تعرف RFC 9110 حقل Via كسجل مرتب لوكلاء وبوابات HTTP التي مررت رسالة بعينها؛ ويمكن استعمال أسماء مستعارة ودمج بعض الإدخالات في شروط محدودة.
  • يحتاج الادعاء باكتمال المسار إلى ربط حقول الطلب والاستجابة الأصلية بسجلات الدخول والخروج، والإعدادات، والأنفاق، والطبقات الأدنى، والتحويلات، والتوقيت.

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

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

تميز RFC 9110 بين الوكيل والبوابة والنفق. يختار العميل الوكيل لتمرير الرسائل. وتبدو البوابة كخادم أصل في جانبها الخارجي ثم تترجم الحركة أو تمررها إلى الداخل. أما النفق فيصبح مرحلاً أعمى بين اتصالين، ولا يعد بعد تفعيله طرفاً في اتصال HTTP. ويمكن لأجهزة في طبقات أدنى أن ترشح الحركة أو تعيد توجيهها من دون علم مرسلي HTTP. تأثير هذه الأجهزة في المسار لا يمنحها إدخالاً في Via.

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

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

كما أن received-by ليس سجلاً ثابتاً للأجهزة. يتضمن عادة مضيفاً ومنفذاً اختيارياً، لكن يمكن استبدال المضيف باسم مستعار إذا كان كشفه حساساً. وينبغي لبوابة عند جدار ناري ألا تكشف أسماء المضيفين الداخليين إلا بتمكين صريح. تعليقات البرمجيات اختيارية ويمكن حذفها قبل التمرير. ولأن Via غير موثق بالمصادقة، فالرمز مجرد إفادة عن التمرير؛ ولا تتأكد المشاركة إلا بالتقاط موثوق ودليل سلامة. كما لا يحدد الرمز وحده عنواناً قابلاً للتوجيه أو جهازاً أو عملية أو جهة مشغلة.

حتى طول القائمة يحتاج إلى سياق. لا تجيز RFC 9110 دمج تتابع مرتب إلا إذا اشتركت عناصره في قيمة received-protocol نفسها؛ وحتى عند تحقق ذلك، ينبغي للمرسل أن يمتنع عن الدمج ما لم تكن العناصر أيضاً تحت سيطرة تنظيمية واحدة وما لم تكن قيم المضيف قد استبدلت مسبقاً بأسماء مستعارة. ولا يجوز مطلقاً دمج عناصر ذات بروتوكولات استقبال مختلفة. وعند تطبيق هذه الشروط مجتمعة، تبقى حدود قدرة البروتوكول محفوظة ولا تُضغط إلا بنية داخلية خاضعة لإدارة واحدة ومخفاة الأسماء. لذلك قد يلخص عنصر ظاهر عدة جهات أعادت تمرير الرسالة.

أما التحويلات فلها مستوى دليل منفصل. يستطيع الوكيل تعديل حقول أو محتوى. وقد تترجم البوابة بين HTTP وبروتوكول خاص. ويحمل النفق بايتات مشفرة من دون كشف رسائل التطبيق أو كل المرحلات. يسجل Via المشاركة في تمرير HTTP، لكنه لا ينسب بالكامل تغييرات المحتوى أو قرار التخزين المؤقت أو الفحص الأمني أو موازنة الحمل أو الروابط المادية.

ينبغي أن يحفظ سجل تتبع الرسالة هوية الطلب والاستجابة، وقيم Via الخام في كل موضع التقاط، والبروتوكول والاتجاه، وربط الاسم المستعار بالوسيط الخاضع للإدارة، وقواعد الدمج، وأوقات الدخول والخروج، وقرارات التخزين والتحويل، وطرفي النفق، ومشاهدات الطبقات الأدنى. ويجب التفريق بين «غير ظاهر في Via» و«غير موجود في المسار». هذا السجل تركيب تشغيلي تحريري، وليس كائناً سلكياً تعرفه IETF.

يبقى الموضوع منفصلاً عن الأعمال المجاورة. تعالج عناوين IPv6 المؤقتة إمكان الربط بعد تبديل المعرف. وتعالج BFD حيوية محددة النطاق وقرار المسار. وتعالج أولوية HTTP أثر تفضيل الجدولة. أما Via فيعالج مصدر سجل تمرير الرسالة ومدى اكتماله.

المصادر