none
Фильтры isapi и IIS 8(.5) RRS feed

  • Вопрос

  • В руководстве по IIS 7 в части использования isapi фильтров сказано, что isapi фильтры заменяются модулями, но еще можно их использовать.

    Ситуация с IIS 8 похоже складывается еще хуже - фильтры стали отрабатывать ПОСЛЕ модулей... Кто-нибудь обладает информацией по приоритетам отработки фильтров и модулей в IIS 8 ?

    В качестве примера могу привести следующую информацию по своему проекту.

    Последовательность отработки (так было на iis 6):

    1. isapi-фильтр (isapi_rewrite) - дописывает оконечный слеш к url сайта

    2. Модуль использует преобразование seo-урла во внутренние адреса страниц сайта.

    site.com/guide/news/ -> site.com/news.aspx?param=number

    В реальности (после перехода на iis 8.5)

    1. Модуль использует преобразование seo-урла во внутренние адреса страниц сайта

    2. isapi-фильтр пропускает страницы сайта, так как не имеет правил для их обработки, а только правила для seo-url-ов.

    Как можно и можно ли управлять приоритетами модуль <-> isapi-фильтр  в части сервер, сайт ?


    Disadvantages can be eliminated, but where to bury dissatisfied


    • Изменено Toologic 22 мая 2014 г. 10:58

Ответы

