يحفظ المستخدم نموذج طلب خدمة ثم يحدث الصفحة، فيظهر تحذير إعادة الإرسال أو تتكرر العملية. قبل إخفاء التحذير في الواجهة، افحص تسلسل HTTP الذي يلي الحفظ. هل المتصفح يعرض استجابة POST نفسها، أم انتقل إلى مورد يمكن قراءته بطلب مستقل؟
افهم دور 303 في رحلة الحفظ
توضح مواصفة HTTP في RFC 9110 أن 303 يوجه إلى مورد آخر يقدم استجابة غير مباشرة للطلب الأصلي، ويمكن جلبه باستخدام GET أو HEAD. وتصف 307 بتحويل يحافظ على طريقة الطلب عند اتباعه تلقائيًا. لذلك لا تختَر رمز التحويل بناء على الشكل النهائي للصفحة فقط.
في مثال افتراضي، ينشئ POST سجل طلب واحدًا ثم يعيد 303 مع Location لصفحة النتيجة. يقرأ المتصفح الصفحة التالية عبر GET وفق الرحلة المقصودة. صفحة النتيجة ليست تصريحًا لإعادة إنشاء الطلب، ويجب أن يظل الوصول إلى تفاصيلها خاضعًا لصلاحيات المستخدم.
التقط السلسلة الفعلية
| الخطوة | ما تثبته في الاختبار |
|---|---|
| إرسال نموذج صحيح | طريقة POST والحقول المقصودة |
| استجابة الحفظ | رمز التحويل ووجهة Location |
| طلب صفحة النتيجة | طريقة القراءة وهوية السجل الصحيح |
| تحديث صفحة النتيجة | عدم إنشاء سجل جديد بسبب هذا التحديث |
لا تخلط التحويل بمنع التكرار
قد يضغط المستخدم زر الحفظ مرتين قبل أن يصل التحويل، أو يعيد عميل آخر إرسال POST بعد انقطاع الشبكة. نمط Post/Redirect/Get لا يضمن وحده تنفيذ العملية مرة واحدة. حدد سياسة تكرار مستقلة في الخادم بحسب طبيعة العملية، واختبرها ببيانات مصطنعة دون تشغيل طلبات مدفوعة أو إرسال رسائل حقيقية.
راجع كذلك فشل التحقق قبل الحفظ وفشل قراءة النتيجة بعد نجاحه. تعذر فتح صفحة التأكيد لا يعني تلقائيًا أن الإنشاء فشل؛ يحتاج العميل طريقة لمعرفة حالة العملية قبل إعادة الإرسال، بدل الاعتماد على رسالة عامة.
اعتمد النتيجة من البيانات نفسها
ضمن تطوير الويب والفحص التقني سلّم سلسلة الطلبات وعدد السجلات ومعرف العملية قبل تحديث الصفحة وبعده. لا تضع أسرارًا أو بيانات النموذج في رابط النتيجة أو سجل مشترك. معيار القبول رحلة واضحة بين الكتابة والقراءة، مع بقاء صلاحيات العرض وسياسة منع التكرار مسؤوليتين مختبرتين في الخادم.
