الخلاصة

  • نشر HTTPbis في 9 سبتمبر 2026 المراجعة 01 من draft-ietf-httpbis-pre-denied. وهي مسودة نشطة لفريق العمل، وليست RFC ولا دليلاً على تخصيص IANA للرقم 419.
  • استبدلت المراجعة عبارة “Preliminary Request Denied” باسم Purpose Declined، واقترحت 419، ووسعت النطاق إلى رفض مبني على Sec-Purpose المعلن. ولا يعرّف Fetch حالياً سوى القيمة prefetch.
  • يجوز للأصل أو لبوابة تتصرف نيابة عنه توليد الرد، بينما ينبغي للوكيل المستقل ألا يفعل ذلك. الحد هنا هو حق تمثيل سياسة الخدمة، لا القدرة التقنية على إنشاء استجابة.
  • لا يحدد الرمز القاعدة التي أدت إلى الرفض. أقترح سجلاً موجزاً يربط الغرض وصاحب القرار والتفويض وإصدار السياسة والتوقيت والتخزين المؤقت والنتيجة. هذا اقتراح تحريري من Daniel Kade، لا شرطاً في المسودة.

العبارة الحاسمة ليست الرقم بل «نيابة عن الأصل»

أصبح الإصدار 01 من The Purpose Declined HTTP Status Code متاحاً عند الساعة 08:56 بالتوقيت العالمي في 9 سبتمبر. كان الإصدار 00 يترك الرقم بصيغة 4xx عامة ويتحدث عن رفض طلب «تمهيدي»، مع تركيز على prefetch وpreload. أما النص الجديد فيقترح 419 ويغطي الطلب الذي يُرفض بسبب الغرض الذي صرح به.

للمسودة موضع فعلي في العملية: وثيقة نشطة لفريق HTTPbis، ضمن IETF stream، وحالتها المقصودة Proposed Standard، ويتولى Tommy Pauly دور document shepherd. لكن حالة IESG ما زالت I-D Exists، من دون Area Director مسؤول أو معالجة في IESG أو telechat. ويسجل جدول IANA الحي النطاق 419-420 على أنه غير مخصص. لذلك فالرقم قرار عمل قيد الاختبار، لا معياراً مكتمل الاعتماد.

تضيف المراجعة تمييزاً مؤسسياً واضحاً. يستطيع خادم الأصل إصدار الرد. ويستطيع CDN أو reverse proxy إصداره عندما يعمل بوابةً نيابة عن ذلك الأصل. أما الوكيل المستقل فينبغي ألا يصدره. لا تقول هذه القاعدة إن الوكيل عاجز عن تركيب 4xx؛ بل تقول إنه لا يملك أن يعرض خياره الخاص بوصفه سياسة الأصل.

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

Sec-Purpose يحمل تصريحاً لا برهاناً على القصد

يمنح Fetch Standard ترويسة Sec-Purpose مهمة محدودة: الإشارة إلى أن الطلب يخدم غرضاً غير الاستخدام الفوري. وهي ترويسة منظمة، والقيمة الوحيدة المعرفة وقت النشر هي prefetch. قد يستعمل الخادم هذا التصريح لتعديل مدة التخزين أو منع الجلب المسبق أو احتساب الزيارة بطريقة مختلفة.

يسمح اسم “Purpose Declined” بقيم محتملة مستقبلاً، لكنه لا ينشئ تلك القيم. كما أنه لا يمنح الخادم قدرة جديدة؛ فالرفض ممكن أصلاً. ما تضيفه المسودة، وفق وصفها، هو جعل السلوك أكثر وضوحاً للعميل والمشغل.

هذا الوضوح ليس توثيقاً للنية. تخبر Sec-Purpose: prefetch بما أعلنه العميل عن الطلب، ولا تثبت رغبة المستخدم أو موافقته على تحميل خلفي، ولا تحدد المكوّن البرمجي الذي بدأ الاتصال. وقد يكون التصريح غير دقيق. وفي الجهة المقابلة لا يكشف 419 إن كانت السياسة ترفض كل prefetch، أو تعمل فقط عند ارتفاع الحمل أو الكلفة أو في منطقة معينة أو عند إشارة إساءة.

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

يجب أن يبقى تفويض البوابة قابلاً للإثبات

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

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

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

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

منع التخزين يحد مدة القرار

تطلب المراجعة 01 محتوى بطول صفر وتوصي بالتخلص من أي محتوى يصل فعلاً. كما تنص على أن 419 غير قابل للتخزين heuristically وينبغي ألا يُخزن. بذلك لا يتحول رفض محلي إلى قاعدة ممتدة من دون قرار جديد.

يحفظ RFC 9110 مسار التوافق: العميل الذي لا يعرف 419 يعامله كعضو x00 من فئته، أي خطأ 4xx عاماً. ويضع RFC 9111 الإطار العام للتخزين. أما التوجيه الأشد في المسودة فيمنع إعادة استعمال رفض اتُخذ في لحظة حمل أو وفق إصدار سياسة معين بعد تغير الظروف.

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

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

المصادر