config calamar para asegurar la cabecera HTTP coincide con el del contenido almacenado en caché

Question

Tenemos una configuración nube como esto:

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

soporte SSL en algunas páginas, y no en otros. Todo más allá de la capa de Perlbal único proceso de solicitudes a través de HTTP sin cifrar desde desenrolla Perlbal el SSL, pero añade una cabecera X-Forwarded-Proto de modo que la aplicación sabe si se utiliza SSL o no.

Si una solicitud golpea la aplicación (Apache) a través de HTTP, cuando esa página en particular requiere SSL se redirige a HTTPS.

Cuando una solicitud de un recurso seguro llega a nuestra aplicación, y si la aplicación envía Cache-Control: public, cachés de calamar que el contenido correctamente. El problema es que si el usuario intenta acceder a la versión HTTP de ese recurso una vez que se almacena en caché, los procesos de calamar como un acierto de caché y devuelve el recurso en caché a través de HTTP, cuando en realidad lo necesitamos tener en cuenta que una caché SRTA porque X -Forwarded-Proto no coincide con la solicitud original.

¿Cómo se hace esto? Nuestra aplicación envía:

Vary: X-Forwarded-Proto,Accept-Encoding

Estoy teniendo dificultades para encontrar cualquier artículo / documentación sobre esto y esta cabecera Vary parece ser lo que otras personas sugieren, pero no está funcionando. Calamar sirve el contenido almacenado en caché, independientemente de la X-reenviado-Proto cabecera que indica SSL o no.

Answer 1

OMFG.

Hemos tenido esto en nuestro .htaccess por razones históricas:

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

Tres adivina lo que ocurre con la memoria caché de calamar una vez que un usuario visita IE 6 nuestro sitio. Cabecera Vary eliminado. estrategia de almacenamiento en caché roto.

Tornillo IE. La eliminación de este era un buen movimiento. Todo funcionando ahora.