Подтвердить что ты не робот

Как работает preCondition = "managedHandler" для модулей?

Прочитав некоторую документацию об интегрированном конвейере, я запутался в том, как IIS определяет, когда запускать управляемые модули, каков фактически управляемый запрос и как это определяется, например:

http://www.iis.net/learn/application-frameworks/building-and-running-aspnet-applications/aspnet-integration-with-iis http://blogs.msdn.com/b/tmarq/archive/2007/08/30/iis-7-0-asp-net-pipelines-modules-handlers-and-preconditions.aspx

"Управляемые" запросы упоминаются несколько раз. Там один экземпляр, где объясняется, что управляемый запрос является запросом, который имеет сопоставление с управляемым обработчиком. Там также цитата, в которой говорится, что обработчик является "специальным" модулем (вторая ссылка).

Модули описываются как что-то, что выполняется для каждого запроса и что у обработчика есть сопоставление, которое указывает, когда оно должно выполняться (например, HTTP GET для *.aspx) (вторая и первая ссылки). Кроме того, для модулей exec_request_handler [который я принимаю как точку, в которой выполняется обработчик фактически) приходит после нескольких этапов конвейера (после begin_request, аутентификации, авторизации и т.д.), Это означает, что есть шаг, который происходит прежде всего, что устанавливает, что запрос предназначен для управляемого обработчика, чтобы отключить выполнение модулей, которые имеют preCondition = "managedHanlder", когда запрос не предназначен для управляемого обработчика.

Я чувствую, что здесь что-то не хватает, может кто-то пролить свет на то, как точно работает preCondition = "managedHandler"?

4b9b3361

Ответ 1

Из этого сообщения в блоге (http://blogs.iis.net/thomad/archive/2006/11/04/precondition-what.aspx):

Предварительное условие ManagedHandler

IIS 7.0 представляет новую управляемую модель расширяемости. Обработчики и модули теперь могут быть записаны в управляемый код и непосредственно интегрированный в конвейер запросов IIS. Но переключение между управляемым и внутренним кодом является дорогостоящим операция. Предварительное условие managedHandler было введено для оптимизация производительности запросов, в которых не требуется быть вовлеченным, например, когда статические файлы (.html,.jpg и т.д.) являются служил. Управляемый код не вызывается, если запрос обслуживается обработчик и каждый управляемый модуль настроены с помощью управляемого Handler Предпосылка. Практический сценарий - это проверка подлинности форм. управляемый модуль аутентификации Forms имеет предварительное условие managedHandler и поэтому вызывается только при использовании страниц ASP.NET(например, *.aspx) запрашиваются. Если запрашивается страница .html, проверка подлинности форм не называется. Если вы хотите защитить весь свой контент формами аутентификации вы можете просто удалить предварительное условие managedHandler из записи модуля аутентификации форм.

Короче говоря, если запрос может обслуживаться встроенным модулем IIS (скажем, образ, например), ему не придется проходить через весь управляемый конвейер (например, все события "global.asax" и даже больше), что приводит к огромному приросту производительности.

РЕДАКТИРОВАТЬ: Фактический ответ на ваш вопрос: сопоставления обработчиков. Это то, что связывает расширение файла с конкретным обработчиком. Ниже вы найдете, как редактировать эти сопоставления в II7. Вы также можете найти дополнительную информацию о сопоставлении обработчика здесь.

open this section in IIS

Then you will see all the registered mappings