IIS и статический контент?

Ответ 1

Я понимаю вашу ситуацию. Иногда его запутывает, как IIS обрабатывает файл. Он также отличается для IIS 6 и IIS 7, а также для классических пулов приложений и пулов приложений с интегрированным режимом. Мой опыт в основном связан с интегрированными пулами приложений в IIS 7.5, поэтому я могу наиболее точно прокомментировать ситуацию.

Первый вопрос

Но как IIS знает, что на самом деле является статическим контентом и что такое нет?

Это просто изображения, css, js, а не ASPX, ashx...?

Где я могу увидеть в IIS то, что уже считается статическим и что не?

Вы можете просмотреть список обработчиков файлов в IIS, перейдя на ваш сайт, а затем нажмите "Отображения обработчиков". По умолчанию они наследуются от базы .Net base.config, которая находится в другом месте в зависимости от вашей версии .Net framework.

• C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config
• C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config

Если запрашиваемый файл еще не явно сопоставлен с другим обработчиком, он падает на обработчик catch (*) в качестве последнего параметра (System.Web.DefaultHttpHandler), который определяет, является ли это статическим файлом или просмотром каталога запрос. Таким образом, статические файлы - это просто файлы, не связанные с другим обработчиком. Например, вы увидите, что *.aspx уже сопоставлен с System.Web.UI.PageHandlerFactory до этого обработчика по умолчанию. Поэтому его обработка будет обработана этим обработчиком и не будет считаться статическим файлом. Если вы удалили это сопоставление, вы могли бы технически обслуживать *.aspx как статический файл, если вы действительно хотели (просто для доказательства того, как он работает).

Но вы также можете явно указать тип файла как статический файл, добавив запись в свой раздел http.Handlers в web.config, сопоставляя расширения файлов с System.Web.StaticFileHandler в IIS. Например:

<configuration>
  <system.webServer>
    <handlers>
      <add name="StaticHandler" verb="*" path="*.zip" type="System.Web.StaticFileHandler" preCondition="integratedMode" />
    </handlers>
  </system.webServer>
</configuration>

В этом примере используется раздел конфигурации <system.webServer>, поэтому его для пула приложений работает в Интегрированном режиме.

Второй вопрос

Как насчет сценария, в котором была объявлена ​​страница с <% @ Заголовок OutputCache (без местоположения). изображения, css, js src файлы внутри него, также выводятся в кеш с тем же свойства?

Нет. Поскольку страница является сервером как отдельный запрос (может быть, даже отдельным обработчиком), он может иметь совершенно разные заголовки/подсказки кеша. Страница хоста и ресурсы, которые он может использовать, не связаны с перспективой кэширования.

Фактически, вы даже можете иметь более короткий период кеша для *.html и более длинный период кеша для *.jpg или *.png? Что-то рассмотреть.

Третий вопрос

Как лучший prcatice, я должен установить год в будущем, так как максимальное время истечения. Я должен использовать это как значение по умолчанию для всех статический контент на сайте

Хм... Я мог бы не пройти за год. Как насчет одного месяца? Я бы установил глобальную политику следующим образом:

<configuration>
  <system.webServer>
    <staticContent>
      <!-- Set expire headers to 30 days for static content-->
      <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="30.00:00:00" />
    </staticContent>
  </system.webServer>
</configuration>

Это то же самое, что и образец, показанный выше, но не находится внутри элемента <location>, вместо этого он прав в корневом элементе <configuration>, поэтому он является политикой по умолчанию. Опять же, это для пула приложений, работающего в Интегрированном режиме. Иногда вам также необходимо включить:

<configuration>
    <system.webServer>
        <modules runAllManagedModulesForAllRequests="true">
            <!-- stuff -->
        </modules>
    </system.webServer>
<system.webServer>

Это просто гарантирует, что статические файлы обрабатываются с помощью управляемого обработчика статических файлов, который учитывает вышеуказанные элементы конфигурации.

Изменить для отправки комментариев

Документация для диалогового окна конфигурации, которое вы указали выше, находится здесь: Настроить заголовок ответа истечения HTTP (IIS 7)

По-видимому, эти настройки сохраняются в формате .c:\Windows\System32\inetsrv\config\applicationHost.config

У меня нет IIS7 и лично разрабатываю на IIS 7.5 сейчас. Поэтому, пожалуйста, отправьте комментарий, если вы можете проверить, что это место является точным!

Ответ 2

• Статический контент - это тот, который IIS читается и отправляется в браузер без какой-либо обработки. Там вы можете настроить IIS, чтобы включить некоторые Cache-Control Header, чтобы кэшировать его на компьютерах браузеров клиентов.
• Вы можете сделать этот эфир с помощью прямой настройки IIS, ether с помощью команд на web.config, как вы говорите. Команды, которые вы добавляете в web.config и относятся к IIS, не связаны с самим asp.net, но IIS и IIS сохраняют его конфигурацию в другом файле, поэтому, когда вы меняете заголовки управления кешем, IIS вы не видите их на web.config.
• Теперь для статического контента, такого как изображения, CSS, JavaScript и другие подобные файлы они говорят, что вы можете следовать политике "никогда не истекать" , добавив 10 лет.
• Проблема заключается в том, что если вы не можете изменить содержимое статического файла, если, например, вы кешируете javascript файл с 10 годами, и вы делаете небольшое изменение на нем, то вам нужен эфир, чтобы изменить имя файла, эфир, чтобы добавить некоторый параметр в конец.
• Теперь элемент <%@ OutputCache в элементе управления относится к кешу сервера, а не к клиенту, и на самом деле это кэширование рендеринга элемента управления на сервере, поэтому в следующий раз, когда вы просите его не терять время чтобы снова отобразить его, но прочитать его из кеша - все равно отправить его в браузер.

И вы также можете прочитать этот ответ еще: В чем разница между кешем IIS (динамический и статический), OutPutCache и кешем браузера