الخلاصة

  • حددت CGI/1.1 تسليماً مشتركاً للطلب والاستجابة بين خادم HTTP ونص، مع ترك بعض التفاصيل لما يحدده النظام أو التنفيذ.
  • وضعت RFC 3875 نطاق TLS بين العميل والخادم: يتوثق الخادم لدى العميل، بينما لا يحصل النص على آلية مدمجة للتحقق ممن استدعاه أو على سلامة مضمونة لرسائل CGI.

الاتصال محمي. لكن التطبيق قد لا يكون في الطرف الآخر منه.

هذا هو الحد الهادئ في RFC 3875، مواصفة Common Gateway Interface (CGI) الإصدار 1.1 المنشورة عام 2004. يستطيع المتصفح إنشاء اتصال TLS مع خادم ويب، ثم يمرر الخادم بيانات الطلب إلى برنامج CGI. لكن علاقة الأمان التي تصفها المواصفة لا تعبر التسليم الثاني كما هي. الخادم هو النظير الشبكي؛ أما النص فهو عملية تطبيقية خلفه.

كان CGI يؤدي وظيفة عملية قبل RFC 3875 بسنوات طويلة. فقد يعمل خادم HTTP بوابةً إلى قاعدة بيانات أو نظام معلومات قائم، بينما ينشئ النص استجابة انطلاقاً من الطلب. وتصف صفحة CGI التاريخية لدى W3C الواجهة بأنها اتفاق بين مطوري الخوادم لدمج نصوص وبرامج البوابات. وتسجل محاولة لتحديث CGI 1.1 في 1995، ثم إعادة تنشيط جهد في نوفمبر 1997 لتحويل الواجهة المتعارف عليها فعلياً إلى RFC معلوماتية. نُشر النص النهائي في أكتوبر 2004 ضمن مسار التقديم المستقل.

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

يسمي العقد «متغيرات فوقية» للطلب مثل REQUEST_METHOD وQUERY_STRING وCONTENT_LENGTH وPATH_INFO وREMOTE_ADDR. كما يحدد طريقة إعادة النص للرؤوس والمتن، بما في ذلك استجابات المستندات وإعادة التوجيه. وبذلك تحصل البرامج التي تعمل على خوادم مختلفة على مفردات مشتركة. ويقسم النص المسؤوليات أيضاً: يتولى الخادم اتصال العميل ونقل البيانات وبروتوكول الشبكة، بينما يتولى النص عمل التطبيق، مثل الوصول إلى البيانات ومعالجة المستندات.

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

ثم تضيق المادة 9.4 حد الثقة. ففي اتصال TLS، ينطبق نموذج الأمان بين العميل والخادم، لا بين العميل والنص. والخادم هو من يتوثق لدى العميل. لا توفر المواصفة للنص وسيلة لتوثيق الخادم الذي استدعاه، ولا تفرض سلامة على رسائل طلب CGI واستجابته.

لا يعني ذلك وجوب اعتبار النص معادياً أو عجز المشغل عن حماية العملية المحلية. يستطيع الخادم الاعتماد على أذونات نظام التشغيل أو قناة خاصة أو ضوابط محلية أخرى. النقطة أضيق من ذلك: TLS عند حافة HTTP لا يثبت وحده أن النص اللاحق هو النظير الشبكي الموثق نفسه. وإذا تلقى النص HTTPS=on أو اسم مستخدم في بيئته، فقد تلقى قيماً؛ ولم تمنحه واجهة CGI دليلاً تشفيرياً يربط تلك القيم بجلسة عميل موثقة.

ولم تحصر المعمارية التنفيذ في نموذج عملية واحد. تصف RFC 3875 العملية الفرعية العاملة باسم مستخدم الخادم ومجموعته بأنها التنفيذ الأكثر شيوعاً، لكنها تقر أيضاً بالنصوص المرتبطة داخل الخادم نفسه. كما تميز بين السلوك «المحدد بالنظام» والسلوك «المحدد بالتنفيذ». أمكن للواجهة المشتركة أن تنتقل بين الخوادم، لكن قابليتها للنقل كانت محدودة.

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

كان الإنجاز التاريخي لـ CGI حدّاً مشتركاً، لا عملية مشتركة ولا قناة أمان من طرف إلى طرف. استطاع الخادم والنص التعاون عبر واجهة مسماة مع بقائهما جهتين مختلفتين ومسؤوليتين منفصلتين. وتجنب قراءة المواصفة بهذه الطريقة خطأً في التصنيف: فالطلب المحمي بين المتصفح والخادم لا يتحول تلقائياً إلى علاقة محمية بين المتصفح والتطبيق. أوضحت RFC 3875 هذا الفصل؛ ولم تلغه.

المصادر