تقنية

تحويل HTTP يصفه المساعد: هل بقي الطلب POST؟

رسم توضيحي: POST إلى ع؛ 303: استرجاع ب؛ المثال يختار GET؛ 307: متابعة ب؛ الطريقة تبقى POST
مخطط من إعداد بحر العلوم. فرعان مؤلفان؛ لا طلب أو نجاح مثبت

إعادة توجيه 303 و 307 لا تفسر بالعنوان الجديد وحده عندما يراجع المساعد سجل HTTP. قد يبدأ الطلب بطريقة POST، ثم تختلف طريقة الطلب الذي يتبعه العميل بحسب رمز الرد. نقرأ RFC 9110 ، ونؤلف فرعين لنفس الطلب دون اتصال خادم أو إرسال نموذج.

الخلاصة السريعة

راجع رمز الرد وطريقة المتابعة؛ يتيح 303 طلب استرجاع GET أو HEAD لمورد آخر، أما 307 فيمنع تغيير الطريقة إذا تابع العميل التحويل تلقائيا. [1]

  • ينص 307 على عدم تغيير طريقة الطلب في التحويل التلقائي؛ في فرع POST المعلن تبقى POST، ولا نفترض أن المتابعة حدثت. [1]
  • في ورقتنا نختار بعد 303 متابعة GET، وبعد 307 متابعة POST؛ الاختيار الأول مثال استرجاع، لا قاعدة تحصر كل 303 في GET وحدها.
  • 303 يشير إلى مورد يقدم جوابا غير مباشر، ولا يعد URI الجديد مكافئا للأصلي؛ استرجاعه قد يكون GET أو HEAD. [1] لا تثبت الوجهة نجاح عمل لم يقدم سجله.
  • 307 تحويل مؤقت؛ يوجه المعيار إلى استمرار استعمال URI الأصلي لطلبات لاحقة. [1] احفظ الفرق بين الرد، والمتابعة، ونتيجتها، ولا نرسل طلبا في هذا المقال.

هل تغيير المكان يغير الطريقة؟

ينص RFC 9110 على أن العميل لا يغير طريقة الطلب إذا نفذ التحويل التلقائي مع 307. [1]

نعلن في ورقتنا أن الطلب الأول POST إلى مورد ع. عند قراءة رد 307 لا يكتب المساعد تلقائيا أن الطلب الثاني GET لأن عنوانا مختلفا ظهر. خانة العنوان وخانة الطريقة مستقلتان في التتبع.

القيد شرط على المتابعة إذا حصلت، ولا يثبت أن العميل تابع فعلا. قد تحتوي الورقة ردا فقط دون طلب تال؛ حينئذ نصف الرد ونترك تنفيذ المتابعة غير مقدم.

كيف نقارن فرعين لنفس البداية؟

ننطلق في فرعين مؤلفين من POST إلى ع. في الأول نفترض رد 303 مع Location يشير إلى ب، ثم نختار متابعة GET إلى ب. في الثاني نفترض رد 307 إلى ب، ثم نعلن متابعة تلقائية بطريقة POST.

الأسماء ع وب موارد رمزية، ولا تحمل أوراقنا بيانات جسم طلب. المقارنة تظهر اختلاف الطريقة في الفرعين، لا إعادة إرسال فعلية. اختيار GET في فرعنا لا يحذف إمكان HEAD الذي يذكره المعيار للاسترجاع.

الفرع المؤلفالطلب الأولالمتابعة المعلنة
رد 303 إلى بPOST إلى عGET إلى ب، باختيار المثال
رد 307 إلى بPOST إلى عPOST إلى ب، عند المتابعة التلقائية

هل المورد ب هو ع نفسه؟

يصف المعيار 303 بأنه يشير لمورد يقدم جوابا غير مباشر، ولا يعتبر URI الجديد مكافئا للأصلي، مع استرجاع GET أو HEAD. [1]

نضع في ورقة ب وصفا مقترحا «صفحة حالة»، لا نعلن أنها أثبتت نجاح POST إلى ع. حتى لو طلبت، يحتاج القول بالنجاح المادة التي قدمتها أو سجل العمل المعني.

لا ننقل إلى ب كل خصائص ع من مجرد العلاقة. كما لا يعني الرد أن الصفحة المطلوبة وصلت أو أن أي رقم داخلها تحقق. نحتاج خط المتابعة ونتيجته، ولا نختلقهما من رمز التحويل.

هل تصبح الوجهة الجديدة دائمة؟

يسمي RFC 9110 الرد 307 مؤقتا، ويوجه إلى استعمال URI الأصلي للطلبات اللاحقة لأن التحويل قد يتغير. [1]

لذلك نرسم متابعة واحدة إلى ب دون شطب ع من كل استعمال مستقبلي. إذا كتب المساعد «انتقل المورد نهائيا»، تجاوز دلالة الرمز الذي قدمناه في هذا المثال.

لم نرسل POST أو GET أو HEAD، ولم نفحص عميل HTTP أو خادما. يفيد الجدول في قراءة طريقة محددة ضمن رد محدد، مع إبقاء التنفيذ والنتيجة والمورد والعنوان مسائل منفصلة في الملخص.

المصادر ومتابعة القراءة

  1. RFC9110: HTTP Semantics, sections15.4.4 and15.4.8 (يفتح في نافذة جديدة)rfc-editor.org

أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.