ادامهٔ دانلود از طریق Squid
پیش از ادامه، پاسخ‌های Range و هویت شیء را بررسی کنید و سیاست پیش‌دریافت Squid را از پشتیبانی پایهٔ محدوده‌ها جدا بدانید.
فقط وقتی دانلود را ادامه دهید که download.part به همان نمایش شیء تعلق داشته باشد که اکنون درخواست می‌کنید. نام فایل به‌تنهایی این را ثابت نمی‌کند؛ مبدأ ممکن است محتوا را از اولین تلاش تغییر داده باشد.
curl --proxy http://proxy.example:3128 --noproxy '' --connect-timeout 5 --max-time 60 -C - --output download.part http://files.example/test.binهر دو نقطهٔ اتصال را با سرویس‌هایی جایگزین کنید که مجاز به استفاده از آن‌ها هستید. برای مقایسهٔ فایل عمومی در جایی که پراکسی عمومی مجاز است، یک نقطهٔ HTTP از فهرست پراکسی‌های HTTP انتخاب کنید. -C - اندازهٔ فایل موجود را نقطهٔ ادامه در نظر می‌گیرد. پاسخ مقصد را بررسی کنید، نه اینکه هر بدنهٔ برگشتی را بایت‌های کم‌شده بدانید:
| پاسخ | تفسیر |
|---|---|
| 206 همراه Content-Range | بررسی کنید محدودهٔ برگشتی همان ادامهٔ موردانتظار باشد. |
| 200 | سرور ممکن است Range را نادیده گرفته و کل نمایش را فرستاده باشد. |
| 416 | محدودهٔ درخواستی قابل‌برآورده‌شدن نیست؛ صفحهٔ خطا را به فایل اضافه نکنید. |
اعتبارسنج‌ها و If-Range می‌توانند از چسباندن نسخه‌های مختلف یک منبع متغیر جلوگیری کنند. پیش از اعتماد به فایل کامل، قواعد نمایش برنامه را رعایت کنید.
range_offset_limit در Squid 6.13 تعیین می‌کند چه زمانی شیء برای کش شدن از ابتدا دریافت شود، نه اینکه آیا کلاینت می‌تواند محدوده‌ای بخواهد:
range_offset_limit 0حد صفر از دریافت اضافهٔ بخش آغازین فقط برای پر کردن کش جلوگیری می‌کند. فرستادن محدودهٔ مفید بدون کش کردن شیء هم می‌تواند موفق باشد. در CONNECT HTTPS معمولی، تبادل Range داخل TLS مقصد است؛ همان پاسخ را بخوانید، نه اینکه سیاست قابل‌مشاهدهٔ کش اشیای Squid را کنترل درخواست داخلی بدانید.