Squid Config, чтобы убедиться, что заголовок HTTP совпадает с тем, что из кэшированного контента

Question

У нас есть облачная настройка, как это:

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

Мы поддерживаем SSL на некоторых страницах, а не на других. Все, кроме Perlbal Payer, только запросы процесса над незашифрованным HTTP, так как Perlbal разворачивает SSL, но он добавляет X-Forwarded-Proto заголовок, так что приложение знает, использовался ли SSL или нет.

Если запрос попадает в приложение (Apache) через http, когда эта конкретная страница требует SSL, он перенаправляет к HTTPS.

Когда запрос на безопасный ресурс достигает нашего приложения, и если приложение отправляет Cache-Control: public, Squid кэширует это содержание правильно. Проблема в том, что если пользователь затем пытается получить доступ к HTTP-версии этого ресурса после того, как он кэшируется, SQUID обрабатывает его как кэш-удар и возвращает кэшированный ресурс по адресу http, когда на самом деле нам нужно, чтобы он считал, что кэш мисс, потому что х -Помощь-прото не соответствует первоначальному запросу.

Как это сделано? Наше приложение отправляет:

Vary: X-Forwarded-Proto,Accept-Encoding

Мне трудно найти какие-либо статьи / документации по этому поводу, и этот заголовок варьирования кажется, что другие люди предлагают, но это не работает. SQUID служит кэшированному контенту независимо от заголовка X-Proto, указывающего SSL или иным образом.

Answer 1

Омфг

У нас было это в нашей .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 пользователь посещает наш сайт. Варьируют заголовок. Кэшинговая стратегия сломана.

Винт т.е. Удаление этого было хорошим ходом. Все работает сейчас.