המשך הורדות דרך 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 שליטה על הבקשה הפנימית.