وقتی فایل دانلودشده با یک خط وضعیت HTTP آغاز می‌شود

اگر یک PDF یا صفحه‌گستردهٔ فرضی با HTTP/1.1 200 OK آغاز شود، دانلودکننده به‌جای فایل، یک پاسخ خام ذخیره کرده است. این پاسخ شماتیک فقط چهار بایت محتوا دارد:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

فایل DATA است. خط وضعیت، سرآیندها، نشانگر اندازه و ساختار پایانی متعلق به HTTP هستند. حذف تعداد ثابتی بایت ناامن است چون طول سرآیندها متفاوت است. کپی کردن همه‌چیز پس از اولین خط خالی هنوز قالب‌بندی تکه‌ای را باقی می‌گذارد، و پاسخ‌های اطلاعاتی می‌توانند پیش از پاسخ نهایی بیایند.

برای یک دانلود معمولی، کپی از سوکت خام به فایل را با رابط بدنهٔ پاسخ کلاینت HTTP جایگزین کنید. پروکسی آن را پیکربندی کنید، وضعیت نهایی را اعتبارسنجی کنید و بدنه را به یک خروجی موقت جریان دهید. کلاینت قالب‌بندی پیام را مدیریت می‌کند: بدنه‌های محدودشده با طول، تکه‌ای و محدودشده با اتصال به تجزیهٔ متفاوتی نیاز دارند.

کدگذاری محتوا لایهٔ دیگری است. بر اساس رفتار مستند کلاینت تصمیم بگیرید که به بایت‌های رمزگشایی‌شدهٔ فایل نیاز دارید یا به محتوای خامی که صریحاً درخواست شده است. بایت‌های فشرده به‌طور خودکار خرابی پروکسی نیستند.

اگر برنامه باید کد سطح سوکت را نگه دارد، مالک همهٔ آن قواعد تجزیه و نیز مدیریت خواندن و نوشتن است. فقط تعداد بایت‌هایی را بنویسید که خواندن واقعاً برمی‌گرداند، نه ظرفیت بافر، و نوشتن‌های جزئی را مدیریت کنید. در غیر این صورت محتوای کهنهٔ بافر می‌تواند حتی بدنه‌ای را که درست استخراج شده خراب کند.

HTTPS بیش از کنار زدن پاسخ CONNECT لازم دارد: پس از برقراری موفق تونل، TLS مقصد را برقرار کنید و سپس پاسخ HTTP درونی را تجزیه کنید. بایت‌های رمزنگاری‌شده پس از سرآیندهای پروکسی، فایل قابل دانلود نیستند.

خروجی ناموفق یا ناقص را با یک نام موقت رها کنید. آن را فقط پس از موفقیت انتقال و بررسی‌های فایل منتشر کنید؛ فایل غیرخالی دانلود کامل را اثبات نمی‌کند.