La rotazione dei mirror cambia ciò che Squid può riutilizzare

Due client scaricano lo stesso RPM tramite Squid, ma il secondo trasferimento raggiunge comunque un mirror. Confrontate gli URL completi delle richieste:

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

I nomi dei file del pacchetto coincidono; i loro URI di destinazione differiscono. Le chiavi della cache HTTP includono almeno il metodo della richiesta e l'URI di destinazione, quindi checksum identici del pacchetto non uniscono automaticamente queste voci.

Yum e DNF possono usare un baseurl fisso o scoprire i mirror tramite mirrorlist e metalink. Installazioni identiche possono quindi scegliere URL di download diversi.

Usare un solo mirror approvato dà alle richieste visibili un'identità di cache coerente. Mantenete allineati i percorsi del repository, l'architettura e la suite. Il pinning cambia anche la disponibilità e il comportamento di selezione dei mirror, quindi rendetelo una decisione di politica del repository.

Verificate se la cache degli oggetti è disponibile

All'interno di un normale tunnel HTTPS CONNECT, Squid non può vedere il corpo della risposta RPM per la cache HTTP. Un nome host mirror condiviso non cambierà questo. Mantenete i repository HTTPS cifrati.

Per le risposte che Squid può memorizzare, il riutilizzo dipende ancora dalla freschezza, dalle direttive di richiesta e risposta e dalla politica locale della cache. Registrate l'URL scelto, se la transazione era HTTP visibile o un tunnel cifrato, e il suo esito nella cache per spiegare un mancato utilizzo.