Squid کے ذریعے ڈاؤن لوڈ دوبارہ جاری کریں
جاری کرنے سے پہلے Range جواب اور آبجیکٹ کی یکسانیت دیکھیں اور Squid کی پری فیچ پالیسی کو بنیادی Range معاونت سے الگ سمجھیں۔
صرف تب ڈاؤن لوڈ جاری کریں جب 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 - موجودہ فائل کے سائز کو جاری رکھنے کا مقام بناتا ہے۔ ہر واپس آنے والی باڈی کو گم شدہ بائٹس ماننے کے بجائے منزل کا جواب دیکھیں:
| جواب | مطلب |
|---|---|
| Content-Range کے ساتھ 206 | دیکھیں لوٹایا گیا رینج مطلوبہ تسلسل ہے۔ |
| 200 | سرور نے شاید Range نظرانداز کرکے پوری نمائندگی بھیجی ہو۔ |
| 416 | مطلوبہ رینج پوری نہیں ہو سکتی؛ خرابی کا صفحہ فائل میں شامل نہ کریں۔ |
ویلیڈیٹر اور If-Range بدلتے وسیلے کے مختلف ورژن جوڑنے سے بچا سکتے ہیں۔ مکمل فائل پر اعتماد سے پہلے ایپ کی نمائندگی کے قواعد اپنائیں۔
Squid 6.13 کا range_offset_limit یہ طے کرتا ہے کہ کیش کے لیے آبجیکٹ کب شروع سے لیا جائے، نہ کہ کلائنٹ رینج مانگ سکتا ہے یا نہیں:
range_offset_limit 0صفر حد صرف کیش بھرنے کے لیے شروع کا اضافی حصہ لینے سے بچاتی ہے۔ آبجیکٹ کیش کیے بغیر مفید رینج بھیجنا پھر بھی کامیاب ہو سکتا ہے۔ عام HTTPS CONNECT میں Range تبادلہ منزل کے TLS کے اندر ہوتا ہے؛ وہ جواب پڑھیں، Squid کی نظر آنے والی آبجیکٹ کیش پالیسی کو اندرونی درخواست کا کنٹرول نہ سمجھیں۔