Все ответы

  • В IIS, начиная с 7, isapi фильтры вызываются через модули. Настраивается в IIS Manager -> <Server> -> Modules -> View Ordered List. Но реальный порядок зависит еще зависит от того, на какой стадии находится запрос в конвеере. Возможнные варианты:

    BEGIN_REQUEST
    AUTHENTICATE_REQUEST
    AUTHORIZE_REQUEST
    RESOLVE_REQUEST_CACHE
    MAP_REQUEST_HANDLER
    ACQUIRE_REQUEST_STATE
    PRE_EXECUTE_REQUEST_HANDLER
    EXECUTE_REQUEST_HANDLER
    RELEASE_REQUEST_STATE
    UPDATE_REQUEST_CACHE
    LOG_REQUEST
    END_REQUEST

    Т.е. если один из модулей отрабатывает на этапе AUTHENTICATE_REQUEST, а другой на этапе LOG_REQUEST, то даже если в View Ordered List вы поставите второй раньше первого - смысла не будет. Сортировать имеет смысл только те модули, которые отрабатывают в рамках одной стадии. Увидеть это наглядно можно, включив Failed Request tracing.

    Забыл сказать, что модули могу сами выставить приоритет. Т.е. если в пределах одной стадии есть модули с разными приоритетами, то выполняться первым будет тот, у кого приоритет выше, даже если в списке он стоит ниже. Если приоритеты одинаковые, то учитывается порядок, в котором они расположены.


  • Не совсем понятно, как можно ISAPI фильтр (\Helicon\ISAPI_Rewrite3\ISAPI_Rewrite.dll) настроить через Модули.

    Мне кажется, скорее, что проблема в том, что в приложении сайта режим обработки запросов в новой конфигурации выставлен в "Интергированный", в котором ASP.NET не связана с модулями isapi или расширениями isapi.

    Перевод приложения в "классический" режим, при котором http запросы сначала обрабатываются isapi, а затем передаются в asp.net приводит к конфликту с модулями, которые могут работать только в интегрированном режиме...

    Как правильно скомбинировать (настроить) данную конфигурацию - вот вопрос всех вопросов.


    Disadvantages can be eliminated, but where to bury dissatisfied

  • Прослойка, которая запускает isapi фильтры реализована через модули. В любом случае все зависит от того, в какой момент что срабатывает, смотрите Failed request tracing, а там уже принимайте решение. И да, смена режима работы может быть причиной.

    О каких модулях идет речь? Что-то стандартное или сами дописывали?

  • 1. Таким образом можно попробовать "поднять" приоритет выполнения модуля isapi-filters ?

    2. Используются 2 библиотеки. Helicon ISAPI Rewrite 3 в качестве isapi фильтра и Masquerade от компании QuantumArt (сайт использует CMS Quantum Publishing) в качестве модуля преобразователя урл-ов.

    3. К сожалению, не получается перевести приложение в "классический" режим - masquerade не отрабатывает.

    Могли бы мы связаться лично?


    Disadvantages can be eliminated, but where to bury dissatisfied

  • А заменить ISAPI Rewrite на URL Rewrite не пробовали? Я с CMS Quantum Publishing не знаком, но похоже продукт достаточно современный и никогда не работал на iis6, по крайней мере текущая версия. Может проще отказаться от ISAPI?

    По поводу приоритетов, то никак. Все, что мы можем это менять порядок модулей в списке, но это не гарантирует, что оно выполнится раньше.

  • Вот трассировка последовательностей запросов

    2.
    -PRE_BEGIN_REQUEST_START
    ModuleName DynamicIpRestrictionModule
    DynamicIpRestrictionModule 0
    4.
    -PRE_BEGIN_REQUEST_START
    ModuleName FailedRequestsTracingModule
    FailedRequestsTracingModule 0
    6.
    -PRE_BEGIN_REQUEST_START
    ModuleName RequestMonitorModule
    RequestMonitorModule 0
    8.
    -PRE_BEGIN_REQUEST_START
    ModuleName IsapiFilterModule
    IsapiFilterModule 0
    22.
    -NOTIFY_MODULE_START
    ModuleName IsapiFilterModule
    Notification MAP_PATH
    fIsPostNotification false
    IsapiFilterModule MAP_PATH 0
    24.
    -NOTIFY_MODULE_START
    ModuleName HttpCacheModule
    Notification BEGIN_REQUEST
    fIsPostNotification false
    HttpCacheModule BEGIN_REQUEST 0
    26.
    -NOTIFY_MODULE_START
    ModuleName IpRestrictionModule
    Notification BEGIN_REQUEST
    fIsPostNotification false
    IpRestrictionModule BEGIN_REQUEST 0
    28.
    -NOTIFY_MODULE_START
    ModuleName RequestFilteringModule
    Notification BEGIN_REQUEST
    fIsPostNotification false
    RequestFilteringModule BEGIN_REQUEST 0
    30.
    -NOTIFY_MODULE_START
    ModuleName FailedRequestsTracingModule
    Notification BEGIN_REQUEST
    fIsPostNotification false
    FailedRequestsTracingModule BEGIN_REQUEST 0
    32.
    -NOTIFY_MODULE_START
    ModuleName ConfigurationValidationModule
    Notification BEGIN_REQUEST
    fIsPostNotification false
    ConfigurationValidationModule BEGIN_REQUEST 0
    34.
    -NOTIFY_MODULE_START
    ModuleName ApplicationInitializationModule
    Notification BEGIN_REQUEST
    fIsPostNotification false
    ApplicationInitializationModule BEGIN_REQUEST 0
    36.
    -NOTIFY_MODULE_START
    ModuleName UrlRewriter
    Notification BEGIN_REQUEST
    fIsPostNotification false
    UrlRewriter BEGIN_REQUEST 0
    44.
    -NOTIFY_MODULE_START
    ModuleName Masquerade
    Notification BEGIN_REQUEST
    fIsPostNotification false
    Masquerade BEGIN_REQUEST 0
    48.
    -NOTIFY_MODULE_START
    ModuleName IsapiFilterModule
    Notification AUTHENTICATE_REQUEST
    fIsPostNotification false
    IsapiFilterModule AUTHENTICATE_REQUEST 0
    50. view trace -NOTIFY_MODULE_START
    ModuleName WindowsAuthenticationModule
    Notification AUTHENTICATE_REQUEST
    fIsPostNotification false
    WindowsAuthenticationModule AUTHENTICATE_REQUEST 0
    54.
    -NOTIFY_MODULE_START
    ModuleName BasicAuthenticationModule
    Notification AUTHENTICATE_REQUEST
    fIsPostNotification false





    AspNetFilterModule LOG_REQUEST

    А вот расшифровка 8 пункта

    8. -PRE_BEGIN_REQUEST_START
    ModuleName IsapiFilterModule 
    Informational
    9. -FILTER_PREPROC_HEADERS_START
    0 ms
    10. -FILTER_START
    FilterName C:\Program Files\Helicon\ISAPI_Rewrite3\ISAPI_Rewrite_x64.dll
    0 ms
    11. -FILTER_END
    NotificationStatus SF_STATUS_REQ_NEXT_NOTIFICATION
    0 ms
    12. -FILTER_START
    FilterName C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_filter.dll
    0 ms
    Verbose
    13. -GENERAL_SET_REQUEST_HEADER
    HeaderName AspFilterSessionId
    HeaderValue
    Replace true
    0 ms
    Informational
    14. -FILTER_SET_REQ_HEADER
    HeaderName AspFilterSessionId:
    HeaderValue
    0 ms
    15. -FILTER_END
    NotificationStatus SF_STATUS_REQ_NEXT_NOTIFICATION
    0 ms
    Informational
    16. -FILTER_PREPROC_HEADERS_END
    0 ms
    Verbose
    17. -PRE_BEGIN_REQUEST_END
    ModuleName IsapiFilterModule
    NotificationStatus NOTIFICATION_CONTINUE

    Как видно фильтр ISAPI_Rewrite.dll выполняется в свое время - тогда я совсем ничего не понимаю...


    Disadvantages can be eliminated, but where to bury dissatisfied


    • Изменено Toologic 22 мая 2014 г. 11:59
  • Либо он запускается и ничего не делает, либо что-то происходит далее. Например в пунктах 36 и 44 гораздо интересней, модуль UrlRewriter у вас уже есть, а следом за ним идет Masquerade. Поэтому вполне возможно, что UrlRewriter изменяет URL так, что Masquerade не отрабатывает корректно. Я бы рекомендовал вам  отказаться от ISAPI, скорей всего функционала UrlRewriter  будет достаточно. Либо отключите UrlRewriter  и попробуйте без него, если не сработает, то останется только вариант с переходом от ISAPI_Rewrite к UrlRewriter.
  • Решение пришло от разработчиков Helicon ISAPI_Rewrite_3

    Теперь все ясно. Вот решение - https://www.helicontech.com/isapi_rewri ... onType.htm
    Просто поставьте в httpd.conf 

    RewriteEngine on
    NotificationType=PREPROC_HEADERS

    Это меняет очередность отработки


    Disadvantages can be eliminated, but where to bury dissatisfied

    • Предложено в качестве ответа Vasily Larionov 22 мая 2014 г. 13:55
    • Помечено в качестве ответа Toologic 22 мая 2014 г. 13:59