Summary

  • تقول مسودة Byte Range PATCH، النسخة 05 إن خادماً لا يدعم PUT الجزئي قد يتجاهل Content-Range ويستبدل المورد بأكمله بالجزء المرسل.
  • يجعل نوع message/byterange نطاق الكتابة جزءاً من مستند PATCH. إذا لم يُعرف موضع النطاق، يجب على الخادم الرفض برمز 400 أو 422.
  • يجب أن يطابق طول الجزء المعلن طول نطاقه تماماً. وإذا سُمح بملفات ذات فجوات، فلا يجوز كشف محتوى غير مهيأ.

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

في القسم الثاني، تحدد المسودة موضع الخطر: وضع Content-Range مع PUT يحتاج إلى دعم خاص في الخادم. عندما يغيب هذا الدعم، قد يُتجاهل الحقل وتُطبّق قاعدة PUT المعتادة باستبدال المورد. العميل وصف مكان التعديل بدقة، لكن الوصف لم يمنحه سلطة فرض العملية على المستقبل. الملف يدفع ثمن اختلاف تفسيرين صامتين.

تقترح المسودة PATCH مع نوع محتوى يحمل معنى الكتابة في موضع محدد. message/byterange يصف نطاقاً واحداً؛ multipart/byteranges يحمل عدة نطاقات؛ وهناك شكل ثنائي مقترح هو application/byteranges. يقبل الخادم النوع فيعرف أن الجسم تعليمات تعديل جزئي، أو يرفض نوعاً لا يفهمه قبل تغيير الملف. الرفض هنا معلومة نافعة، أما النجاح الذي يمحو المورد فيترك للمالك مهمة اكتشاف الضرر.

الموضع جزء من الأمر

كل جزء من التصحيح يحدد نطاقاً متصلاً واحداً. غياب موضع معروف يستوجب 400 أو 422. وإذا احتوى الجزء على Content-Length، فيجب أن يساوي طول النطاق المحدد. لا يحق للخادم أن يخمن أين يضع البايت الإضافي أو أي بايت يتجاهله. وللتدفق الذي لا يُعرف طوله النهائي، يقدم Content-Offset نقطة البداية. يبقى آخر الملف مجهولاً، لكن بداية الكتابة يجب أن تكون معروفة.

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

يعالج القسم الرابع مصير الطلب المنقطع عبر Prefer: transaction=atomic أو transaction=persist. الأول يطلب الالتزام عند النجاح، والثاني يفضل حفظ ما وصل قبل الانقطاع. ينبغي أن يذكر الخادم التفضيل الذي طبقه في Preference-Applied. هذا خيار يخص الاحتفاظ بالحالة، بعد تحديد ما إذا كانت البايتات جزءاً داخل الملف أم نسخة تحل محله.

تتيح RFC 5789 الإعلان عن أنواع PATCH المدعومة باستخدام Accept-Patch. ما ينقص هو تجربة منشورة ترسل PUT بنطاق وPATCH من نوع message/byterange إلى خوادم مختلفة، وتحتفظ بالبايتات قبل وبعد، ورمز الاستجابة وETag. ستكشف التجربة كيف تُفسر الأنظمة الفعلية هذا الحد.

المسودة وحالتها · RFC 5789 · RFC 9110