Summary

  • وصف تنفيذ HTTP الخاص بالويب في 1991 طلب GET واحداً تعقبه وثيقة HTML؛ وكان الخادم يعلن النهاية بإغلاق الاتصال.
  • لم يتضمن هذا التبادل سطر حالة أو ترويسات. وتقول ملاحظات التصميم إن الخطأ يعود في صورة وثيقة ولا يمكن تمييزه من النجاح إلا بقراءة النص.
  • أضاف HTTP لاحقاً الإصدار والترويسات وأكواد الحالة، مع الإبقاء على الصيغة البسيطة للتوافق؛ ولا يبيّن هذا الاستمرار مدى انتشار HTTP/0.9.

كانت الصفحة هي الرد كله

في تنفيذ الويب الموصوف عام 1991، يفتح العميل اتصالاً بالخادم، ويستخدم المنفذ 80 افتراضياً إذا لم يحدده العنوان، ثم يرسل سطراً يتضمن GET ومعرّف المستند. يعيد الخادم تدفقاً من بايتات HTML ويغلق الاتصال عند إتمام إرسال الوثيقة. لا يسبق الصفحة سطر حالة مستقل ولا تتبعها كتلة ترويسات؛ فأول بايت يصل هو بالفعل جزء من المستند.

لا يصف سجل Tim Berners-Lee غلافاً خفياً لبروتوكول HTTP يحيط بكل صفحة. فهو يسمي الرد رسالة HTML، ويقول إن إغلاق الاتصال ينهيها. كما يوضح أن الخادم يستطيع إرسال نص خطأ مقروء بصيغة HTML. ثم يحدد القيد مباشرة: لا توجد وسيلة لتمييز رد الخطأ من الرد الناجح إلا عبر النص نفسه. يستطيع المتصفح عرض ما وصله، لكن صيغة السلك لا تقدم رمزاً تقرؤه الآلة لمعنى «غير موجود» أو إعادة توجيه أو خطأ خادم.

يعرض ملخص يونيو 1992 مفاضلة التصميم. لا يرسل المتصفح إلا أمراً واحداً هو GET يتبعه معرّف وثيقة، وقد يضم كلمات مفتاحية للبحث في فهرس مسمى. ولا يحتفظ الخادم بحالة تخص المتصفح. ويمكن أن يكون الرد HTML أو نصاً عادياً، وأن يحمل وثيقة أو قائمة أو نتائج بحث. كانت البساطة ميزة: لا يخرج من الخادم سوى نص موسوم. لكن الملخص يذكر غياب حد لغوي يفصل معلومات HTTP عن محتوى الوثيقة ونوعها. رسالة الخطأ نفسها وثيقة، وقد يتجاوزها القارئ.

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

ولم يقتصر التصميم الأول على الصفحات الثابتة. فقد تشير علامة ISINDEX إلى أن يبني المتصفح استعلاماً بإلحاق كلمات مفتاحية بمعرّف الوثيقة، ثم يعيد الخادم قائمة نتائج بصيغة HTML. وفي شرحه للحاجة إلى بروتوكول جديد، يذكر Berners-Lee البحث في الفهارس والتفاوض التلقائي على الصيغة وإحالة العميل إلى خادم آخر ضمن قدرات الوصول للمعلومات المطلوبة. هذه أهداف أوسع للتصميم، وليست دليلاً على أن التبادل البسيط ذي السطر الواحد قدمها كلها.

توسيع الرد مع إبقاء القديم معروفاً

تُظهر رسالة عامة في قائمة www-talk من ديسمبر 1992 اقتراحاً لتوسيع البروتوكول. اقترح Berners-Lee أن تظل الخوادم الجديدة تتعرف على GET <url>، وأن يضيف العميل رمزاً للإصدار في السطر نفسه ثم ترويسات مثل From وAccept وAccept-Encoding. ويتضمن مثال الرد إصداراً وحقل رد ونوع MIME والطرائق المدعومة. كان ذلك مقترحاً قيد النقاش، لا تسجيلاً نهائياً للصيغة التي نُشرت فعلاً. لكنه يوضح الحاجة إلى أن يحمل الرد معلومات عن نفسه إضافة إلى محتواه.

وثّق RFC 1945، المنشور بصفة Informational في 1996، الصيغتين لاحقاً. بقي الطلب البسيط GET ومعه URI بلا ترويسات، وبقي الرد البسيط متن الكيان فقط وينتهي بإغلاق الخادم للاتصال. أما الرد الكامل فيبدأ بسطر حالة وقد يحمل ترويسات للرد والكيان. وينبه RFC إلى أن الطلب البسيط يمنع الخادم من تحديد نوع الوسائط المعادة. وقد أتاح إبقاء الصيغة القديمة قابلة للتعرف أن تراعي أنظمة HTTP اللاحقة العملاء والخوادم الأقدم من دون الادعاء بأنها ترسل الرسالة نفسها.

يهم ترتيب الأحداث هنا. فتعريف RFC اللاحق مفيد لفهم التوافق، لكنه لا يثبت المصادقة على معيار HTTP/0.9 مستقل عام 1991. وروى Berners-Lee لاحقاً أن أول خادم ويب وبرمجيات العملاء، ومنها متصفح الوضع السطري الذي طورته Nicola Pellow، أتيحت لمجتمع فيزياء الطاقة العالية ثم لمجتمعات النص التشعبي وNeXT في صيف 1991. كما قال إن مواصفات URI وHTML وHTTP نُشرت على أول خادم لتشجيع النقاش والتبني. توفر هذه المصادر سياقاً للتجربة، ولا تعدّ المنشآت التي استخدمت كل شكل من الرسائل.

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

المصادر