config Squid pour assurer en-tête HTTP correspond à celle du contenu mis en cache

Question

Nous avons une configuration en nuage comme ceci:

User Request -> Perlbal (SSL unwrapping) -> Squid (Caching) -> Apache -> HTTP Response 

Nous soutenons SSL sur certaines pages, et non pas sur d'autres. Tout ce qui est au-delà de la couche perlbal ne traite que les requêtes via HTTP non crypté car perlbal déballe le SSL, mais ajoute un en-tête X-Forwarded-Proto pour que l'application sache si SSL a été utilisé ou non.

Si une demande touche l'application (Apache) via HTTP, lorsque cette page particulière requiert SSL, elle est redirigée vers HTTPS.

Lorsqu'une demande de ressource sécurisée parvient à notre application et que l'application envoie Cache-Control: public, squid met en cache ce contenu correctement. Le problème est que si l'utilisateur essaie alors d'accéder à la version HTTP de cette ressource une fois qu'il est mis en cache, squid le traite comme cache HIT et renvoie la ressource mise en cache sur HTTP, alors qu'en fait nous avons besoin de le considérer comme un cache MISS car X -Forwarded-Proto ne correspond pas à la demande d'origine.

Comment cela est-il fait? Notre application envoie:

Vary: X-Forwarded-Proto,Accept-Encoding 

Je vais avoir du mal à trouver tout articles/documentation sur ce sujet et cet en-tête Variez semble être ce que les autres suggèrent, mais il ne fonctionne pas. Squid sert le contenu mis en cache indépendamment de l'en-tête X-Forwarded-Proto indiquant SSL ou autre.

Answer 1

OMFG.

Nous avions cela dans notre .htaccess pour des raisons historiques:

BrowserMatch "MSIE" brokenvary=1 
BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1 
BrowserMatch "Opera" !brokenvary 
SetEnvIf brokenvary 1 force-no-vary 

Trois devine ce qui se passe dans le cache squid une fois un IE 6 visites d'utilisateurs de notre site. Varier l'en-tête supprimé. La stratégie de cache est cassée.

Vis IE. Enlever ceci était un bon mouvement. Tout fonctionne maintenant.