الخلاصة

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

كان الموضع صحيحاً وقد تكون النسخة خاطئة

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

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

قدمت RFC 2068 الحقل If-Range عام 1997 ضمن أول مواصفة معيارية لـ HTTP/1.1. أوضحت أن طلب نطاق مع شرط عادي قد يفشل إذا تغير الكيان، فيضطر العميل بعد ذلك إلى طلب ثانٍ للحصول على الجسم الحالي كاملاً. اختصر الحقل الجديد الخطوتين: إذا لم يتغير الكيان فأرسل الأجزاء الناقصة، وإلا فأرسل الكيان الجديد كله.

أبقت RFC 2616 عام 1999 هذا الانقسام. تطابق وسم الكيان يقود إلى الجزء المحدد باستجابة 206 Partial Content، وعدم التطابق يقود إلى الكيان الكامل باستجابة 200 OK. الشرط الكاذب لا يرفض القراءة؛ بل يسحب فقط ميزة استكمال النسخة القديمة.

قبل طلب واحد نتيجتين مفيدتين

يمكن للعميل أن يرسل:

Range: bytes=4000000-
If-Range: "release-18"

لا يقول الطلب إن الجزء هو النتيجة المقبولة الوحيدة. يقول إن الجزء مقبول فقط إذا ظل "release-18" مُحقِّقاً قوياً للتمثيل المختار حالياً. عند الاختلاف، يتجاهل الخادم Range ويعيد الجسم الكامل المعتاد. وعلى العميل أن يستبدل نسخته الجزئية بجسم 200، لا أن يضيف الجسم الكامل إليها.

لهذا لا يعمل If-Range مثل الشروط الأخرى. يمكن أن يمنع If-Match العملية ويؤدي إلى 412 Precondition Failed. ويمكن أن يجعل If-None-Match طلب GET ينتهي بـ 304 Not Modified. أما If-Range فيقرر شكل البيانات: جزء اقتصادي إذا استمرت النسخة، أو نسخة حالية كاملة إذا انقطعت الاستمرارية.

فصلت RFC 7233 طلبات النطاق عام 2014 وحددت الحدود. لا يجوز للعميل إنشاء If-Range من دون Range، ويتجاهله الخادم إذا غاب النطاق أو لم يدعم المورد العملية. عند تطابق المُحقِّق ينبغي معالجة النطاق، وعند عدم التطابق يجب تجاهله. يوفر الحقل جولة إضافية، لكنه لا يجبر خادماً على دعم أجزاء لا يقدمها.

تحتفظ RFC 9110 بالمعنى الحالي وترتيب التقييم. في GET يحوي الحقلين، يؤدي شرط صحيح ونطاق قابل للتطبيق إلى 206؛ وإلا يُهمل Range وتكون الاستجابة 200. تظل الأخطاء والتحويلات والفحوص التي تسبق الشرط ذات أولوية. لا يمنح المُحقِّق سلطة على بقية دلالات الطلب.

تركيب البايتات احتاج مساواة قوية

يفرق HTTP بين المُحقِّق القوي والضعيف لأن التشابه الدلالي لا يساوي التطابق بايتاً ببايت. قد يكون تغيّر الفراغات أو التسلسل غير مهم عند إعادة استخدام صفحة مخزنة. لكنه مهم تماماً عندما سيوضع جزء جديد خلف جزء محفوظ؛ تغيير مبكر واحد قد يزيح كل المواضع اللاحقة.

توضح RFC 7232 أن المُحقِّق القوي يتغير عندما تتغير بيانات التمثيل القابلة للملاحظة، ولذلك يصلح للنطاقات الجزئية. أما الضعيف فيصلح حين لا تكون المساواة الدقيقة مطلوبة. لهذا لا يجوز وضع ETag ضعيف في If-Range. ولا يجوز استخدام تاريخ Last-Modified إلا عندما لا يملك العميل وسم كيان ويكون التاريخ قوياً بالمعنى المحدد.

