Pourquoi CONNECT ne remplit pas le cache d’objets de Squid
Pourquoi un tunnel HTTPS ordinaire peut transférer beaucoup d’octets sans fournir au proxy des objets de réponse HTTP réutilisables.
Un tunnel CONNECT ordinaire fournit à Squid des octets chiffrés, pas une réponse de site pouvant être mise en cache. Un gros téléchargement HTTPS peut donc créer beaucoup de trafic sans entrée d’objet réutilisable.
Squid peut enregistrer destination, durée et nombre d’octets du tunnel. Il ne reçoit pas le chemin URL interne, les directives de cache, la représentation et les validateurs comme des messages HTTP normaux à stocker et réutiliser. Plus d’espace disque ou une limite de taille d’objet accrue ne les rendent pas visibles.
Examinez méthodes de requête et journaux de tunnels avant de déclarer le cache défaillant. Une charge dominée par CONNECT est compatible avec de gros transferts et peu de réutilisation d’objets. Pour un vrai contrôle, utilisez une ressource HTTP sous votre contrôle avec en-têtes de cache explicites et contenu connu ; vérifiez que vous testez le traitement d’objets de Squid, pas un tunnel, le cache du navigateur ou le CDN de destination.
Le TLS vers le proxy est une couche distincte. Après terminaison de son propre service d’écoute TLS, Squid peut traiter une requête vers une destination HTTP ordinaire. Si cette connexion demande plutôt CONNECT vers HTTPS, le TLS interne de destination reste distinct et opaque.
L’interception HTTPS modifie les exigences de confiance des certificats, d’autorisation et de confidentialité. Ce n’est pas un simple réglage d’espace cache, et un proxy direct normal n’a pas besoin d’interception pour fonctionner.