Переопределение URL-адресов IIS и маршрутизация ASP.NET

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

После выпуска модуля переопределения URL-адресов для IIS и включения маршрутизации ASP.NET в платформа .NET Framework 4 у разработчиков ASP.NET появилось много вопросов о том, как эти две функции связаны друг с другом и когда следует использовать ту или иную. В этом документе описываются различия между этими двумя технологиями и приводятся рекомендации для веб-разработчиков о том, когда следует использовать перезапись URL-адресов IIS, а когда — ASP.NET маршрутизации.

С точки зрения высокого уровня, кажется, что эти технологии предоставляют очень похожие функциональные возможности— оба позволяют веб-приложениям иметь удобные и понятные для поисковых систем URL-адреса. Однако между этими двумя технологиями существуют фундаментальные различия, которые важно понимать, чтобы принять правильное решение о том, что использовать для веб-приложения. Чтобы помочь вам понять эти различия, мы сначала объясним, как работает перезапись URL-адресов IIS и ASP.NET маршрутизации.

Переопределение URL-адресов IIS

Основная идея перезаписи URL-адресов не является новой концепцией. Он был представлен на веб-сервере Apache около десяти лет назад. С тех пор он оказался очень полезным инструментом для администраторов веб-серверов и веб-разработчиков. Многие популярные приложения, размещенные в Apache, теперь используют перезапись URL-адресов, чтобы обеспечить поддержку "чистых" URL-адресов.

Концепция перезаписи URL-адресов проста. Когда клиент отправляет запрос на веб-сервер для определенного URL-адреса, модуль переопределения URL-адресов анализирует запрошенный URL-адрес и изменяет его на другой URL-адрес на том же сервере. Модуль переопределения URL-адресов запускается на ранних этапах конвейера обработки запросов, изменяя запрошенный URL-адрес, прежде чем веб-сервер решит, какой обработчик будет использоваться для обработки запроса. Обработчик, выбранный на основе переопределенного URL-адреса, обрабатывает запрос и создает ответ, который отправляется обратно в веб-браузер. Запрашивающий клиент никогда не видит перезаписанный URL-адрес; что касается клиента, он получил ответ от исходного URL-адреса.

С точки зрения архитектуры IIS этот процесс представлен на следующей схеме:

Схема процесса перезаписи I I S U R L от запроса H T T P к ответу H T T P.

Модуль переопределения URL-адресов — это модуль машинного кода, который подключается к конвейеру обработки запросов на этапах "Предварительный запрос" или "Начать запрос", а затем оценивает запрошенный URL-путь с помощью набора правил перезаписи. Каждое правило перезаписи анализирует путь URL-адреса и при соблюдении всех условий правила изменяет исходный путь на новый. После оценки всех правил модуль переопределения URL-адресов создает окончательный путь URL-адреса, который используется для запроса в оставшейся части обработки конвейера IIS. Это означает, что выбор обработчика в конвейере IIS выполняется на основе переопределенного URL-адреса, созданного модулем переопределения URL-адресов.

Маршрутизация ASP.NET

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

С точки зрения архитектуры IIS и ASP.NET этот процесс представлен на следующей схеме:

Схема процесса маршрутизации AS P DOT NET с использованием обработчиков I H T T P от запроса к ответу.

ASP.NET маршрутизация реализуется как модуль управляемого кода, который подключается к конвейеру обработки запросов IIS на этапе разрешения кэша (событие PostResolveRequestCache) и на этапе обработчика карты (событие PostMapRequestHandler). ASP.NET маршрутизация настроена для выполнения всех запросов к веб-приложению.

Во время события PostResolveRequestCache модуль просматривает таблицу маршрутизации (коллекцию объектов маршрута) на наличие маршрута, соответствующего запрошенным URL-пути. При обнаружении совпадения модуль получает ссылку на обработчик, соответствующий данному маршруту, и сохраняет ссылку как часть текущего контекста HTTP. Обработчиком может быть любой объект платформа .NET Framework, реализующий интерфейс System.Web.IHttpHandler. Если маршрут не найден, модуль ничего не делает, а URL-адрес проходит и обрабатывается обычным образом (обычно путем сопоставления с файлом на диске).

Во время события PostMapRequestHandler модуль проверяет, содержит ли контекст HTTP какие-либо сведения о обработчике. Если это так, ASP.NET маршрутизация использует сведения для задания свойства Handler текущего контекста HTTP. Это гарантирует, что на этапе Выполнения обработчика службы IIS будут выполнять обработчик, выбранный модулем маршрутизации. Если эти сведения не заданы, модуль ничего не делает, и URL-адрес не выполняется, чтобы iis сделали выбор обработчика.

