URL Rewrite(2): Использование компонентов для перезаписи URL.
Автор:Eve Cole
Время обновления:2009-06-29 23:46:44
Принцип работы компонента URL Rewrite уровня asp.net очень прост. Фактически, он просто слушает событие BeginRequest и определяет целевой URL-адрес в соответствии с конфигурацией. В проектах, в которых я участвовал раньше, я обнаружил, что частота использования URLRewriter в качестве компонента URL Rewrite очень высока. Я думаю, это может быть связано с тем, что это что-то предоставленное Microsoft.
Если вы хотите использовать URLRewriter, первым естественным шагом будет настройка HttpModule в web.config:
<httpModules>
< добавить
name = " МодульРерайтер "
type = " URLRewriter.ModuleRewriter, URLRewriter " />
</httpМодули>
Затем пришло время настройки (Примечание: настоятельно рекомендуется использовать атрибут configPath для извлечения конфигурации в дополнительные файлы для упрощения управления):
<configSections>
< раздел
name = " RewriterConfig "
type = " URLRewriter.Config.RewriterConfigSerializerSectionHandler, URLRewriter " />
</configSections>
<RewriterConfig>
<Правила>
<RewriterRule>
< LookFor > ~/tag/([w]+)/ </ LookFor >
< SendTo > ~/Tags.aspx?Tag=$1 </ SendTo >
</RewriterRule>
</ Правила >
</RewriterConfig>
Регулярные выражения — удивительная вещь, их можно сопоставлять и фиксировать. В приведенном выше примере мы перемещаем «/tag/xxx», который соответствует условиям LookFor, на страницу Tags.aspx и используем xxx в качестве значения элемента Tag QueryString, чтобы можно было передать HttpContext.Request.QueryString в коде. . ["Тег"] для получения значения.
Функциональности URLRewriter достаточно для большинства приложений, но мне это всегда не нравилось. Но если вы спросите меня, почему мне это не нравится, я не смогу вам ответить, какой уродливый Иньмао. Возможно, это просто проблема с этим методом настройки. При использовании URL Rewriter раздел конфигурации часто бывает очень длинным. Для каждого элемента конфигурации требуется всего 4 строки кода от <RewriterRule> до </RewriterRule>. Небольшой проект может легко содержать сотни строк конфигурации. «Это слишком XML», — подумал я, — почему бы не использовать XML-атрибут? Это уменьшает каждый элемент конфигурации до 1 строки — но это отступление.
Поэтому, если я сейчас хочу перезаписать URL-адреса, я часто использую компонент с открытым исходным кодом UrlRewriter.NET, созданный Intelligencia . Хотя это имя очень похоже на предыдущее, его функциональность намного превосходит прежнее. Этот компонент относительно близок к используемому URLRewriter (на самом деле кажется, что все компоненты URL Rewrite похожи. Все, что нам нужно сделать, это настроить:
<configSections>
< раздел
name = " переписчик "
тип = " Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler ,
Intelligencia.UrlRewriter " />
</configSections>
<переписчик>
< переписать
url = " ^/User/(d+)$ "
to = " ~/User.aspx?id=$1 "
обработка = " остановить " />
< переписать
url = " ^/User/(w+)$ "
to = " ~/User.aspx?name=$1 "
обработка = " остановить " />
</рерайтер>
< система.web >
<httpModules>
< добавить
name = " URLRewriter "
тип = " Intelligencia.UrlRewriter.RewriterHttpModule,
Intelligencia.UrlRewriter " />
</httpМодули>
< /system.web >
Давайте главным образом посмотрим на элемент конфигурации <rewriter/> правил перезаписи. В отличие от URLRewriter, UrlRewriter.NET использует мой любимый метод: по одному узлу на правило, что значительно упрощает переписывание правил всего проекта. Но что означает обработка="stop"? Речь идет о том, как UrlRewriter.NET обрабатывает правила перезаписи. Когда UrlRewriter.NET обнаружит подходящее правило перезаписи, он не остановится на этом, а продолжит поиск других совпадений. Последнее правило перезаписи, которое может соответствовать текущему запросу, в конечном итоге вступит в силу. Если нам нужно, чтобы UrlRewriter.NET вступил в силу после обнаружения совпадения, нам нужно установить атрибут обработки на остановку. Например, в приведенной выше конфигурации, если за «/User/» следует число, для поиска будет использоваться идентификатор пользователя, в противном случае будет учитываться предоставленное в данный момент имя пользователя.
Если UrlRewriter.NET просто проще в настройке, у него нет никаких преимуществ перед URLRewriter. Но возможности UrlRewriter.NET выходят далеко за рамки этого. То, что мы только что использовали, на самом деле является лишь одним из предоставляемых им действий. Кроме того, он также предоставляет множество действий:
- if,
- если только
- перезапись
- перенаправления
- setstatus
не - запрещена
- ,
- не разрешена
- , не найдена,
- не реализована,
- addheader
- setcookie
- setproperty
. Одного действия UrlRewriter.NET также предоставляет функции «Условие», «Преобразование», «Документ по умолчанию», «Парсер», «Обработчик ошибок», «Регистратор» и другие функции, а также может передаваться. Выражение, «представляющее» сложную логику. Это не настройка, это просто программирование! Правильно, UrlRewriter.NET можно использовать для выражения некоторой логики запроса-ответа посредством конфигурации, что, несомненно, приносит нам большое удобство. Я не могу подробно объяснить здесь все аспекты UrlRewriter.NET. Заинтересованные друзья могут поближе познакомиться с справкой, представленной на его официальном сайте. «Если у вас есть такие компоненты, чего еще можно желать?» Однако я все же хочу порекомендовать здесь еще один компонент. Потому что в некоторых особых случаях UrlRewriter.NET не может удовлетворить наши требования. Эм? Разве он не может расширяться сам по себе? Это верно, но давайте сначала разберемся с этим, и я объясню этот вопрос в последней статье этой серии. UrlRewriter.NET обеспечивает переписывание URL-адресов на уровне ASP.NET. Если вы хотите выполнить перезапись URL-адресов на уровне IIS, вам необходимо использовать другие методы. ISAPI Rewrite — хорошо известный компонент для перезаписи URL-адресов на уровне IIS. К сожалению, это коммерческий компонент, и его необходимо приобрести за доллары США. Поэтому я рекомендую здесь еще один продукт с открытым исходным кодом: IIRF (Ionic's Isapi Rewrite Filter) .
Поскольку перезапись URL-адресов выполняется на уровне IIS, метод настройки IIRF отличается от метода UrlRewriter.NET. Если вы хотите использовать IIRF, вам необходимо добавить IsapiRewrite4.dll в список фильтров ISAPI веб-сайта:
IIRF настраивается через ini-файл IsapiRewrite4.ini, и IsapiRewrite4.dll можно разместить в одном каталоге:
RewriteRule ^/User/(d+)$ /User.aspx?id=$1 [I, L]
RewriteRule ^/User/(w+)$ /User.aspx?name=$1 [I, L]
Правило перезаписи IIRF: «RewriteRule <url-pattern> <destination> [<modifiers>]». Ограничений на количество пробелов между каждой частью нет, но это должен быть пробел, а не другие символы пробела, такие как Tab. . Само собой разумеется, «шаблон URL-адреса» и «назначение» — ключ кроется в модификаторе. Существует множество модификаторов для IIRF. Здесь я представлю только два, использованные выше. «I» означает, что сопоставление не зависит от регистра. Функция «L» аналогична обработке = «stop» в UrlRewriter.NET. IIRF вступит в силу сразу после обнаружения совпадения и не будет продолжать поиск.
Хотя IIRF является компонентом с открытым исходным кодом, его функции по-прежнему относительно мощны. Особенно после объединения RewriteCond (условия перезаписи) можно реализовать более сложные правила перезаписи. Например, следующая конфигурация перезаписывает запрос корневого каталога, содержащий слово Googlebot в UserAgent, на определенный ресурс:
RewriteCond %{HTTP_USER_AGENT} ^Googlebot.*
RewriteRule ^/ $/Googlebot.html [L]
Наконец, давайте посмотрим на разницу между двумя компонентами Rewrite. Очевидно, что самая большая разница заключается в том, что они перезаписываются на разных уровнях. На двух схематических диаграммах ниже показано, как в двух случаях они изменяют «/User/jeffz», который должен был получить результат «404 Ресурс не найден». "/User/name=jeffz".
Первый — это перезапись URL-адресов с помощью UrlRewriter.NET на уровне ASP.NET:
Далее идет перезапись URL-адресов IIRF на уровне IIS:
Я считаю, что с этими двумя компонентами нам больше ничего не нужно для реализации перезаписи URL-адресов.