Конфигурация Squid для обеспечения того, чтобы заголовок HTTP совпадал с заголовком кэшированного содержимого - PullRequest
0 голосов
/ 05 ноября 2010

У нас есть облачная установка, подобная этой:

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 или иным образом.

1 Ответ

0 голосов
/ 05 ноября 2010

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 посещает наш сайт.Различные заголовки удалены.Стратегия кеширования нарушена.

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

...