IIS URL Rewrite Module 2 : 10 полезных советов
Это перевод оригинальной статьи 10 URL Rewriting Tips and Tricks
Эта статья содержит некоторые советы, которые могут оказаться полезными при решении задач, связанных с адресами URL на веб-сайтах. Каждый совет предлагает описание проблемы и пример решения с помощью URL Rewrite Module for IIS 7.0.
1. Добавление или удаление завершающего символа наклонной черты (слэша)
Многие веб-приложения используют виртуальные URL – это адреса, которые на самом деле не сопоставлены с реальными каталогами или файлами на сервере. Примером такого веб-приложения на ASP.NET MVC можно считать https://stackoverflow.com/questions/60857/modrewrite-equivalent-for-iis-7-0 на PHP примером может служить следующий адрес: https://ruslany.net/2008/11/url-rewrite-module-release-to-web/. Если вы запросите эти адреса с или без завершающего символа наклонной черты вы получите одну и ту же страницу. Это поведение вполне нормально для посетителей, но может создать проблему для поисковых систем или систем аналитики. Разные URL для одной страницы могут трактоваться такими системами как разные страницы, что в свою очередь может повлиять на ранг страницы и аналитические данные.
Эту проблему крайне легко исправить написав правило переопределения URL. Располагать или нет завершающий слэш в адресе – это больше дело вкуса, но сделав один выбор вы можете определить правило, которое всегда отображает URL в одном виде.
Правило для того чтобы всегда удалять завершающий слэш:
<rule name="Remove trailing slash" stopProcessing="true">
<match url="(.*)/$" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Redirect" redirectType="Permanent" url="{R:1}" />
</rule>
Правило для того чтобы всегда дополнять URL завершающим слэшем:
<rule name="Add trailing slash" stopProcessing="true">
<match url="(.*[^/])$" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Redirect" redirectType="Permanent" url="{R:1}/" />
</rule>
2. Приведение URL к нижнему регистру
Проблема похожая на проблему с завершающим слэшем возникает когда кто-нибудь ссылается на вашу страницу с разным регистром букв, например: https://ruslany.net/2008/07/IISNET-Uses-Url-Rewrite-Module/ вместо https://ruslany.net/2008/07/iisnet-uses-url-rewrite-module/. В этом случае поисковые и аналитические системы могут трактовать эти URL как разные страницы.
Для того чтобы исправить URL и привести все его символы в нижний регистр вы можете воспользоваться следующим правилом:
<rule name="Convert to lower case" stopProcessing="true">
<match url=".*[A-Z].*" ignoreCase="false" />
<action type="Redirect" url="{ToLower:{R:0}}" redirectType="Permanent" />
</rule>
3. Канонические имена сайтов
Очень часто одному сайту соответствуют несколько имен. Наиболее распространенный пример: https://www.yoursitename.com и https://yoursitename.com . Другой пример: вы можете изменить имя своего сайта на новое, но хотите чтобы посетители со старого имени переходили на новое.
Очень простой правило поможет решить эти задачи:
<rule name="Canonical Host Name" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" negate="true" pattern="^ruslany\.net$" />
</conditions>
<action type="Redirect" url="https://ruslany.net/{R:1}" redirectType="Permanent" />
</rule>
Для примера того, как работает это правило вы можете перейти по адресу https://www.ruslany.net/2008/10/aspnet-postbacks-and-url-rewriting/ и убедиться, что “www” убрано из имени сайта.
4. Перенаправление на HTTPS
Когда происходит обращение к сайту по HTTP, который требует соединение через HTTPS по защищенному каналу, сервер IIS вернет ошибку с кодом HTTP 403 (Unauthorized). Вы можете надеяться, что ваши посетители всегда будут вводить https в строку адреса. Однако, если вы хотите чтобы ваш сайт был более простым в посещении и более дружелюбным вы можете перенаправлять посетителей на правильный адрес, вместо того, чтобы сообщать им об ошибке. Типичный пример сайт http://www.paypal.com, если вы перейдете по этому адресу, то увидите, что ваш браузер перенаправил вас на https://www.paypal.com.
С помощью URL Rewrite Module вы можете легко решить эту задачу:
<rule name="Redirect to HTTPS" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="^OFF$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
</rule>
5. Возврат кода HTTP 503
Код возврата со статусом HTTP 503 означают, что сервер не может обработать запрос в данный момент в связи с проведением технических работ. Этот код говорит о том, что сайт не работает временно, так что поисковые системы получив этот код не будут индексировать сайт, а вернуться к нему позднее. Когда вы останавливаете пул приложения в IIS, сервер будет автоматически возвращать на все запросы ответ со статусом HTTP 503. Но что если вам не нужно останавливать весь сайт и вы хотите провести технические работы только в одном из разделов?
С помощью URL Rewrite Module вы можете создать правило, которое решает эту задачу:
<rule name="Return 503" stopProcessing="true">
<match url="^products/sale/.*" />
<action type="CustomResponse" statusCode="503"
subStatusCode="0"
statusReason="Site is unavailable"
statusDescription="Site is down for maintenance" />
</rule>
6. Предотвращение сторонних ссылок на изображения сайта (Image Hotlinking)
Сторонние ссылки на изображения сайта (Image Hotlinking) – это использование изображений с вашего сайта для отображения их на других ресурсах в интернете. Такое неконтролируемое использование изображений увеличивает нагрузку на канал передачи данных для вашего сайта. Кроме того, существуют другие проблемы с подобным использованием, например, права на копирование изображений.
С помощью URL Rewrite Module вы можете легко предотвратить несанкционированное использование изображений с вашего сайта:
<rule name="Prevent image hotlinking">
<match url=".*\.(gif|jpg|png)$"/>
<conditions>
<add input="{HTTP_REFERER}" pattern="^$" negate="true" />
<add input="{HTTP_REFERER}" pattern="^https://ruslany\.net/.*$" negate="true" />
</conditions>
<action type="Rewrite" url="/images/say_no_to_hotlinking.jpg" />
</rule>
Это правило будет перенаправлять все запросы со сторонних сайтов на специальное изображение расположенное по адресу /images/say_no_to_hotlinking.jpg.
7. Обратный прокси для другого сайта или сервера
Используя URL Rewrite Module вместе с Application Request Routing вы можете заставить работать IIS в режиме обратного прокси-сервера. Например, в можете захотеть опубликовать содержимое ресурса из локальной сети в интернет. Для того, чтобы это осуществить необходимо проделать несколько шагов:
Убедитесь, что переключатель Enable proxy включен в функции Application Request Routing в IIS Manager;
Добавьте следующее правило на сайт, который будет являться прокси-сервером и будет принимать запросы:
<rule name="Proxy">
<match url="(.*)" />
<action type="Rewrite" url="https://internalserver/{R:1}" />
</rule>
Обратите внимание на префикс “https://” в правиле. Употребление этого префикса говорит системе URL Rewrite о необходимости использовать механизм прокси вместо перезаписи адреса. Когда Rewrite-правило содержит URL с префиксом протокола, то URL Rewrite Module не осуществляет стандартную логику по перезаписыванию URL. Вместо этого, запрос будет перенаправлен в модуль Application Request Routing, который в свою очередь осуществит прокси-запрос на адрес указанный в правиле.
8. Обратный прокси и HTTPS
Правило в предыдущем совете всегда использует незащищенное соединение по HTTP. Однако часто необходимо сохранить возможность запросов по протоколу HTTPS. Это может быть достигнуто следующим правилом:
<rule name="Proxy">
<match url="(.*)" />
<conditions>
<add input="{CACHE_URL}" pattern="^(https?)://" />
</conditions>
<action type="Rewrite" url="{C:1}://internalserver/{R:1}" />
</rule>
9. Перезапись или перенаправление на основе параметров запроса
Следующее правило демонстрирует как два различных параметра запроса извлекаются из строки и используются в перезаписи URL:
<rule name="Query String Rewrite">
<match url="page\.asp$" />
<conditions>
<add input="{QUERY_STRING}" pattern="p1=(\d+)" />
<add input="##{C:1}##_{QUERY_STRING}" pattern="##([^#]+)##_.*p2=(\d+)" />
</conditions>
<action type="rewrite" url="newpage.aspx?param1={C:1}&amp;amp;param2={C:2}" appendQueryString="false"/>
</rule>
Согласно этому правилу запрос с параметрами page.asp?p2=321&p1=123 будет перезаписан как newpage.aspx?param1=123¶m2=321.
10. Как избежать перезаписи запросов для ресурсов ASP.NET
Приложения на основе ASP.NET часто создают запросы к файлу WebResources.axd для получения разных ресурсов. Однако такого файла на сервере не существует и все запросы к нему в ASP.NET обрабатываются динамически. Поэтому некоторые правила перезаписи адресов могут порушить приложение, перезаписав запрос к WebResources.axd.
Эта проблема может быть легко решена на основе простого добавления еще одного условия в правило:
<rule name="RewriteUserFriendlyURL1" stopProcessing="true">
<match url="^([^/]+)/?$" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
<!-- The following condition prevents rule from rewriting requests to .axd files -->
<add input="{URL}" negate="true" pattern="\.axd$" />
</conditions>
<action type="Rewrite" url="article.aspx?p={R:1}" />
</rule>