إذا بدأ ملف PDF أو جدول بيانات مفترض بـ HTTP/1.1 200 OK، فإن المُنزِّل حفظ استجابة خامًا بدلًا من الملف. هذه الاستجابة التخطيطية تحتوي على أربعة بايتات فقط من المحتوى:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

الملف هو DATA. سطر الحالة والترويسات وعلامة الحجم والبنية المُنهية تنتمي إلى HTTP. إزالة عدد ثابت من البايتات غير آمنة لأن أطوال الترويسات تتفاوت. نسخ كل ما بعد أول سطر فارغ يُبقي تأطير القطع، والردود المعلوماتية قد تسبق الاستجابة النهائية.

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

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

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

HTTPS يحتاج أكثر من تجريد استجابة CONNECT: بعد إعداد النفق بنجاح، أنشئ TLS الوجهة ثم حلل استجابة HTTP الداخلية. البايتات المشفرة التي تلي ترويسات الوسيط ليست الملف القابل للتنزيل.

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

مقالات ذات صلة