قُبل طلب الحذف ثم رفضته شبكة CDN في المصب

الخلاصة

• يثبت 201 Created أن شبكة CDN أنشأت مورد تشغيل، ولا يثبت أن الحذف أو الإبطال أو التموضع المسبق اكتمل.
• إذا سبق لشبكة عبور أن قبلت الطلب، فعليها تحويل رفض HTTP المتزامن من شبكة أبعد إلى Error.v2 غير متزامن داخل مورد حالتها. ذكر PID للشبكة الرافضة اختياري.
• ينبغي فصل دليل القبول والتنفيذ ومصدر الخطأ والعدادات والمصالحة بعد عودة العقدة ونتيجة المستخدم.

أين اختفى اسم الرافض؟

ترسل شبكة A إلى B طلباً لحذف محتوى. تصادق B الطلب وتنشئ مورداً وترد بـ201 Created. ثم تمرره إلى C. ترى C عنصراً غير مدعوم فترد على B بـ400 Bad Request.

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

تعالج المراجعة 20 من CDNI Control Interface / Triggers 2nd Edition، المنشورة في 2 سبتمبر 2026، هذه الفجوة. تعرض صفحة Datatracker الوثيقة كمسودة إنترنت نشطة لمجموعة CDNI وفي حالة WG Document. ستستبدل RFC 8007 إذا اعتُمدت، لكنها ليست RFC الآن ولا موافقة IESG ولا دليلاً على تطبيق أي مزود.

مقارنة بـالمراجعة 19، أضافت النسخة الجديدة معالجة موسعة للأخطاء وانتقالها في السلاسل. الخبر ليس مجرد دعم أمر purge، بل كيفية حفظ رفض يصل بعد قبول سابق.

الرفض يبدل نوع سجله

إذا اكتشفت B قبل الإنشاء أن الطلب مشوه أو غير مصرح أو يتضمن فعلاً لا تدعمه، تعيد 4xx ولا تنشئ مورداً. أما بعد ردها على A، فقد انتهت معاملة الإنشاء بينهما. لا يمكن لرد 4xx أو 5xx اللاحق من C أن يحل محل جواب مضى.

لذلك تفرض المراجعة 20 على B أن تحول رفض C إلى Error.v2 Description داخل مورد التشغيل الذي تملكه. ويصعد الفشل غير المتزامن من C بالطريقة نفسها. تعرف A النتيجة عند الاستعلام لاحقاً، فتجد مثلاً الحالة failed والرمز eunsupported.

كان الدليل عند C رفضاً مباشراً. وعند A صار رواية من B عن رفض C. حفظ 201 وحده يمحو الفشل؛ وحفظ الخطأ الأخير من دون مسار التحويل يمحو سلسلة المصدر.

ثم تأتي حدود الإفصاح. يجوز لـB تضمين CDN Provider ID الخاص بـC، لكنه ليس ملزماً؛ ويمكنه استخدام PID الخاص به وإخفاء موضع الخطأ الحقيقي. توفر سجلات IANA لمعاملات CDNI مفردات مشتركة، ولا تفرض كشف السلسلة التجارية.

الاكتمال يخص رسماً بيانياً

يبدأ المورد عادة بـpending ثم active وينتهي بـcomplete أو failed. لا يجوز لشبكة العبور إعلان complete حتى يكتمل العمل لديها ولدى جميع شبكات المصب. وإذا أعلنت هي أو إحدى الشبكات processed فعليها نقل الحالة نفسها إلى المنبع.

تعني processed أن الطلب قُبل لكن تحديثات الحالة اللاحقة لن تتوافر. إنها حد للرؤية، لا نجاح مقنع. توصي المسودة بمعرفات فريدة وفق RFC 9562 وعدم إعادة استخدام URI بعد الحذف. يثبت المعرف استمرارية المورد، لا صحة أثره.

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

العداد يقبل التكرار عمداً

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

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

الإلغاء سباق وليس ممحاة

تنفيذ الإلغاء اختياري. قد تقبل B الإلغاء بعد أن انتقلت المهمة التي رأتها A pending إلى active. وقد يكتمل عمل active أو processed قبل توقفه. تدل cancelling على عملية إيقاف جارية، ولا تثبت توقف الأثر فوراً.

حذف المورد يزيل سجل الحالة ويجعل الطلبات اللاحقة تعود بـ404 Not Found. لذلك تفضل المسودة الإلغاء عندما يحتاج المنبع إلى مراجعة الحالة النهائية. يثبت 204 No Content حذف مورد المتابعة، لا عكس ما نفذته الشبكات.

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

ترجع البنية إلى بيان المشكلة في RFC 6707، وإطار الواجهات في RFC 7336، ومتطلبات التحكم في RFC 7337. وتحدد RFC 9110 دلالات HTTP. لكن نجاح عملية HTTP لا يملك سلطة الإثبات على كل عمل موزع جاء بعدها.

العقدة الغائبة قد تعيد الحالة القديمة

تعد المسودة الغياب المؤقت لعقدة في dCDN حالة تشغيلية داخلية لا ينبغي وحدها أن تغير الحالة المنشورة. وقبل عودة العقدة إلى الخدمة العادية، ينبغي جعلها متوافقة مع عمليات التشغيل السابقة.

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

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

تحسن الواجهة دفتر الأدلة، لكنها لا تجعل صفحة واحدة هي الواقع كله.