Rrotullimi i pasqyrave ndryshon atë që Squid mund të ripërdorë

Dy klientë shkarkojnë të njëjtin RPM përmes Squid, por transferimi i dytë ende arrin në një pasqyrë. Krahasoni URL-të e plota të kërkesave:

http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpm

Emrat e skedarëve të paketës përputhen; URI-të e tyre të synuara ndryshojnë. Çelësat e cache-së HTTP përfshijnë të paktën metodën e kërkesës dhe URI-në e synuar, kështu që shumat e kontrollit që përputhen të paketës nuk i bashkojnë automatikisht këto zëra.

Yum dhe DNF mund të përdorin një baseurl fiks ose të zbulojnë pasqyra përmes mirrorlist dhe metalink. Prandaj instalimet identike mund të zgjedhin URL të ndryshme shkarkimi.

Përdorimi i një pasqyre të vetme të miratuar u jep kërkesave të dukshme një identitet të qëndrueshëm cache. Mbani rrugët e depove, arkitekturën dhe grupin të rreshtuara. Fiksimi ndryshon gjithashtu disponueshmërinë dhe sjelljen e përzgjedhjes së pasqyrave, prandaj bëjeni një vendim të politikës së depos.

Kontrolloni nëse cache-ja e objekteve është e disponueshme

Brenda një tuneli të zakonshëm HTTPS CONNECT, Squid nuk mund të shohë trupin e përgjigjes RPM për cache HTTP. Një emër hosti i përbashkët pasqyre nuk do ta ndryshojë këtë. Mbani depot HTTPS të kriptuara.

Për përgjigjet që Squid mund të ruajë në cache, ripërdorimi ende varet nga freskia, direktivat e kërkesës dhe përgjigjes dhe politika lokale e cache-së. Regjistroni URL-në e zgjedhur, nëse transaksioni ishte HTTP i dukshëm apo tunel i kriptuar, dhe rezultatin e cache-së për të shpjeguar një humbje.