متحقق يستأنف تنزيل ملف دون خلط نسختين: مشاريع تخرج تطوير الويب

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

حدد حالة المورد قبل إرسال الطلب

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

اصنع موارد مرجعية قابلة للفحص

أنشئ ثلاثة ملفات ثابتة ذات بايتات مختلفة مع حجم معروف وبصمة SHA-256 محسوبة محلياً. يعمل خادم الاختبار على مجلد منفصل ولا يقرأ ملفات المستخدم. أضف نقطة تحكم توقف الاستجابة بعد عدد محدد من البايتات، ونقطة أخرى تبدل نسخة الملف بين طلبين. خزّن بيانات المورد مثل ETag وLast-Modified بجانب fixture. اكتب القيم في التقرير حتى يعرف الفريق لماذا كان الاستئناف صحيحاً أو لماذا وجب إسقاط الجزء. هذه منصة اختبار للبروتوكول، ولا ينبغي أن تصبح مكتبة تنزيل إنتاجية دون مراجعة أوسع.

حالة من 0 إلى 999 بايت

لنفترض أن التمثيل الأول طوله 1000 بايت، وتوقف الاتصال بعد البايت 399، أي أن العميل يملك 400 بايت تبدأ بالفهرس صفر. يطلب المتبقي باستخدام Range: bytes=400- وIf-Range بالقيمة القوية المسجلة. إذا جاء رد 206 مع Content-Range يبدأ من 400 ويتوافق إجماله وETag مع ما سبق، يمكن إلحاق الجسم بعد التحقق من طول الجزء النهائي والبصمة. هذه أرقام توضيحية. إذا عدل الخادم الملف وأصبح طوله 1100 وبـETag جديد، فالرد الكامل 200 يعني التخلص من الجزء المحلي وكتابة نسخة جديدة، لا إلحاق كامل الجسم بعد أول 400 بايت.

اجعل القرار مرئياً في انتقالات حالات

حالات العميل المقترحة: لا يوجد ملف، تنزيل جار، جزء متوقف، طلب استئناف، قبول 206، استبدال كامل عبر 200، استجابة غير صالحة، واكتمال بعد تحقق البصمة. لا تقبل جزءاً إذا كان Content-Range لا يبدأ في الموضع المتوقع أو إذا لم يطابق الحجم المتوقع مجموع المدى. استجب إلى 416 بتسجيل مدى غير صالح ومراجعة حجم النسخة المحلية؛ لا تفترض أن كل خادم يدعم نفس سياسة الحدود. وضح أن خادم الاختبار نفسه يجب أن يطبق Range على النحو الذي تعرفه المواصفة.

مصفوفة اختبار قبل العرض

غط انقطاعاً ثم 206 صحيحاً، وغيّر المحتوى قبل الاستئناف، وأعد الملف نفسه مع ETag متغير، واختبر ETag ضعيفاً، ومدى يبدأ في موضع خاطئ، و206 بطول جسم غير متوقع، و200 كامل بعد طلب Range، و416. في كل حالة قارن البصمة النهائية بالملف المرجعي. معيار النجاح هو تطابق البايتات والبصمة، لا مجرد ظهور «اكتمل التنزيل». أضف إيقاف التطبيق بعد حفظ الجزء ثم استعادته بعد تشغيل جديد؛ يجب ألا يفقد العميل موضعه أو يخلط ملفاً قديماً بجديد. هذه حالات بروتوكول مضبوطة، وليست ادعاء أن كل جهاز شبكة ينتجها.

ما الذي لا يثبته المختبر؟

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

احفظ metadata الخاصة بالجزء في ملف جانبي يكتب بشكل ذري؛ إن أغلق التطبيق فجأة أثناء تحديث المؤشر، يجب ألا يوحي الملف أنه يحتوي bytes أكثر مما كتب فعلياً. شغّل المحاكي مع إيقاف قسري بعد نقاط مختارة ثم أعد التشغيل، وتحقق من طول الملف وبصمته قبل محاولة الاستئناف. إذا لم توجد ETag قوية، صمم سلوكاً محافظاً مثل إعادة الطلب الكامل أو اعتماد تحقق آخر موثق، ولا تخترع ضماناً من تاريخ تعديل ضعيف. يختبر هذا الجانب سلامة العميل عند الانقطاع بين كتابة البيانات وحفظ الحالة، لا دلالة HTTP وحدها. سجل الخطوات والأحجام ليتمكن المشرف من تكرار التعطل.