Различия между переопределением URL-адресов IIS и маршрутизацией ASP.NET

На основе приведенного выше объяснения существуют следующие main концептуальные различия между переопределением URL-адресов IIS и маршрутизацией ASP.NET:

  1. Переопределение URL-адресов используется для управления путями URL-адресов перед обработкой запроса веб-сервером. Модуль переопределения URL-адресов не знает, какой обработчик в конечном итоге обработает перезаписанный URL-адрес. Кроме того, фактический обработчик запросов может не знать, что URL-адрес был перезаписан.
  2. ASP.NET маршрутизация используется для отправки запроса обработчику на основе запрошенного URL-пути. В отличие от перезаписи URL-адресов, модуль маршрутизации знает об обработчиках и выбирает обработчик, который должен создать ответ для запрошенного URL-адреса. Маршрутизацию ASP.NET можно рассматривать как расширенный механизм сопоставления обработчиков.

Помимо этих концептуальных различий существуют следующие функциональные различия между переопределением URL-адресов IIS и маршрутизацией ASP.NET:

  1. Модуль переопределения URL-адресов IIS можно использовать с веб-приложением любого типа, включая ASP.NET, PHP, ASP и статические файлы. ASP.NET маршрутизацию можно использовать только с веб-приложениями на основе платформа .NET Framework.
  2. Модуль переопределения URL-адресов IIS работает одинаково, независимо от того, используется ли для пула приложений режим конвейера IIS : интегрированный или классический. Для ASP.NET маршрутизации предпочтительнее использовать режим интегрированного конвейера. ASP.NET маршрутизация может работать в классическом режиме, но в этом случае URL-адреса приложения должны содержать расширения имен файлов или приложение должно быть настроено для использования сопоставления обработчика "*" в IIS.
  3. Модуль переопределения URL-адресов IIS может принимать решения о перезаписи на основе доменных имен, заголовков HTTP и переменных сервера. По умолчанию маршрутизация ASP.NET работает только с URL-путями и заголовком HTTP-Method.
  4. Помимо перезаписи, модуль переопределения URL-адресов может выполнять перенаправление HTTP, выдавать пользовательские коды состояния и прерывать запросы. ASP.NET маршрутизация не выполняет эти задачи.
  5. Модуль переопределения URL-адресов не является расширяемым в текущей версии. ASP.NET маршрутизация полностью расширяема и настраивается.

Какой вариант следует использовать?

Что означают все эти сведения, если вам нужно выбрать технологию для включения чистых URL-адресов для веб-приложений? В этом разделе мы объясним, как сделать этот выбор.

Если веб-приложение создано с помощью чего-либо, кроме ASP.NET, используйте модуль переопределения URL-адресов IIS. В противном случае используются следующие правила:

  1. Если вы разрабатываете новое веб-приложение ASP.NET, использующее ASP.NET MVC или технологии ASP.NET динамических данных , используйте маршрутизацию ASP.NET. Ваше приложение будет использовать встроенную поддержку чистых URL-адресов, включая создание чистых URL-адресов для ссылок на веб-страницах. Обратите внимание, что ASP.NET маршрутизация пока не поддерживает стандартные приложения веб-формы, хотя планируется поддержка в будущем.
  2. Если у вас уже есть устаревшая ASP.NET веб-приложение и вы не хотите его изменять, используйте модуль Переопределение URL-адресов. Модуль переопределения URL-адресов позволяет преобразовать URL-адреса, понятные для поисковых систем, в формат, который в настоящее время используется приложением. Кроме того, он позволяет создавать правила перенаправления, которые можно использовать для перенаправления поисковых систем-обходчиков на очистку URL-адресов.

На практике, однако, выбор не обязательно должен быть либо /или. Эти технологии можно использовать вместе и дополнять друг друга. В следующих разделах описаны некоторые сценарии, в которых можно совместно использовать маршрутизацию ASP.NET и перезапись URL-адресов IIS.

Применение канонических URL-адресов для приложения.
Следует принудительно использовать http://www.mysite.com/home/about вместо http://mysite.com/Home/About. Когда веб-клиент запрашивает URL-адрес, который не соответствует нужному формату, клиент перенаправляется на канонический URL-адрес. В этом сценарии можно использовать модуль переопределения URL-адресов для принудительного применения канонических URL-адресов и выполнения перенаправления, а также использовать маршрутизацию ASP.NET для выбора обработчика, который будет обрабатывать запрошенный путь URL-адреса.

В следующем примере показано правило переопределения URL-адресов, которое можно использовать в этом сценарии:

