Использование трассировки неудачных запросов для трассировки правил переписывания

Руслан Якушев

IIS 7.0 и более поздних версий трассировки неудачных запросов (FRT) — это мощный инструмент для устранения сбоев обработки запросов. FRT можно использовать с модулем перезаписи URL-адресов для трассировки применения правил перезаписи к URL-адресу запроса. В этом пошаговом руководстве описано, как использовать FRT для устранения неполадок и отладки правил перезаписи URL-адресов. Дополнительные сведения о Трассировке неудачных запросов (FRT) см. в этой статье.

Необходимые условия

В этом пошаговом руководстве требуются следующие предварительные требования:

  1. Службы IIS версии 7.0 или выше с включёнными ролевыми службами ASP.NET и «Трассировка»
  2. Установлена версия перезаписи URL-адресов для выхода Go Live

Настройка тестовой веб-страницы

Чтобы продемонстрировать, как работает модуль перезаписи URL-адресов, мы будем использовать простую тестовую ASP.NET страницу. Эта страница считывает переменные веб-сервера и выводит их значения в браузере.

Скопируйте следующий код ASP.NET и поместите его в папку %SystemDrive%\inetpub\wwwroot\ в файл с именем article.aspx:

<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>URL Rewrite Module Test</title>
</head>
<body>
      <h1>URL Rewrite Module Test Page</h1>
      <table>
            <tr>
                  <th>Server Variable</th>
                  <th>Value</th>
            </tr>
            <tr>
                  <td>Original URL: </td>
                  <td><%= Request.ServerVariables["HTTP_X_ORIGINAL_URL"] %></td>
            </tr>
            <tr>
                  <td>Final URL: </td>
                  <td><%= Request.ServerVariables["SCRIPT_NAME"] + "?" + Request.ServerVariables["QUERY_STRING"] %></td>
            </tr>
      </table>
</body>
</html>

После копирования этого файла перейдите к http://localhost/article.aspx, затем проверьте правильность отображения страницы в браузере.

Снимок экрана: доступ к странице статьи через веб-браузер.

Настройка правил перезаписи

Найдите файл web.config в %SystemDrive%\inetpub\wwwroot\ папке или создайте его, если он не существует. Откройте файл web.config и добавьте следующий раздел в <system.webServer> элемент:

<rewrite>
      <rules>
        <rule name="Fail bad requests">
          <match url="." />
          <conditions>
            <add input="{HTTP_HOST}" negate="true" pattern="localhost" />
          </conditions>
          <action type="AbortRequest" />
        </rule>
        <rule name="Rewrite to article.aspx">
          <match url="^article/([0-9]+)/([_0-9a-z-]+)" />
          <action type="Rewrite" url="article.aspx?id={R:1}&amp;title={R:2}" />
        </rule>
      </rules>
</rewrite>
  • Правило "Неудачные запросы" прерывает HTTP-подключение, если заголовок узла HTTP-запроса не соответствует localhost.
  • Правило перезаписи в article.aspx" перезаписывает URL-адреса из этого формата http://localhost/article/234/some-title в этот формат http://localhost/article.aspx?id=234&title=some-title.

Убедитесь, что правила настроены правильно, открыв браузер и выполнив запрос http://localhost/article/234/some-title. Если правила настроены правильно, в браузере должен появиться следующий ответ:

Снимок экрана: страница тестового теста модуля переопределения U R L, отображающая исходную версию U R L и версию перезаписи.

Настройка трассировки неудачных запросов

Теперь включите трассировку неудачных запросов для «веб-сайта по умолчанию» (см. в этой статье для пошаговых инструкций по включению FRT). После включения трассировки неудачных запросов мы создадим правило FRT для событий трассировки, относящихся к модулю перезаписи URL-адресов.

