Пакет mvc 4 и минимизация - не получаю 304 (не изменено) при обновлении

Я пробую объединение и минификацию MVC 4 Beta через System.Web.Optimization. Я надеялся, что сайт, для которого я его использую, получит 304 (Not Modified), когда я нажму «Обновить».

Я думал, что точка src для моего пакета js, /desktop-js-bundle?v=D33JhbMl9LHkXSPBj1tfRkRI0lHeYVmbSMQqD59bXHg1 (с этой версией #), заключалась в том, что версия # менялась только тогда, когда один из файлов в пакете на сервере был изменен. Тем не менее, каждый раз, когда я нажимаю «Обновить» и отслеживаю вкладку «Сеть» в Chrome F12, он делает запрос с тем же номером версии и получает статус 200.

Почему бы просто не вернуть 304?, что уменьшило бы нагрузку и увеличило производительность на приличную величину. Спасибо!


bundle asp.net-mvc-4 minify http-status-code-304 asp.net-optimization
person Ian Davis    schedule 21.03.2012    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Почему он просто не возвращает 304?

Потому что когда вы нажимаете F5, срок действия кеша вашего браузера истекает. По сути, ваш тест ошибочен. Вы должны разместить ссылки на этот пакет на разных страницах (используя тег <script>). Затем вы должны перейти на эти страницы с помощью гиперссылок. Теперь обратите внимание на вкладку Network.

Также убедитесь, что вы работаете в режиме Release.

ОБНОВИТЬ:

Хорошо, покопавшись еще немного вот что я узнал. Код состояния HTTP 200 действительно всегда отправляется, что нормально. Но во второй раз пакет извлекается из кеша.

Вот первый запрос:

введите здесь описание изображения

Мы видим, что в этом случае бандл поступает с сервера с заголовками ответов HTTP-кэша.

И вот вторая просьба:

введите здесь описание изображения

На втором снимке экрана ясно видно, что пакет обслуживается из кеша. Обратите внимание, что вся линия окрашена в серый цвет. Код состояния HTTP 200 является вымышленным => клиент даже не отправляет HTTP-запрос на сервер, поскольку он извлекает пакет непосредственно из своего кеша.

То же самое я могу наблюдать и в Google Chrome.

Для первого запроса:

введите здесь описание изображения

И для второго запроса:

введите здесь описание изображения

person Darin Dimitrov    schedule 21.03.2012
comment
но он возвращает 304, когда делает запрос на файл js, который у меня есть вне пакета. и 304 для всех изображений. - person Ian Davis; 21.03.2012
comment
@IanDavis, ты работаешь в режиме Release? Пакеты IIRC кэшируются только в режиме выпуска. - person Darin Dimitrov; 21.03.2012
comment
как я могу сказать? это происходит после того, как я делаю публикацию в один клик, которую я настроил в Visual Studio, затем я захожу на рабочий сайт и нажимаю «Обновить», чтобы увидеть 200 (не 304). - person Ian Davis; 21.03.2012
comment
У вас есть <compilation debug="false"> в вашем web.config? Обычно, если вы опубликовали свой сайт в режиме выпуска, это должно быть так. Также попробуйте то, что я вам предложил: использовать ссылки для перехода между страницами, которые содержат одно и то же включение сценария пакета, чтобы увидеть, получаете ли вы по-прежнему 200-е. - person Darin Dimitrov; 21.03.2012
comment
У меня есть <compilation debug="true" targetFramework="4.0"> в опубликованном файле web.config. Интересно, почему визуальная студия так делает. и я пробовал навигацию по страницам с одинаковыми ссылками на скрипт - все еще 200. позвольте мне попробовать обновление web.config. а пока кто-нибудь знает, почему Visual Studio это делает? я пропустил настройку? - person Ian Davis; 21.03.2012
comment
после изменения его на <compilation debug="false" targetFramework="4.0"> все еще 200, когда я нажимаю «Обновить» и когда я перемещаюсь между страницами. Примечание. У меня есть одна ссылка на скрипт, ведущая непосредственно к файлу js, и она возвращает 304. Только мои пакеты css и js продолжают возвращать 200, даже если они продолжают использовать одну и ту же версию #. - person Ian Davis; 21.03.2012
comment
Хм, это очень странно. Посмотрим, смогу ли я воспроизвести проблему. - person Darin Dimitrov; 21.03.2012
comment
@IanDavis, хорошо, я обновил свой ответ, добавив в него исследования, которые я провел. Вывод - бандл корректно обслуживается из кеша второй раз. Код состояния 200, который вы видите, даже не исходит от сервера. Это чисто выдумка. Клиент даже не отправляет запрос на сервер, а напрямую извлекает его из своего кеша. - person Darin Dimitrov; 21.03.2012
comment
@DarinDimitrov Я могу убедиться, что это верно для FF и Chrome, но проверяли ли вы IE? Я запускаю IE10 в предварительной версии Windows 8 для потребителей, и JS определенно не обслуживается из кеша браузера, даже по ссылке. Похоже, пока System.Web.Optimization не поддерживает ETags, IE будет возвращаться к серверу за запросом. - person Emil Lerch; 10.05.2012

arrow_upward
1
arrow_downward

У меня была такая же проблема, и проблема была с пакетом Microsoft.AspNet.Web.Optimization. Как описано здесь: http://aspnetoptimization.codeplex.com/workitem/127, версии 1.1. 2 - 1.1.3 затронуты. После перехода на версию 1.1.1 все работает нормально, и после обновления возвращается 304 для неизмененных ресурсов.

Вы можете сделать это в консоли диспетчера пакетов с помощью следующих команд:

PM> Uninstall-Package "Microsoft.AspNet.Web.Optimization"
PM> Install-Package "Microsoft.AspNet.Web.Optimization" -Version 1.1.1
person Tomasz Rozmus    schedule 30.09.2015