الخلاصة

  • يقترح draft-ietf-httpbis-pre-denied-01 الرمز 419 عندما يرفض الخادم الطلب المرتبط استناداً إلى الغرض المعلن في Sec-Purpose، ويقصر الدلالة على ذلك الطلب وحده.
  • لا يفترض عرض هذه الاستجابة للمستخدم؛ ينبغي أن يكون متنها صفري الطول، وأي متن يصل ينبغي تجاهله. النص الحر لا يثبت حمولةً زائدة أو حظراً دائماً أو موعداً مضموناً للمحاولة التالية.

وصلت الاستجابة برمز مقترح 419، لكن صفحة HTML المرفقة قالت: «الخدمة ممتلئة، حاول لاحقاً». قرأ العميل الجملة، انتظر دقيقة، ثم أطلق كل العمل المؤجل. لم يكن المشروع قد عرّف هذه الجملة، ولم يكن الخادم قد وعد بسعة جديدة بعد دقيقة.

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

نُشرت المراجعة 01 من The Purpose Declined HTTP Status Code في 9 سبتمبر 2026 بوصفها Internet-Draft نشطة ضمن مجموعة HTTP في IETF، وتنتهي في 13 مارس 2027. المقصود أن تسلك مسار المعايير، لكنها وثيقة عمل قابلة للتغيير أو الاستبدال أو الانتهاء. عند تجميد المصادر لم يكن 419 مخصصاً في سجل IANA. لذلك لا تمثل الوثيقة RFC أو تخصيصاً نهائياً أو دليلاً على الانتشار والتشغيل البيني.

المعنى الضيق أفضل من الشرح الواسع

يسمح معيار Fetch لوكيل المستخدم أن يعلن غرض الطلب بواسطة Sec-Purpose. المثال الأساسي هو الجلب الاستباقي، حين يطلب المتصفح تمثيلاً قبل التصفح العادي أملاً في تقليل زمن الانتظار.

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

المقترح 419 يعطي تصنيفاً أدق: رُفض هذا الطلب بسبب غرضه المعلن. وهو لا ينشئ قدرة رفض جديدة. كانت الجهة المستلمة قادرة على الرفض أصلاً؛ الرمز يحسن وصف السبب المقدم.

هذه الدقة لا تسمح بإضافة تفاصيل غير محددة. لا يقول الرمز إن السعة نفدت، ولا إن المستخدم محظور، ولا إن المورد سيظل مرفوضاً، ولا إن محاولة لاحقة ستنجح. كل ادعاء إضافي يحتاج إلى إيصال آخر.

الغرض المعلن ليس هويةً ولا موافقة

يعبر Sec-Purpose عن سياق ألحقه وكيل المستخدم بالطلب. قد يطلق المتصفح جلباً استباقياً بناءً على توقع داخلي من دون نقرة، وقد لا يزور الشخص الرابط أبداً.

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

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

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

من أنشأ الاستجابة جزء من الدليل

يسمح المشروع لخادم الأصل وللبوابة التي تعمل نيابة عنه، مثل CDN أو الوكيل العكسي، بإنشاء الحالة. أما الوكيل الذي لا يعمل لحساب الأصل فلا ينبغي له ذلك.

قد يرفض الطرف الحدّي الطلب قبل وصوله إلى التطبيق. يكون القرار حقيقياً إذا كان مفوضاً، لكنه لا يثبت أن تطبيق الأصل رأى الطلب أو أن الأصل كان متعطلاً. وفي الاتجاه الآخر، وصفه بأنه «ضوضاء وسيط» قد ينكر سلطة مفوضة فعلاً.

تساعد نقطة إنهاء TLS والمسار وVia وProxy-Status ومعرفات الربط وسجلات الطرفين على تحديد موضع القرار. يقدم RFC 9209 تشخيصاً لمعالجة الوسطاء، لكنه لا يجعل الوسيط شاهداً على الحالة الداخلية للأصل.

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

الطلب المرتبط هو حد الزمن

ينص المشروع على أن الدلالة تخص الطلب المرتبط فقط. قد ينجح أو يفشل طلب قادم يحمل الغرض نفسه. لا توجد قاعدة دائمة يمكن استنتاجها من الحدث الواحد.

قد تتغير الحمولة، ويسخن المخزن المؤقت، وتتبدل كلفة التمثيل، أو يُعدل إعداد البوابة. وقد يفشل الطلب التالي بسبب مصادقة أو تفويض لا علاقة لهما بالغرض.

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

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

التخزين المؤقت قد يكرر قراراً واحداً

يقول المشروع إن الحالة ليست قابلة للتخزين الاستدلالي وينبغي ألا تُخزن. إعادة استخدام الرفض تجعل قراراً بشأن طلب واحد يحكم طلباً آخر لم يقيمه الخادم.

يضع RFC 9111 قواعد التخزين العامة، ويمكن لـCache-Status في RFC 9211 أن يبين ما إذا كانت الاستجابة نُقلت أو أعيد استخدامها أو أُعيد التحقق منها. لكنه لا يثبت سبب قرار السياسة، كما أن 419 لا يثبت مسار التخزين.

عند ظهور مئة استجابة متطابقة، يجب السؤال: هل حدثت مئة عملية تقييم، أم أعيد تشغيل نتيجة واحدة؟ العمر والتوجيهات والمفتاح وسجل القرار تحدد معنى العدد.

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

المتن غير الموثوق قد يوسع الادعاء

يوصي المشروع بمحتوى صفري الطول وبإهمال أي محتوى يصل، لأن الاستجابة ليست مخصصة للعرض. هذا يمنع قالب الخطأ من التحول إلى واجهة آلية غير معرفة.

قد تقول الصفحة «أعد المحاولة» من دون زمن، أو «لا توجد صلاحية» من دون أن يكون التفويض سبباً، أو تعرض تفاصيل داخلية لا ينبغي نشرها. لا تمنحها الكلمات سلطة لمجرد أنها جاءت مع حالة مفهومة.

يحذر قسم الأمن أيضاً من تسريب حالة داخلية. إذا تغير إصدار 419 مع سخونة التخزين أو عتبة سعة أو تجربة، يمكن للمراقب الخارجي استنتاج التحولات. تحسين الوضوح للمشغلين يجب أن يرافقه تقليل لما يكشفه التنفيذ.

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

المصادر والحدود

تحتوي الحزمة المجمدة على المراجعة 01 وسجلات Datatracker وصفحة مجموعة HTTP ومعيار Fetch وRFCs الدلالات والتخزين وتشخيص الوسطاء والمخازن ونصوص BCP 14 وسجل IANA. تثبت هذه المصادر المقترح وحالة التسجيل وقت الفحص.

لا تثبت تبنياً أو حادثةً أو منتجاً أو سلوك مزود أو صدوراً نهائياً. المثال الافتتاحي حالة تحليلية لا تقرير تشغيل حقيقي.

المصادر