Предотвращать связывание пакета, если кеш-бит не соответствует содержимому

Я использую Bundling и Minification на ферме серверов, где есть период перекрестка старых и новых серверов.

Проблема заключается в том, что старые серверы кэшируют содержимое URL-адреса нового URL-адреса кэша пакетов.

Например, новый HTML кэшируется с URL new:

<script src="/bundle.css?v=RBgbF6A6cUEuJSPaiaHhywGqT7eH1aP8JvAYFgKh"></script>

Затем выполняется запрос к серверу old, который еще не обновлен новым кодом CSS, а затем кэшируется.

Любые последующие вызовы URL new свяжутся, затем возвращают старый код.

Поэтому есть ли способ проверить, соответствует ли содержимое пакета хэш-кешу? И если он не выбрасывает 404, например.

Используя мой пример выше, когда запрос возвращается к старому серверу для пакета, он проверяет содержимое пакета, генерирует хэш содержимого и сравнивает его с запросом.

В этом случае кеш-бастер не будет соответствовать фактическому хеш-содержимому и будет возвращено значение 404.

В конечном итоге пользователь ударил бы по серверу new с запросом на расслоение, а правильный контент был бы кеширован.

Ответ 1

Мы скоро столкнемся с одной и той же проблемой, но мы придерживаемся только двух доменов обновления (разделяем серверы пополам, чтобы одновременно работать не более одной версии).

Насколько я понимаю, существует 4 возможных варианта:

Всегда ли ваш статический контент указывает на современный сервер. Это можно сделать (в зависимости от вашей конфигурации) по IP-адресу или с помощью URL-адреса, который, как вы знаете, уже обновлен (если у вас есть сервер, который сначала обновляется).
Настройте балансировщик нагрузки так, чтобы запросы с одного и того же IP-адреса попадали в одну и ту же систему (если ваш статический контент обслуживается с серверов приложений). Если это невозможно сделать на уровне балансировки нагрузки, вы можете сделать это дальше, настроив разные IP-адреса для разных сред, а затем поменяв их записи DNS.
Реализовать обработчик в ASP.NET, который прослушивает файлы CSS, и проверяет, является ли хэш этого пакета ожидаемым. Возможно, вам понадобится объект singleton, который будет хранить их, когда они будут созданы, когда ваше приложение загрузится. Затем он может вернуть 404, 301 (чтобы заставить их повторить попытку) или вернуть старую версию, но дать указание не кэшировать результаты. Обратите внимание: с HttpPipelining вы вряд ли попадете на другой сервер, поэтому перенаправление может не помочь.
Установите флаг конфигурации, который установлен во время развертывания, который изменяет все ваши URL-адреса, связанные с кэшированием, на текущую дату. Это эффективно отключит все кэширование до завершения развертывания, что означает, что любые "неправильные" активы не будут сохранены.

Это проблема, которую вы на самом деле видите, или она гипотетическая? Если на вашем сайте не очень высокий трафик, и ваши развертывания занимают несколько минут, это не то, что вы, вероятно, увидите. Вам нужно будет опасаться возвращения 404s, поскольку иногда неправильная таблица стилей лучше, чем ни одна таблица стилей.