الخلاصة

  • تقترح مسودة نشطة في مجموعة HTTP الرمز 419 Purpose Declined عندما يرفض الخادم طلباً بسبب Sec-Purpose المعلن. إنه إيصال يخص ذلك الطلب، لا حظراً دائماً ولا حكماً على صحة الخادم ولا صلاحية رفض جديدة. وفي 29 سبتمبر 2026 ظل سجل IANA يعد 419–420 غير مخصصين.
  • لا تكفي إضافة الرقم. يجب أن تبقى صلة بين الغرض، وصاحب القرار المفوض، وسياسة عدم التخزين، وسلوك العميل، ومجموعة SLO، والطلب الحقيقي اللاحق. وإلا اختزلت الأدوات 419 إلى 4xx عام وبقيت لوحة المراقبة تروي القصة الخطأ.

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

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

لكن استخدام 503 Service Unavailable يطمس هذا الفرق. فئة 5xx في RFC 9110 تعني أن الخادم أخفق في تنفيذ طلب يبدو صالحاً. من الطبيعي أن يفتش فريق المناوبة عن ضغط أو اعتماد معطل عند ارتفاع 503. الخطأ هو وضع رفض اختياري للعمل التخمني في العداد نفسه.

تقترح draft-ietf-httpbis-pre-denied-01 المؤرخة 9 سبتمبر 2026 الرمز 419: رفض الخادم هذا الطلب بسبب الغرض المعلن. الوثيقة Internet-Draft نشطة لمجموعة HTTP ووجهتها المقصودة Standards Track، وليست RFC. وعند تثبيت الأدلة كان 419–420 بلا تخصيص من IANA.

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

الغرض المعلن سياق، لا دليل على الطلب

يعرف معيار Fetch رأس Sec-Purpose للأغراض التي لا تمثل استخداماً فورياً من المستخدم. والرمز الوحيد المعرف هو prefetch: جلب مورد يتوقع العميل حاجته قريباً. وعندما يكون initiator هو الجلب المسبق يضع المسار Sec-Purpose: prefetch.

يمكن للخادم تغيير مدة التخزين، أو منع الجلب، أو عدم احتسابه زيارة. لكن الرأس لا يثبت أن المستخدم سيتنقل، ولا جودة التوقع، ولا الهوية، ولا تحقق منفعة.

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

الرمز الملتبس يحرك فرقاً وميزانيات في الاتجاه الخطأ

حين يدخل الرفض المقصود في 503، يحقق SRE في نطاق فشل غير موجود، ويستهلك error budget، ويقدم تقرير عميل لا يقيس الالتزام الحقيقي. وقد تضيف المؤسسة سعة كي تخفض منحنى سببه أصلاً اقتصاد واعٍ في العمل.

ولا يحل 403 Forbidden المشكلة، لأنه يوحي بمنع المورد عموماً. قد ينجح الطلب الفوري بعد ثوان، وقد يقبل الجلب المسبق التالي. 419 المقترح يقول شيئاً أضيق: رُفض هذا الطلب بسبب غرضه.

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

ينتهي الرفض بانتهاء الطلب

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

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

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

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

من يرسل 419 يحتاج إلى تفويض

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

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

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

يفهم العميل القديم الفئة وقد يفقد السبب

يلزم RFC 9110 العميل بمعالجة 4xx غير المعروف مثل 400 عموماً. يمنع ذلك اعتبار 419 نجاحاً، لكنه لا يحفظ معنى Purpose Declined. قد يحوله SDK إلى bad request، أو تجمعه المنصة تحت other_4xx، أو تضعه اللوحة باللون الأحمر.

تقتضي أولوية الشيفرة العاملة فحص العميل والحافة والأصل والذاكرة والتتبع والمقاييس والتنبيه وSLO والتقرير. لا تعيد أي عملية تسجيل مستقبلية برمجة تلك المكونات تلقائياً.

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

ربط الإيصال بالواقع اللاحق

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

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

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

تثبت المصادر نص الاقتراح وحالته ومعنى Fetch وقواعد HTTP وبقاء الرقم غير مخصص. ولا تثبت متصفحاً أو CDN أو نشرًا أو وفراً أو تبنياً. تلك مسائل تطبيق وقياس.

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

المصادر