HTTP Range requests: إزاي الـ pause والـ seek شغالين، وإزاي تكمّل تحميل بأمان

زرار pause في أي download manager، والـ seek في نص فيديو، والتحميل اللي بيكمّل بعد ما النت يقطع: التلاتة شغالين بنفس الفكرة البسيطة في HTTP، وهي الـ Range requests. الـ client بيطلب جزء معيّن من الملف بس، مش الملف كله.

في المقال ده هنمشي على الموضوع خطوة بخطوة من MDN، وبعدين نشوف ليه ده مهم لو عندك CDN قدام الـ backend بتاعك.

1. اتأكد إن السيرفر بيدعم الـ ranges

أسهل طريقة إنك تعمل HEAD request وتبص على الـ headers:

curl -I https://example.com/a.mp4

لو الرد فيه Accept-Ranges بقيمة غير none (غالبًا bytes) يبقى السيرفر بيدعم الـ range requests. لو القيمة none أو الـ header مش موجود أصلًا، يبقى مفيش دعم، والـ client هيضطر ينزّل الملف كله كل مرة.

2. اطلب البايتات اللي محتاجها بس

بعد كده تبعت Range header وتحدد البايتات:

GET /a.mp4 HTTP/1.1
Host: example.com
Range: bytes=0-1023

لو السيرفر بيدعم، الرد بيرجع 206 Partial Content. ساعتها:

• الـ Content-Length بيبقى حجم الجزء اللي رجع بس، مش حجم الملف كله.
• الـ Content-Range بيقولك الجزء ده واقع فين من الملف كله، زي مثال MDN: Content-Range: bytes 0-1023/146515.

ممكن كمان تطلب أكتر من range في نفس الطلب، والرد ساعتها بيبقى multipart، بس الحالة الشائعة هي range واحد.

3. كمّل التحميل بأمان بـ If-Range

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

الحل هو If-Range. بتبعته مع الـ Range ومعاه الـ ETag أو الـ Last-Modified اللي خدتهم أول مرة (واحد بس منهم، مش الاتنين):

GET /a.mp4 HTTP/1.1
Host: example.com
Range: bytes=1024-
If-Range: "etag-value"

• لو الملف لسه زي ما هو: السيرفر يرجّع 206 بالجزء الناقص.
• لو الملف اتغيّر: السيرفر يرجّع 200 بالملف كله، فتبدأ من الأول بدل ما تبوّظ الملف.

4. اعرف الأكواد

• 206 Partial Content: ده الجزء اللي طلبته.
• 416 Range Not Satisfiable: الـ range اللي طلبته برة حجم الملف.
• 200 OK: السيرفر مش بيدعم الـ ranges، وبعتلك الملف كله.

طب والـ CDN؟

هنا الموضوع بيبقى مهم أكتر. Cloudflare نشرت يوم 23 أكتوبر 2026 إن video player بيعمل seek لنص فيلم بيطلب بضع ميجابايت بس، لكن في التنفيذ القديم عندهم للـ range caching، الطلب ده كان ممكن يخلّي Cloudflare تسحب 128 MiB من الـ origin وتنقلها بين الـ data centers، وأحيانًا بعد ما المشاهد يكون مشي أصلًا.

وأعلنت إن التنفيذ الجديد بقى متاح باسم Origin Range Requests، كـ feature self-service على كل الخطط، من غير range size تظبطه ومن غير ما تكلّم الـ support، وبيتفعّل بـ Cache Rule.

رأيي

لو بتقدّم ملفات كبيرة أو فيديو من الـ backend بتاعك، جرّب أمر الـ curl -I ده النهارده على أكبر ملف عندك. ناس كتير بتكتشف إن السيرفر (أو الـ framework اللي بيعمل stream للملف) بيبعت الملف كله في كل seek، وده بيضيع bandwidth وفلوس. ولو بتكتب download logic بنفسك، متكمّلش أي تحميل من غير If-Range.

السيرفر بتاعك بيرجّع Accept-Ranges؟

المصادر

• MDN — HTTP range requests
• Cloudflare Blog — Origin Range Requests: Serving large files without range-request tuning