<rewrite>
    <rules>
        <rule name="Enforce canonical hostname" stopProcessing="true">
            <match url="(.*)" />
            <conditions>
                <add input="{HTTP_HOST}" negate="true" pattern="^www\.mysite\.com$" />
            </conditions>
            <action type="Redirect" url="http://www.mysite.com/{R:1}" redirectType="Permanent" />
        </rule>
    </rules>
</rewrite>

Обслуживание статического содержимого с другого сайта или сервера.
Веб-приложение развертывается на нескольких серверах таким образом, что динамическое веб-содержимое размещается на одном сайте или сервере, а все статическое содержимое — на другом сайте или сервере. Модуль переопределения URL-адресов можно использовать вместе с модулем маршрутизации запросов приложений IIS , чтобы перенаправлять все запросы статических файлов на другой сервер, обслуживая при этом все запросы динамических веб-страниц с текущего сервера. Таким образом, ASP.NET маршрутизация используется только для динамического веб-содержимого и не оценивает URL-адреса для статического содержимого.

В следующем примере показано правило переопределения URL-адресов, которое можно использовать в этом сценарии:

<rewrite>
    <rules>
        <rule name="Forward to static file server">
            <match url="^.+\.(?:jpg|bmp|gif)$" />
            <action type="Rewrite" url="http://static_file_server/{R:0}" />
        </rule>
    </rules>
</rewrite>

Управление статическим содержимым.
При перемещении статических файлов или папок в новое расположение вы по-прежнему можете поддерживать старые URL-адреса из соображений обратной совместимости. На самом деле, возможно, вы не хотите, чтобы посетители веб-сайта знали, что файлы или папки были перемещены. В этом случае можно использовать модуль переопределения URL-адресов для перезаписи путей к статическим файлам, а все URL-адреса динамических веб-страниц ASP.NET обрабатываются модулем маршрутизации.

В следующем примере показано правило переопределения URL-адресов, которое можно использовать в этом сценарии:

<rewrite>
    <rules>
        <rule name="Rewrite to new folder">
            <match url="^Images/(.+)$" />
            <action type="Rewrite" url="NewImages/{R:1}" />
        </rule>
    </rules>
</rewrite>

Блокировка запросов.
Модуль Переопределения URL-адресов можно использовать для блокировки определенных запросов на основе различных критериев. Например, можно запретить определенным обходчикам сайта доступ к определенным URL-путям на веб-сайте. Таким образом, запрещенные запросы даже не пойдут на маршрутизатор ASP.NET, что снижает нагрузку на веб-сервер.

В следующем примере показано правило переопределения URL-адресов, которое можно использовать для блокировки нежелательных обходчиков сайтов. Обратите внимание, что запросы блокируются для определенного URL-пути на основе http-заголовка агента пользователя или IP-адреса клиента:

<rewrite>
    <rules>
        <rule name="Block SomeRobot" stopProcessing="true">
            <match url="^folder1/folder2" />
            <conditions logicalGrouping="MatchAny">
                <add input="{USER_AGENT}" pattern="SomeRobot" />
                <add input="{REMOTE_ADDR}" pattern="201\.45\.33\.[0-5]" />
            </conditions>
            <action type="AbortRequest" />
        </rule>
    </rules>
</rewrite>

Будущие направления

Несмотря на то, что перезапись URL-адресов IIS и маршрутизация ASP.NET имеют некоторое функциональное перекрытие, они предназначены для сценариев, уникальных для каждой технологии. Из-за этого эти две технологии будут по-прежнему существовать и развиваться как независимые компоненты в IIS с потенциалом для более тесной интеграции между ними. Например, ASP.NET маршрутизации можно использовать некоторые из расширенных средств, предоставляемых модулем переопределения URL-адресов. Модуль переопределения URL-адресов можно лучше интегрировать с ASP.NET с точки зрения расширения для настройки логики перезаписи URL-адресов.

Заключение

Для реализации сценариев обработки URL-адресов для веб-приложения можно использовать перезапись URL-адресов IIS или маршрутизацию ASP.NET. ASP.NET маршрутизация является решением, оптимизированным для ASP.NET, поэтому она может быть предпочтительнее для веб-разработчиков, которые проектируют свои ASP.NET приложения с нуля и хотят иметь чистую структуру URL-адресов. Перезапись URL-адресов IIS — это универсальный механизм обработки URL-адресов, который предназначен для множества сценариев. В частности, он может использоваться веб-разработчиками, а также администраторами веб-серверов и сайтов для включения очистки URL-адресов для существующих веб-приложений без изменения кода приложения.