סבב המראות משנה את מה ש-Squid יכול לעשות בו שימוש חוזר
הסבר מדוע חבילות RPM זהות שהורדו מכתובות מראה שונות יכולות לתפוס רשומות מטמון נפרדות ב-Squid.
שני לקוחות מורידים את אותה חבילת RPM דרך Squid, אך ההעברה השנייה עדיין מגיעה למראה. השוו את כתובות הבקשה המלאות:
http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpm
שמות קבצי החבילה תואמים; כתובות ה-URI היעד שלהן שונות. מפתחות מטמון HTTP כוללים לפחות את שיטת הבקשה ואת כתובת ה-URI היעד, ולכן סכומי בדיקה תואמים של החבילה אינם מאחדים את הרשומות הללו באופן אוטומטי.
Yum ו-DNF יכולים להשתמש ב-baseurl קבוע או לגלות מראות דרך mirrorlist ו-metalink. לכן התקנות זהות עשויות לבחור כתובות הורדה שונות.
שימוש במראה אחת מאושרת נותן לבקשות גלויות זהות מטמון עקבית. שמרו על יישור נתיבי המאגר, הארכיטקטורה והחבילה. נעיצה גם משנה את הזמינות ואת התנהגות בחירת המראה, ולכן הפכו אותה להחלטת מדיניות של המאגר.
בדקו אם אחסון אובייקטים במטמון זמין
בתוך מנהרת HTTPS CONNECT רגילה, Squid אינו יכול לראות את גוף תגובת ה-RPM לצורך אחסון HTTP במטמון. שם מארח מראה משותף לא ישנה זאת. שמרו על מאגרי HTTPS מוצפנים.
עבור תגובות ש-Squid יכול לאחסן במטמון, השימוש החוזר עדיין תלוי ברעננות, בהנחיות הבקשה והתגובה ובמדיניות המטמון המקומית. תעדו את הכתובת שנבחרה, אם העסקה הייתה HTTP גלוי או מנהרה מוצפנת, ואת תוצאת המטמון שלה כדי להסביר החמצה.