В предыдущих статьях мы говорили о нескольких основных аспектах перезаписи URL. В последней статье этой серии мы обсудим некоторые детали и характеристики различных уровней перезаписи URL-адресов.
Теоретически перезапись URL-адресов на уровне IIS, написанная на C или C++, имеет более высокую производительность, чем перезапись URL-адресов на уровне ASP.NET, написанная в управляемом коде. Но я думаю, что разница в этой области в большинстве случаев незначительна, и практически невозможно, чтобы эта производительность стала узким местом производительности. Таким образом, выбранный уровень перезаписи URL-адресов обычно не определяется требованиями к производительности вашего приложения. Итак, какой уровень перезаписи URL-адресов следует использовать? На что следует обратить внимание после использования различных уровней перезаписи URL-адресов? Я здесь, чтобы рассказать о своих личных взглядах.
Хотя текущий компонент перезаписи URL-адресов может соответствовать большинству приложений с точки зрения функциональности, в какой-то момент нам все же потребуются некоторые специальные функции. Например, перезапись URL-адресов на основе имени домена нелегко осуществить с помощью текущего компонента перезаписи URL-адресов. Коммерческая версия ISAPI Rewrite в настоящее время может это поддерживать. К сожалению, UrlRewriter.NET и IIRF с открытым исходным кодом не имеют достаточных функций в этом отношении. Все они сопоставляются на основе пути запроса относительно сайта, а запрошенное доменное имя не может использоваться в качестве условия сопоставления. Это требует от нас расширения компонента URL Rewrite. Для большинства разработчиков .NET управляемый код, естественно, является первым выбором для разработки. В настоящее время может возникнуть необходимость выбрать компонент перезаписи URL-адресов уровня ASP.NET. Однако в Интернете можно найти множество примеров расширений, будь то UrlRewriter.NET на уровне ASP.NET или IIRF на уровне IIS.
Но на самом деле, если мы хотим достичь вышеуказанных функций, мы также можем сделать это в два этапа. Сначала мы используем IIRF для перезаписи URL-адресов на уровне IIS, а затем далее переписываем URL-адреса на уровне ASP.NET. Например, если теперь мы хотим переписать « http://jeffz.domain.com/articles » на «/ArticleList.aspx?owner=jeffz», мы можем сначала позволить IIRF выполнить первую перезапись URL-адреса с целью перезаписи «/articles» перезаписывается на «/ArticleList.aspx».
RewriteRule ^/Articles$ /ArticleList.aspx [I, L, U]
Таким образом, подсистема ASP.NET напрямую получит запрос на /ArticleList.aspx. Затем внутри ASP.NET мы можем сделать второй URL Rewrite (для удобства я все равно пишу его в Global.asax, а в проекте рекомендуется использовать дополнительный HttpModule).
protected void Application_BeginRequest (отправитель объекта , EventArgs e)
{
Контекст HttpContext = HttpContext .Current;
строка хоста = context.Request.Url.Host;
владелец строки = хост.Подстрока(0, хост.IndexOf( '.' ));
context.RewritePath(context.Request.RawUrl + "?owner=" + владелец);
}
После двух перезаписей URL-адресов желаемый эффект был достигнут (в реальных проектах приведенный выше код нельзя использовать напрямую, поскольку необходимо оценить, существует ли строка запроса и т. д.).
Кроме того, перезапись URL-адресов на уровне ASP.NET может работать только в ASP.NET (очевидно). Если вы хотите, чтобы перезапись URL-адресов поддерживала другие серверные технологии, такие как PHP, RoR и т. д., вы можете использовать только перезапись URL-адресов на уровне IIS. (или другая функция перезаписи URL-адресов, предоставляемая серверной технологией).
Некоторым специальным символам не разрешено появляться в URL-адресах. Если они появятся в URL-адресах, значение запроса изменится. Например, нам нужно выполнить перезапись URL-адреса на странице поиска, переписать «/Search/xxx» на «/Search.aspx?xxx», а затем получить ключевые слова, предоставленные пользователем, на основе строки после вопросительного знака. При использовании UrlRewriter.NET мы будем использовать следующую
конфигурацию : <rewriter>
< переписать URL = " ^/Search/(.+)$ " to = " ~/Search.aspx?$1 " обработка = " остановить " />
</ rewriter >
В обычных обстоятельствах перезапись URL-адресов работает нормально. Но если пользователь использует «%» в качестве ключевого слова, ситуация другая, потому что мы получим следующее приглашение на странице с ошибкой:
Это связано с тем, что в URL-адресе нельзя использовать «%». Вы можете зайти на различные веб-сайты и попытаться запросить некоторые пути, например «ABC%25DEF» («%25», за которым следует «%»), и большинство из них обнаружит ошибки «400 Bad Request». Однако допустимо помещать «%» в строку запроса — да, разве мы не переписали ключевое слово в строку запроса? Почему это все еще не работает? Это также определяется способом выполнения ASP.NET.
Неверный запрос определяется на этапе 3 приведенного выше рисунка, то есть пока он еще инициализируется. Перезапись URL-адреса происходит только в событии BeginRequest на шаге 4. Если запрос содержит недопустимые символы, у нас вообще нет возможности выполнить перезапись URL.
Так как же нам справиться с этой проблемой? В обычных обстоятельствах не будет большой проблемы, если мы удалим % на клиенте (некоторые сайты так делают), но что, если нам придется его оставить? Затем используйте строку запроса для передачи параметров или мы также можем использовать перезапись URL-адреса уровня IIS. Все еще принимая IIRF в качестве примера:
RewriteRule ^/Search/(.+)$ /Search.aspx?$1 [I, L, U]
Когда запрос отправляется в IIS (шаг 1) и после выбора ISAPI, который должен быть передан готов к выполнению (шаг 2) Перезапись URL-адреса произошла раньше. После перезаписи URL-адреса «%» в адресе был перенесен в строку запроса, и это, естественно, допустимо, когда он передается ASP.NET для обработки.
Наконец, давайте обсудим настройку страницы ошибок. Например, обычно мы настраиваем для приложения страницу ошибки 404, чтобы при доступе пользователя к несуществующему ресурсу мы могли показывать ему конкретную страницу вместо приглашения об ошибке по умолчанию. Но на этом этапе разные уровни перезаписи URL-адресов должны быть настроены с использованием разных методов.
Если мы используем перезапись URL-адресов на уровне ASP.NET, вообще говоря, мы настроили сопоставление подстановочных знаков в IIS, так что любой запрос (включая html, jpg и т. д.) будет обрабатываться ASP.NET. Если запрашивается несуществующий ресурс, ASP.NET выдает ошибку 404, поэтому страницу ошибки 404 следует настроить в web.config:
< customErrors режим = « Вкл .» defaultRedirect = " GenericErrorPage.htm " >
< ошибка Кодстатуса = " 404 " перенаправление = " FileNotFound.htm " />
</ customErrors >
Если мы используем перезапись URL-адресов на уровне IIS, мы не будем настраивать сопоставление подстановочных знаков. Другими словами, механизм ASP.NET начнет работать только в том случае, если адрес после перезаписи будет aspx (или другие вещи, которые должны были обрабатываться ASP.NET ISAPI). Если пользователь запрашивает несуществующий ресурс, IIS выдаст ошибку 404. В это время страница ошибки 404 должна быть настроена в IIS:
До сих пор обсуждалась тема URL Rewrite. В реальной разработке вы обязательно столкнетесь с различными ситуациями, но если вы понимаете суть метода URL Rewrite и думаете в соответствии с тем, как работает программа, я считаю, что, как правило, вы не столкнетесь с трудными проблемами.