تكشف التواريخ سبب الحذر. قد تكون دقة الساعة أبطأ من وتيرة تحديث المورد، فتتقاسم نسختان ثانية واحدة. يقارن If-Range التاريخ تماماً بقيمة Last-Modified، ولا يستخدم علاقة «أقدم أو مساوٍ» الخاصة بـ If-Unmodified-Since. إذا لم يكن الزمن دليلاً قوياً، فالنتيجة الآمنة هي إغلاق المسار الجزئي.

ولا يعني ETag القوي أنه تجزئة تشفيرية. قيمته معتمة للعميل. القوة تعني التزام المصدر بألا يعيد القيمة نفسها لبيانات تمثيل مختلفة قابلة للملاحظة ضمن هذا المورد والنطاق الزمني ذي الصلة. لا يصادق على الناشر، ولا يثبت صحة الملف، ولا يثبت أن القيمة نفسها عند عنوان URL آخر تعني محتوى متساوياً. نفت RFC 2616 هذا الاستنتاج بين عناوين URI المختلفة.

التطابق لم يكن وعداً باستجابة 206

بعد نجاح المقارنة، ما زال الخادم يفحص وحدة النطاق وصيغته وطول التمثيل الحالي وإمكان تلبية المواضع المطلوبة. نطاق مدعوم وصحيح وقابل للتلبية ينتج عادة 206 Partial Content. يحمل الجزء الواحد Content-Range لتحديد موضعه؛ وتستخدم الأجزاء المتعددة multipart/byteranges. إذا لم يتقاطع أي نطاق مع الامتداد الحالي، فقد تكون النتيجة 416 Range Not Satisfiable.

يحدد Content-Range موضع الجسم الذي وصل، لكنه لا يثبت نسخة البايتات القديمة. يقوم المُحقِّق القوي المشترك بهذا الدور المحدود. وحتى التطابق لا يثبت أن العميل استلم كل الأجزاء أو كتبها بالترتيب أو احتفظ بها.

الخطر في الاتجاهين غير متساوٍ. عدم تطابق زائد يعيد إرسال الملف كاملاً؛ تكلفته واضحة لكنه يعطي نسخة متماسكة. تطابق كاذب قد يصنع بهدوء ملفاً هجيناً. فضل التصميم إعادة نقل مرئية على استمرارية موهومة.

تحولت الذاكرة الوسيطة إلى حارس للأجزاء

يمكن للذاكرة الوسيطة حفظ استجابة 200 غير مكتملة أو 206 أو نطاقات متفرقة. عندما تدمجها، تصبح مسؤولة عن نسبها. تسمح RFC 7234 بحفظ المحتوى غير المكتمل فقط لذاكرة تفهم Range وContent-Range، ولا تسمح بدمج النطاقات إلا إذا اشتركت كلها في المُحقِّق القوي نفسه.

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

تحافظ RFC 9111 الحالية على الفصل. تستطيع الذاكرة إكمال استجابة بطلب نطاق لاحق، لكنها لا تعيد استخدامها كجسم كامل قبل اكتمالها فعلياً. ويجب وسم الرد الجزئي بـ 206. لا يخزن If-Range البيانات ولا يركبها؛ إنه يقدم دليلاً لفرع واحد في استجابة الخادم.

لذلك يحتاج التدقيق إلى حفظ هدف الطلب ومدخلات التفاوض وRange والمُحقِّق السابق والحالي وطريقة المقارنة والحالة وContent-Range وبصمة الجسم النهائي كلٌ على حدة. يعرف الخادم ما أرسله. ويعرف العميل أو الذاكرة ما استلمه وركبه. لا يثبت سجل واحد السلسلة كاملة.

استمرارية بلا سجل عالمي للنسخ

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

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

تحدد وثائق RFC العقد، ولا تثبت تنفيذ منتج حالي. لا تستطيع إثبات قوة ETag فعلي، أو حفظ وسيط له، أو دعم خادم للنطاق، أو تخزين الملف المكتمل. تحتاج تلك الادعاءات إلى التقاط الطلبات والاستجابات ومدخلات اختيار التمثيل وتاريخ المُحقِّقات وبصمات الأجزاء وسجل التركيب.