الخلاصة

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

نجاحان يخفيان عملاً ضائعاً

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

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

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

في أبريل 2012 عرّف RFC 6585 الرمز 428 Precondition Required. معناه أن خادم الأصل يشترط أن يكون الطلب مشروطاً. ويذكر النص استخداماً نموذجياً: يقرأ العميل حالة، يعدلها، ثم يعيدها بعدما غيرها طرف ثالث في الأثناء.

من الحذر إلى بوابة قبول

إذا حصل العميل عند القراءة على ETag قوي مثل "v7"، فإن If-Match: "v7" عند الكتابة يحول ذاكرته إلى ادعاء قابل للاختبار. لا ينفذ الأصل الطريقة إلا إذا ظل التمثيل المحدد يحمل الوسم نفسه. إذا أنشأت كتابة أخرى "v8" صار الشرط كاذباً، ولا يجوز تنفيذ التغيير.

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

لا يجعل المثال حقلاً واحداً إلزامياً لكل عملية. يقرر If-Match: * أن تمثيلاً حالياً يجب أن يوجد. ويقرر If-None-Match: * أنه يجب ألا يوجد، فيحمي الإنشاء من إنشاء متزامن. وعند غياب ETag يمكن استعمال If-Unmodified-Since كشرط زمني. على المورد أن يبين نوع الدليل المقبول.

إذن كان التغيير التاريخي في توزيع السلطة: من يملك الحالة الراهنة يستطيع أن يطلب من الكاتب الكشف عن الماضي الذي بنى عليه نيته.

غياب الشرط ليس فشل الشرط

يجيب 428 Precondition Required عن سؤال القبول. تتطلب السياسة شرطاً، لكن الطلب لم يقدم شرطاً مقبولاً، لذلك لا تبدأ الطريقة ذات الأثر.

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

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

ليس 428 نوعاً من 409 أيضاً. يستطيع 409 وصف تعارض دلالي مع حالة المورد. أما 428 فيطلب الدليل قبل محاولة كتابة قد تخفي التعارض. وهو ليس 423 الخاص بـWebDAV؛ فلا يقرر وجود قفل ولا ينشئ واحداً.

لماذا يحتاج If-Match إلى مقارنة قوية

يفرض RFC 9110، وهو مرجع دلالات HTTP الحالي، المقارنة القوية لـIf-Match. قد يكفي الوسم الضعيف ليقول إن تمثيلين متكافئان بما يسمح بإعادة استخدام ذاكرة مخبأة. أما الكاتب فيريد وقف الطريقة متى تغيرت بيانات التمثيل.

لذلك يصبح توليد الوسم جزءاً من عقد الواجهة. إذا تغيرت الحالة المحمية ولم يتغير الوسم مرت كتابة قديمة. وإذا تغير الوسم بسبب ترتيب تسلسلي غير مهم ظهرت تعارضات كاذبة. خدمة تفرض If-Match ولا تصدر ETag قوياً صالحاً تجعل 428 طريقاً مسدوداً.

الزمن أقل دقة. يستطيع If-Unmodified-Since أداء غرض مشابه عند غياب الوسم، لكن RFC 9110 يعد If-Match بديلاً أدق ويتجاهل شرط التاريخ عند وجود الاثنين. دقة الساعة وطريقة إنشاء الطابع تحدان قوة هذا الدليل.

يجب أن تلامس المقارنة لحظة الالتزام

يضع HTTP تقييم الشروط في الأصل بعد الفحوص العادية ومباشرة قبل فعل الطريقة. لا يملك الوسيط الحقيقة الحالية لدى الأصل، لذلك لا يجوز أن يقرر صحة If-Match من نفسه؛ بل يمرر الطلب.

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

الحل مقارنة وفعل ذريان: عمود نسخة، أو compare-and-swap، أو معاملة مكافئة. يحدد HTTP الوعد المرئي على السلك، ولا يخلق عزل قاعدة البيانات.

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

الرفض لا يقوم بالمصالحة

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

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

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

رفض لا يجوز تخزينه

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

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

ما زال سجل IANA يسجل 428 باسم Precondition Required ويحيله إلى RFC 6585. تختصر العبارة قاعدة عميقة: قبل استبدال الحاضر، على الكتابة أن تكشف الماضي الذي يمنحها أساسها.

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

المصادر هي RFC 6585 وRFC 9110 وسجل IANA. تثبت الدلالات وترتيب التقييم والقيود، ولا تقيس الانتشار الحالي أو الخسائر أو دعم كل المكتبات أو حادثة محددة. ليس 428 قفلاً ولا دمجاً ولا معاملة ولا ضمان تنفيذ مرة واحدة.