Spegula rotacio ŝanĝas tion, kion Squid povas reuzi
Klarigu, kial identaj RPM-pakaĵoj elŝutitaj de malsamaj spegulaj URL-oj povas okupi apartajn kaŝmemorajn enskribojn de Squid.
Du klientoj elŝutas la saman RPM per Squid, sed la dua transigo ankoraŭ atingas spegulon. Komparu la plenajn petajn URL-ojn:
http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpmLa dosiernomoj de la pakaĵo kongruas; iliaj celaj URI-oj malsamas. La kaŝmemoraj ŝlosiloj de HTTP inkludas almenaŭ la petan metodon kaj la celan URI-on, do kongruaj kontrolsumoj de la pakaĵo ne aŭtomate kunigas tiujn enskribojn.
Yum kaj DNF povas uzi fiksan baseurl aŭ malkovri spegulojn per mirrorlist kaj metalink. Sekve identaj instalaĵoj povas elekti malsamajn elŝutajn URL-ojn.
Uzi unu aprobitan spegulon donas al videblaj petoj konsekvencan kaŝmemoran identecon. Tenu deponejajn vojojn, arkitekturon kaj suite kunordigitaj. Fiksado ankaŭ ŝanĝas disponeblecon kaj spegulan elekton, do faru ĝin decido de deponeja politiko.
Kontrolu ĉu objektkaŝado haveblas
Ene de ordinara HTTPS CONNECT tunelo, Squid ne povas vidi la korpon de la RPM-respondo por HTTP-kaŝado. Komuna spegula gastigantnomo tion ne ŝanĝos. Tenu HTTPS-deponejojn ĉifritaj.
Por respondoj, kiujn Squid povas kaŝi, reuzado ankoraŭ dependas de freŝeco, petaj kaj respondaj direktivoj, kaj loka kaŝpolitiko. Registru la elektitan URL-on, ĉu la transakcio estis videbla HTTP aŭ ĉifrita tunelo, kaj ĝian kaŝrezulton por klarigi maltrafon.