Чтобы создать правило FRT в диспетчере IIS, выполните следующие действия.

  1. Щелкните значок "Правила трассировки неудачных запросов", чтобы перейти к списку правил FRT.
    Снимок экрана панели 'Домашняя страница веб-сайта по умолчанию' с выбранными правилами трассировки неудачных запросов.
  2. Нажмите на действие "Добавить...", чтобы открыть мастер создания правила FRT. Снимок экрана: диалоговое окно
  3. На первой странице мастера выберите пункт "Все содержимое (*)"
  4. Нажмите кнопку "Далее" и укажите код состояния как "200-399"
    Скриншот настройки кодов состояния на значение от 200 до 399.
  5. Нажмите "Далее", затем снимите флажки со всех поставщиков трассировки, кроме "WWW Server", и снимите флажки со всех областей поставщика, кроме "Перезапись". Снимок экрана, на котором указаны только WWW Server и области только для Перезаписи.
  6. Нажмите кнопку "Готово", чтобы сохранить правило FRT.

Если трассировка неудачных запросов была установлена после модуля перезаписи URL-адресов, область "Перезапись" в разделе поставщиков трассировки может быть недоступна. Если вы не видите область перезаписи, перейдите в раздел "Добавить и удалить программы", а затем запустите установщик модуля перезаписи URL-адресов в режиме восстановления.

Анализ файла журнала трассировки неудачных запросов

После создания правила FRT выполните запрос http://localhost/article/234/some-title. При этом будет создан вход %SystemDrive%\inetpub\Logs\FailedReqLogFiles\FRT. Этот журнал можно открыть с помощью Internet Explorer, и он будет отображаться в виде HTML-документа, который можно легко просматривать. Ниже приведен пример событий перезаписи URL-адреса, которые можно найти в файле журнала трассировки:

Снимок экрана: доступ к журналу F R T с помощью веб-браузера. В журнале отображается список правил перезаписи и их логика перезаписи.

Эти события показывают, как были оценены правила перезаписи и как запрошенный URL-адрес был изменен модулем перезаписи. Давайте рассмотрим некоторые события, чтобы лучше понять логику оценки правила:

URL_REWRITE_START . Это событие указывает начало событий перезаписи URL-адресов. Свойства события предоставляют следующие сведения:

  • Строка входного URL-адреса — "/article/234/some-title".
  • Не было строки запроса.
  • Scope="Distributed" указывает, что правила являются локальными (т. е. правила определены в Web.config для сайта) в отличие от глобальных (то есть определенных на уровне сервера).

RULE_EVALUATION_START — это событие указывает начало логики оценки правила. Свойства события содержат следующие сведения:

  • Правило использует регулярные выражения для синтаксиса шаблона (patternSyntax="ECMAScript")
  • Последующие правила будут оцениваться (StopProcessing = false)
  • Правило определяется на корневом уровне сайта (RelativePath = "/")

PATTERN_MATCH . Это событие содержит сведения о том, как URL-адрес был сопоставлен с шаблоном правила. Свойства события предоставляют следующие сведения:

  • Шаблон правила — "." (то есть соответствует любому символу)
  • Вводный URL успешно соответствует шаблону.

CONDITIONS_EVALUATION_START - Поскольку входной URL-адрес соответствовал шаблону, началась оценка условий.

CONDITION_EVALUATION . Это событие содержит следующие сведения:

  • Значение HTTP_HOST было "localhost" и соответствовало шаблону.
  • Так как условие отрицания было указано в правиле (т. е. Negated="true") оценка условия не завершилась успешно.

CONDITIONS_EVALUATION_END . Это событие показывает, что оценка условий для этого правила не завершилась успешно

RULE_EVALUATION_END . Это событие показывает, что правило не изменяет URL-адрес (Succeeded="false"). Это связано с ошибкой оценки условия правила.

RULE_EVALUATION_START . Это даже показывает, что строка URL-адреса была передана второму правилу

PATTERN_MATCH . Это событие содержит сведения о том, как URL-адрес был сопоставлен с шаблоном правила. Свойства события говорят нам, что:

  • Шаблон правила: "^article/([0-9]+)/([0-9a-z]+)"
  • Входной URL-адрес соответствует шаблону успешно

REWRITE_ACTION . Это событие указывает, что оценка правила выполнена успешно, и URL-адрес был перезаписан на "/article.aspx" со строкой запроса "id=234&title=some-title"

Сводка

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

  • Last updated on