الخلاصة

  • سمّى RFC 1945 في مايو 1996 الرمز 302 «Moved Temporarily» واشترط تأكيد المستخدم قبل تحويل POST آلياً. أبقى RFC 2068 في يناير 1997 التحفظ، وسجّل أن بعض العملاء يبدلون POST إلى GET، وعرّف 303 «See Other» لقراءة مورد آخر بطريقة GET.
  • أعاد RFC 2616 في يونيو 1999 تسمية 302 إلى «Found»، وقال إن معظم برامج العميل القائمة تعاملت معه مثل 303، فتطلب عنوان Location بطريقة GET أياً كانت الطريقة الأولى. أضاف 307 «Temporary Redirect» لتمييز الحفاظ على الطريقة؛ وكان 303 موجوداً منذ 1997.
  • ما زال RFC 9110 الصادر في يونيو 2022 يسمح لأسباب تاريخية بتغيير POST إلى GET بعد 302. أما العميل الذي يتبع 307 آلياً فلا يجوز له تغيير الطريقة. يحدد ذلك ما إذا كان متن النموذج سيصل إلى العنوان الجديد.

نقل العنوان لا يحدد ما الذي يُنقل

في RFC 1945، النص الأصلي لـ HTTP/1.0 المنشور في مايو 1996، حمل الرمز 302 اسم «Moved Temporarily». المورد المطلوب موجود مؤقتاً في URL آخر يورده الخادم في Location. ولأن النقل قد يتغير، يستمر العميل في استخدام العنوان الأصلي مستقبلاً. إذا كان الطلب GET، يبدو الأمر كإشارة طريق: اسأل هنا، واقرأ الوثيقة هناك.

أما POST فيحمل غالباً نموذجاً وفعلاً طلبه المستخدم. عندما يرسل الخادم عنواناً مؤقتاً، هل يعيد المتصفح إرسال البيانات ذاتها إلى المكان الجديد؟ نص 1996 منع التحويل الآلي لطلب POST بعد 302 من دون إمكان تأكيد المستخدم. انتقال الوجهة قد يغير الشروط التي اختار الشخص على أساسها تقديم بياناته.

للتحويل محوران منفصلان. يجيب Location عن أين يذهب الطلب الثاني. وتجيب طريقة الطلب ومتنه عن ما الذي سيحدث هناك. إبقاء POST قد يحمل حقول النموذج إلى خادم آخر. تحويله إلى GET يطلب مورداً من دون إعادة الإرسال. تصوير 302 كسهم على خريطة وحدها يمحو هذا الاختلاف.

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

قال 303 «اقرأ»، وبعض العملاء فعلوا ذلك عند 302

أبقى RFC 2068، مواصفة HTTP/1.1 من يناير 1997، تسمية «Moved Temporarily» واشترط تأكيداً قبل التحويل الآلي لطلب لا يستخدم GET أو HEAD. وسجّلت ملاحظة في النص اختلافاً قائماً: بعض عملاء HTTP/1.0 كانوا يغيّرون POST إلى GET عندما يتبعون 302 آلياً. وصف النص هذا السلوك بأنه مخالف للقاعدة التي يحددها.

عرّف المستند نفسه 303 «See Other». بعد معالجة POST، يستطيع الخادم الإشارة إلى مورد آخر يُقرأ بطريقة GET. نتيجة برنامج شغّله POST مثال أساسي: يحدث الفعل في العنوان الأول، ثم تُقرأ صفحة تعرض النتيجة في العنوان الثاني. العنوان الجديد ليس مجرد اسم بديل للمورد الأول. أعطى 303 للمرسل وسيلة صريحة ليقول: انتهت العملية، اقرأ الناتج.

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

دخلت أغلبية العملاء في نص 1999

أعاد RFC 2616 الصادر في يونيو 1999 اسم 302 إلى «Found». الأهم ملاحظته: لم تسمح وثيقتا 1996 و1997 بتغيير الطريقة أثناء التحويل، لكن معظم برامج العميل القائمة تعاملت مع 302 كما لو كان 303، فأرسلت GET إلى Location بصرف النظر عن طريقة الطلب الأولى. كلمة «معظم» حكم الوثيقة الأصلية على الواقع آنذاك، وليست إحصاءً حديثاً لنسخ المتصفحات.

قدّم النص خيارات أوضح للخادم. ظل 303 يدل على قراءة مورد مختلف بطريقة GET، ولا سيما بعد فعل أطلقه POST. وكان هذا الرمز معرّفاً في 1997. الإضافة الجديدة في 1999 هي 307 «Temporary Redirect»، الذي يوضح الاتجاه الآخر: انقل الطلب مؤقتاً إلى عنوان جديد مع الحفاظ على طريقته. يفرّق الرقمان بين طلب قراءة نتيجة وطلب إكمال الفعل نفسه.

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

من يدير نموذجاً يرى الفرق فوراً. إذا عولج الإرسال، فقراءة صفحة تأكيد بطريقة GET لا تعيد المتن. إذا كانت العملية ستُستكمل في عنوان مؤقت، فلا بد أن تصل طريقة POST ومتنه. بعد اختلاف العملاء، يؤدي الاعتماد على 302 وحده إلى ترك جزء من القرار لعادات المتصفح.

العادة القديمة تكتب بنداً في معيار 2022

يحمل RFC 9110 الصادر في يونيو 2022 حول دلالات HTTP أثر ذلك التفاوض. لأسباب تاريخية، يجوز لبرنامج العميل أن يغيّر POST إلى GET بعد 302. الجواز لا يلزم كل عميل بالتحويل. إذا لم يرد الخادم هذا السلوك، يشير النص إلى 307. من يتبعه آلياً لا يجوز له تغيير طريقة الطلب.

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

وللحفاظ على POST ثمن أيضاً. تحت 307، يمكن أن يذهب متن النموذج إلى URI الذي يحدده Location. إذا كان الفعل يجب أن يستمر هناك، فذلك هو المقصود. وإذا كانت الوجهة تحت إدارة مختلفة، فإن انتقال المتن قرار حساس. التحويل إلى GET لا يكرر المتن، لكنه لا ينفذ عملية تتطلب فعلاً استمرار POST. يختار صاحب الخادم الرمز بحسب العملية التي يريدها، لا بحسب حداثة الرقم.

لا تسمي الوثائق الأربع إصدارات كل متصفح التي بدأت تبديل الطريقة؛ ستحددها سجلات تنفيذ مؤرخة. أما المسار الرئيس فواضح في الأصول: قيد في 1996، اختلاف مسجل في 1997، اعتراف بسلوك الأكثرية وإضافة 307 في 1999، وإذن تاريخي باقٍ في 2022.

الطريقة جزء من الحمولة

يبدو رد 3xx أحياناً لافتة تقول إن الصفحة تحركت. تكشف قصة 302 أن الطلب ينقل فعلاً أيضاً. قد يحتوي POST بيانات وقراراً اتخذه المستخدم. إعادته إلى URI جديد ليست مثل قراءة صفحة هناك بطريقة GET. يحدد Location المكان؛ ويحدد الرمز والمتصفح ما الذي يعبر الحد بين المكانين.

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

القراءة العملية الآن في ثلاثة أرقام متجاورة: قد يحوّل 302 طلب POST إلى GET؛ ويطلب 303 قراءة مورد آخر؛ ويحفظ 307 الطريقة عند النقل المؤقت الآلي. يأخذ النموذج نفسه مسارات مختلفة بحسب الرقم. التباس الرمز الأقدم نتج من أن العملاء أجابوا السؤال قبل أن يلحق بهم النص.

المصادر