Вопрос по asp.net-mvc, cache-control, javascript – Выдвиньте новую версию JavaScript, CSS и графического контента, используя ASP .NET MVC

3

Я хочу, чтобы мой JavaScript ссылался через & lt; script & gt; теги, мои css и различные графические файлы для кэширования в браузере пользователя для данной версии моего сайта. Однако когда я выпускаю обновление файла, я хотел бы убедиться, что новый контент (Javascript, CSS, графика и т. Д.) Будет обновляться на компьютере пользователя.

При исследовании этой проблемы я обнаружил ряд возможных решений:

Adjust http headers for things like cache control and expires Append a unique querystring to each resource request Include a version number in the path (or filename) of the resource being requested

Моя проблема с вариантом 1 (помимо незнания того, как реализовать его для некоторых типов контента) заключается в том, что если между браузером и IIS существует промежуточный прокси-сервер, то промежуточный прокси-сервер может не учитывать заголовки http, и контент будет кэшируется между браузером и прокси.

Моя проблема с вариантом 2 в два раза. Например, если я просто использую случайное число или временную метку, то браузер будет каждый раз запрашивать новый ресурс, минуя локальный кеш, даже если содержимое не изменилось (если не между выпусками). Обойти эту проблему можно, используя метку времени файла ресурса или хеш файла; это изменится только тогда, когда произойдет новый выпуск. Однако это вызывает у меня второе беспокойство: я понимаю, что некоторые веб-прокси никогда не кэшируют что-либо со строкой запроса по умолчанию (http://stackoverflow.com/questions/5541340/how-can-i-prevent-javascript-caching- -подход строку запроса-разве-работает). Хотя это, вероятно, настраиваемо, я бы не хотел полагаться на то, что администратор изменил настройку по умолчанию, чтобы получить преимущество в производительности от кэширования.

Вариант 3 кажется лучшим выбором, но я не знаю, как реализовать его на практике для ASP .NET MVC (в настоящее время используется ASP .NET MVC 3). Вручную, я мог бы зайти в каждый файл, который ссылается на графический, css или внешний файл javascript, и изменить путь для включения другого номера версии для каждого выпуска, но, очевидно, это утомительно и подвержено ошибкам.

Мои вопросы тогда:

1) Существуют ли другие стратегии, позволяющие избежать кэширования (для данного выпуска), которые я должен рассмотреть, и

2) предполагая, что я использую опцию 3 (включая номер версии в пути к ресурсу), как я могу добиться этого в приложении ASP .NET MVC способом, который реально поддерживать?

Спасибо,

Notre

Ваш Ответ

2   ответа
2

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

Пожалуйста, обратитесь ответ @Kip в этомнить это ясно описывает об этом. Хотя ответ в php, он может быть реализован в самом asp.net mvc.

Если вы используете новую функцию связывания / минимизации в ASP.NET MVC 4, я думаю, что управление версиями будет осуществляться им автоматически (хотя и не уверен).

+1 Мы связываем и добавляем номер сборки к запросам к этому пакету ресурсов, чтобы избежать неизбежного «очистки кэша браузера». телефонные звонки при обновлении.
Спасибо, Марк, за то, что поделились темой с ответом @ Kip. Это похоже на то, что я хочу, и я посмотрю на его создание. Да, вы правы в отношении объединения / минимизации ASP .NET MVC 4 - я обнаружил в другом потоке, что он обрабатывается автоматически. (Он использует подход с использованием строки запроса, который мне не очень нравится по причинам, указанным выше). В настоящее время мы все еще находимся на ASP .NET MVC 3, поэтому я пока не могу принять это решение. Notre
1

ханизмом истечения срока действия.

Для механизма Expiration вы можете использовать expires для заголовка (но это хорошо для статического ресурса, который, как вы знаете, никогда не изменится).

Для валидации и условного получения используются ETag, что, кажется, идеально подходит для вашей задачи.

Спасибо за информацию. Этот документ о производительности Yahoo был великолепен! После прочтения раздела об ETag, я считаю, что это не тот путь, по причинам, изложенным в статье. Ранее в статье говорилось, что "если вы используете заголовок Expires далекого будущего, вы должны изменять имя файла компонента при каждом изменении компонента. В Yahoo! мы часто делаем этот шаг частью процесса сборки: номер версии внедряется в имя файла компонента, например, yahoo_2.0.6.js. & quot; Это подтверждает мое впечатление, что это правильный путь. Notre
как насчет установки ETag? Всякий раз, когда компонент изменяется, вы можете изменить etag для ваших файлов js.
Привет, для управления Etags и Cache, пожалуйста, обратитесь к этой статьеdeveloper.yahoo.com/performance/rules.html  Для того, чтобы реализовать в MVC. Пожалуйста, обратитесь к этой статьеstackoverflow.com/questions/6642815/…
Похоже, что ETag может быть проблематичным, согласно предоставленной вами статье Yahoo; см. «Настройка ETag». раздел Notre
Привет Анад, не могли бы вы рассказать о механизме валидации и условных ETag? Может быть, со ссылкой или что-то? Я не уверен, что все это значит, и как это применять. Спасибо! Notre

Похожие вопросы