У нас есть такая облачная настройка:
User Request -> Perlbal (SSL unwrapping) -> Squid (Caching) -> Apache -> HTTP Response
Мы поддерживаем SSL на некоторых страницах, но не на других. Все, что находится за пределами уровня perlbal, обрабатывает запросы только по незашифрованному HTTP, поскольку perlbal разворачивает SSL, но он добавляет X-Forwarded-Proto заголовок, чтобы приложение знало, использовался SSL или нет.
Если запрос попадает в приложение (Apache) через HTTP, когда эта конкретная страница требует SSL, он перенаправляется на HTTPS.
Когда запрос на безопасный ресурс достигает нашего приложения, и если приложение отправляет Cache-Control: public, squid правильно кэширует это содержимое. Проблема в том, что если пользователь затем пытается получить доступ к HTTP-версии этого ресурса после его кеширования, squid обрабатывает его как HIT кеша и возвращает кэшированный ресурс по HTTP, тогда как на самом деле нам нужно, чтобы он считался кешем MISS, потому что X -Forwarded-Proto не соответствует исходному запросу.
Как это сделать? Наше приложение отправляет:
Vary: X-Forwarded-Proto,Accept-Encoding
Мне сложно найти какие-либо статьи / документацию по этому поводу, и этот заголовок Vary кажется тем, что предлагают другие люди, но он не работает. Squid обслуживает кэшированный контент независимо от заголовка X-Forwarded-Proto, указывающего SSL или иначе.
OMFG.
У нас было это в нашем .htaccess по историческим причинам:
BrowserMatch "MSIE" brokenvary=1
BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1
BrowserMatch "Opera" !brokenvary
SetEnvIf brokenvary 1 force-no-vary
Три предположения, что происходит с кешем squid, когда пользователь IE 6 заходит на наш сайт. Заголовок Vary удален. Стратегия кеширования нарушена.
Винт IE. Удаление этого было хорошим ходом. Теперь все работает.