HTTP حجز خانة للدفع منذ 1997؛ لكن الرمز 402 لم يحصل على قواعد للتحصيل

الخلاصة

• أدرج RFC 2068 الرمز 402 Payment Required في HTTP/1.1 في يناير 1997، ثم خصص له تعليمة واحدة: «محجوز للاستخدام المستقبلي».
• أبقى RFC 2616 وRFC 7231 وRFC 9110 على الحجز نفسه. لم يحدد HTTP سعراً موحداً أو طلب دفع أو قواعد تسوية للرمز 402.

الرقم ظهر قبل صندوق التحصيل

شرح RFC 1945 رموز الحالة بوصفها نتائج تقرؤها الآلات، وسرد القيم المعروفة في HTTP/1.0. في قائمة أخطاء العميل جاء 401 Unauthorized ثم 403 Forbidden، ولم يظهر 402 بينهما. سمحت الوثيقة برموز التوسعة، لذلك كان ممكناً استعمال رقم غير مدرج كتوسعة. ما غاب هو تعريفه داخل القائمة المنشورة. RFC 1945 §§6.1.1–6.1.2

أدخلت مواصفة HTTP/1.1 الصادرة في يناير 1997 الرمز 402 في قواعد رموز الحالة، وخصصت له القسم 10.4.3. لم تتجاوز القاعدة جملة واحدة: «This code is reserved for future use.» أشار الاسم إلى بوابة مالية، ولم يشرح النص المعياري كيفية عبورها. RFC 2068 §§6.1.2, 10.4.3

يمكن لرمز الحالة تصنيف رد الخادم، لكنه لا يحمل تفاصيل المعاملة. لا يذكر تعريف 402 المبلغ أو العملة أو المستفيد أو إثبات الدفع أو تأكيده أو تسويته أو طريقة الاعتراض عليه. يستطيع الخادم شرح شروطه في متن الرد؛ أما HTTP فلا يجعل تلك الشروط قابلة لإعادة الاستخدام بين الخدمات والعملاء.

401 يرسل تحدياً؛ أما 402 فينتظر دوره

يوضح الرمز المجاور 401 شكل التفاعل المشترك. يفرض RFC 9110 أن يتضمن رد 401 الحقل WWW-Authenticate مع تحدٍّ واحد على الأقل ينطبق على المورد. يستطيع العميل قراءة الآلية وتحديد بيانات الاعتماد المطلوبة. لا يقدم القسم 15.5.3 توجيهاً مماثلاً للرمز 402؛ بل يكرر حجزه للمستقبل. RFC 9110 §§15.5.2–15.5.3

يقع العمل الناقص على التطبيق. إذا جعلت خدمةٌ الوصولَ مشروطاً بالدفع، فعليها تحديد المستحقات، وكيف يثبت المشتري الدفع، ومن يتلقى المال، وما الذي يحدث عند رفض الإثبات أو تعثر التسوية. يضع HTTP علامة الرفض؛ أما نقطة التحصيل والإيصال ومسار الخطأ فتتولاها الخدمة.

المستقبل تمدد من إصدار إلى آخر

كرر RFC 2616 الجملة نفسها في القسم 10.4.3 في يونيو 1999. فعل RFC 7231 ذلك في 2014، ثم عاد RFC 9110 إليها في 2022. تغير رقم القسم وبقي الحجز. حدّثت كل نسخة معنى HTTP وأبقت خانة الدفع فارغة في الإصدار التالي. RFC 2616 §10.4.3 · RFC 7231 §6.5.2

لا تسمي وثائق RFC نظام الدفع الذي توقعه مؤلفوها. يمكن لسجل تصميم معاصر يحدد ذلك النظام أن يغير تفسير هذه القصة. تكشف المواصفات المنشورة اسم الرمز وقرار حجزه، ولا تروي أصل الخانة الفارغة.

تسجل صفحة سجل IANA التي روجعت لهذا المقال، والمحدّثة في 15 سبتمبر 2025، الرمز 402 بوصفه «Payment Required» وتحيل إلى RFC 9110، القسم 15.5.3. سجل رموز حالة HTTP لدى IANA

فاتورة التكامل تعود إلى المطورين

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

402 اسم لحالة، وليس واجهة دفع. يخبر العميل بأن الخادم ربط الوصول بالدفع، ولا يمنحه طريقة مشتركة لاستيفاء الشرط. تظل نقطة التحصيل في HTTP قاعدة محلية تحمل رقماً معيارياً.

المصادر

• RFC 1945 — HTTP/1.0
• RFC 2068 — HTTP/1.1
• RFC 2616 — HTTP/1.1
• RFC 7231 — دلالات HTTP/1.1 ومحتواه
• RFC 9110 — دلالات HTTP
• IANA HTTP Status Code Registry