Справочник по конфигурации модуля переопределения URL-адресов
В этой статье представлен обзор модуля перезаписи URL-адресов и описаны основные понятия конфигурации, используемые модулем.
Общие сведения о функциях
Модуль переопределения URL-адресов перезаписывает URL-адреса запросов на простые, понятные для пользователя и поисковые системы, отображаемые пользователям или в веб-приложениях. Переопределение URL-адресов использует определенные правила для оценки и сопоставления URL-адреса запроса с адресом, определенным в правиле, прежде чем он обрабатывается веб-сервером IIS. Вы можете определить логику перезаписи URL-адресов, включающую регулярные выражения и дикие карта, и правила можно применять на основе URL-адреса запроса, заголовков HTTP и переменных сервера. Хотя основной целью модуля является перезапись URL-адресов запросов на более понятные URL-адреса, вы также можете использовать модуль для определения правил, выполняющих перенаправления, отправки пользовательских ответов или прерывания запросов.
Обзор правил перезаписи
Правило переопределения определяет логику сравнения или сопоставления URL-адреса запроса с и что делать, если сравнение выполнено успешно.
Правила перезаписи состоят из следующих частей:
- Шаблон — шаблон правила используется для указания регулярного выражения или дикого карта шаблона, используемого для сопоставления строк URL-адресов.
- Условия — коллекция необязательных условий используется для указания дополнительных логических операций для выполнения, если строка URL-адреса соответствует шаблону правила. В условиях можно проверка для определенных значений заголовков HTTP или переменных сервера или проверить, соответствует ли запрошенный URL-адрес файлу или каталогу в физической файловой системе.
- Действие — действие используется для указания того, что делать, если строка URL-адреса соответствует шаблону правила и выполняются все условия правила.
Область правил переопределения
Правила перезаписи можно определить в двух разных коллекциях:
<globalRules>
— Правила в этой коллекции можно определить только на уровне сервера. Глобальные правила используются для определения логики перезаписи URL-адресов на уровне сервера. Эти правила определены в файле applicationHost.config, и они не могут быть переопределены или отключены на всех более низких уровнях конфигурации. Глобальные правила всегда работают с путем абсолютного URL-адреса (то есть запрошенного URI без имени сервера). Эти правила оцениваются в начале конвейера обработки запросов IIS (событие PreBeginRequest ).<rules>
— правила в этой коллекции называются распределенными правилами, и их можно определить на любом уровне в иерархии конфигурации. Распределенные правила используются для определения логики перезаписи URL-адресов, относящегося к определенной конфигурации область. Этот тип правила можно добавить на любом уровне конфигурации с помощью файлов web.config или с помощью<location>
тегов в файлах ApplicationHost.config или Web.config. Распределенные правила работают по URL-адресу относительно расположения файла web.config, в котором они определены. В случаях, когда распределенные правила определяются внутри тега<location>
, они работают по URL-пути относительно пути, указанному для этого<location>
тега. Эти правила вычисляются на событии BeginRequest в конвейере IIS.
Оценка правил
Каждый уровень конфигурации в IIS может иметь ноль или больше правил перезаписи. Правила оцениваются в том же порядке, в котором они указаны. Модуль переопределения URL-адресов обрабатывает набор правил с помощью следующего алгоритма:
- Во-первых, URL-адрес соответствует шаблону правила. Если он не соответствует, модуль перезаписи URL-адресов немедленно останавливает обработку этого правила и переходит к следующему правилу.
- Если шаблон совпадает и нет условий для правила, модуль перезаписи URL-адресов выполняет действие, указанное для этого правила, а затем переходит к следующему правилу, где он использует замененный URL-адрес в качестве входных данных для этого правила.
- Если шаблон соответствует правилу и есть условия, модуль перезаписи URL-адресов оценивает условия. Если оценка выполнена успешно, выполняется указанное действие правила, а в качестве входных данных для последующего правила используется URL-адрес перезаписи.
Правило может включать флаг StopProcessing . Когда действие правила выполняется (т. е. соответствующее правило) и этот флаг включен, это означает, что больше последующих правил не будет обработано, и запрос будет передан конвейеру запросов IIS. По умолчанию этот флаг отключен.
Наследование правил
Если правила определены на нескольких уровнях конфигурации, модуль перезаписи URL-адресов оценивает правила в следующем порядке:
- Оцените все глобальные правила.
- Оцените набор правил, включающий распределенные правила из родительских уровней конфигурации, а также правила из текущего уровня конфигурации. Оценка выполняется в порядке родительского к дочернему, что означает, что родительские правила вычисляются сначала, а правила, определенные на последнем дочернем уровне, оцениваются последним.
Сохранение исходного URL-адреса
Модуль переопределения URL-адресов сохраняет исходный запрошенный путь URL-адреса в следующих переменных сервера:
- HTTP_X_ORIGINAL_URL — эта переменная сервера содержит исходный URL-адрес в декодируемом формате;
- UNENCODED_URL — эта переменная сервера содержит исходный URL-адрес точно так же, как он был запрошен веб-клиентом, при сохранении всех исходных кодировок.
Доступ к частям URL-адресов из правила переопределения
Важно понимать, как к определенным частям строки URL-адреса можно получить доступ из правила перезаписи.
Для URL-адреса HTTP в этой форме: http(s)://<host>:<port>/<path>?<Querystring>
- <Путь> соответствует шаблону правила.
- Строка <запросов> доступна в переменной сервера, называемой QUERY_STRING, и к ней можно получить доступ с помощью условия в правиле.
- Узел <> доступен в переменной сервера HTTP_HOST и может быть доступен с помощью условия в правиле.
- Порт <> доступен в переменной сервера SERVER_PORT и может быть доступен с помощью условия в правиле.
- Переменные сервера SERVER_PORT_SECURE и HTTPS можно использовать для определения того, использовалось ли безопасное подключение. Доступ к этим переменным сервера можно получить с помощью условия в правиле.
- Переменная сервера REQUEST_URI может использоваться для доступа ко всему запрошенным URL-пути, включая строку запроса.
Например, если запрос был выполнен для этого URL-адреса: http://www.mysite.com/content/default.aspx?tabid=2&subtabid=3
и на уровне сайта определено правило перезаписи:
- Шаблон правила получает строку
content/default.aspx
URL-адреса в качестве входных данных. - Переменная сервера QUERY_STRING содержит
tabid=2&subtabid=3
. - Переменная сервера HTTP_HOST содержит
www.mysite.com
. - Переменная сервера SERVER_PORT содержит
80
. - Переменная сервера SERVER_PORT_SECURE содержит
0
и содержит HTTPSOFF
. - Переменная сервера REQUEST_URI содержит
/content/default.aspx?tabid=2&subtabid=3
. - Переменная сервера PATH_INFO содержится
/content/default.aspx
.
Обратите внимание, что входная строка URL-адреса, передаваемая в распределенное правило, всегда соответствует расположению файла web.config, в котором определено правило. Например, если запрос выполняется http://www.mysite.com/content/default.aspx?tabid=2&subtabid=3
, и правило перезаписи определяется в каталоге /content , то правило получает эту строку URL-адреса default.aspx в качестве входных данных.
Переопределение конфигурации правила
Шаблон правила
Шаблон правила перезаписи используется для указания шаблона, с которым сравнивается текущий путь URL-адреса. Текущее значение в этом контексте означает значение пути URL-адреса при применении правила. Если перед текущим правилом существовали какие-либо правила, возможно, они соответствовали исходному запрошенному URL-адресу и изменили его. Строка URL-адреса, вычисляемая по шаблону, не включает строку запроса. Чтобы включить строку запроса в оценку правила, можно использовать переменную сервера QUERY_STRING в условии правила. Дополнительные сведения см. в разделе "Использование переменных сервера в правилах перезаписи".
Шаблон указывается в элементе <сопоставления> правила переопределения.
Синтаксис шаблона правила
Синтаксис шаблона правила можно указать с помощью атрибута patternSyntax правила. Этот атрибут можно задать для одного из следующих параметров:
ECMAScript — синтаксис регулярного выражения, совместимый с Perl (стандарт ECMAScript ). Это параметр по умолчанию для любого правила. Это пример формата шаблона: "^([_0-9a-zA-Z-]+/)? (wp-.*)"
Wild карта — синтаксис Wild карта используется в модуле перенаправления HTTP IIS. Ниже приведен пример шаблона в этом формате: "/Scripts/*_in.???", где звездочка ("*") означает "соответствовать любому количеству символов и записывать их в обратной ссылке" и "?" означает, что соответствует ровно одному символу (обратная ссылка не создается).
Область атрибута patternSyntax является правилом, то есть применяется к шаблону текущего правила и ко всем шаблонам, используемым в условиях этого правила.
Свойства шаблона правила
Шаблон можно отрицать с помощью атрибута <negate элемента match>. Если этот атрибут используется, действие правила выполняется только в том случае, если текущий URL-адрес не соответствует указанному шаблону.
По умолчанию используется сопоставление шаблонов без учета регистра. Чтобы включить конфиденциальность регистра, можно использовать атрибут <ignoreCase элемента сопоставления> правила.
Условия для правил
Условия правила позволяют определять дополнительную логику для оценки правил, которая может быть основана на входных данных, отличных от текущей строки URL-адреса. Любое правило может иметь ноль или более условий. Условия правила оцениваются после успешного сопоставления шаблона правила.
Условия определяются в <коллекции условий> правила переопределения. Эта коллекция имеет атрибут, называемый логическим группированием , который определяет, как оцениваются условия. Если правило имеет условия, действие правила выполняется только в том случае, если шаблон правила соответствует и:
- Все условия были оценены как true, при условии, что использовалось логическое группирование="MatchAll".
- По крайней мере одно из условий было оценено как true, при условии, что использовался логическийgrouping="MatchAny".
Условие определяется путем указания следующих свойств:
- Входная строка
- Тип соответствия
Входные данные условия указывают, какой элемент следует использовать в качестве входных данных для оценки условия. Входные данные условия — это произвольная строка, которая может включать переменные сервера и обратные ссылки на предыдущие шаблоны условий и (или) шаблонов правил.
Тип соответствия может быть одним из следующих трех вариантов:
IsFile — этот тип соответствия используется для определения того, содержит ли входная строка физический путь к файлу в файловой системе. Если строка ввода условия не указана, модуль перезаписи URL-адресов использует физический путь запрошенного файла в качестве значения по умолчанию для входных данных условия. Этот тип соответствия можно использовать только для распределенных правил.
IsDirectory — этот тип сопоставления используется для определения того, содержит ли входная строка физический путь к каталогу в файловой системе. Если строка ввода условия не указана, модуль перезаписи URL-адресов использует физический путь запрошенного файла в качестве значения по умолчанию для входных данных условия. Этот тип соответствия можно использовать только для распределенных правил.
Шаблон — этот тип сопоставления используется для выражения условия, в котором произвольные входные строки сопоставляются с шаблоном регулярного выражения. Шаблон условия можно указать с помощью синтаксиса регулярных выражений или с помощью синтаксиса wild карта. Тип шаблона, используемый в условии, зависит от значения флага patternSyntax , определенного для правила, к которому принадлежит это условие. Этот тип условия имеет два связанных атрибута, которые управляют сопоставлением шаблонов:
- шаблон — используйте этот атрибут для указания фактического шаблона.
- ignoreCase — используйте этот атрибут для управления соответствием шаблонов условию, чувствительным к регистру или не учитывает регистр.
Кроме того, результат оценки условия можно отрицать с помощью атрибута negate . Это можно использовать для указания условия, которое проверка, если запрошенный URL-адрес не является файлом, как показано в следующем примере:
<add input="{REQUEST_FILENAME}" matchType="isFile" negate="true">
Действие правила
Действие перезаписи правила выполняется, когда текущий URL-адрес соответствует шаблону правила и успешно выполнена оценка условия (в зависимости от конфигурации правила все условия соответствуют или одному или нескольким условиям). Доступно несколько типов действий, а атрибут <типа элемента конфигурации действия> можно использовать для указания действия, выполняемого правилом. В следующих разделах описаны различные типы действий и параметры конфигурации, связанные с конкретными типами действий.
Действие перезаписи
Действие перезаписи заменяет текущую строку URL-адреса строкой подстановки. Строка подстановки всегда должна указывать путь URL-адреса (например, contoso/test/default.aspx). Обратите внимание, что замены, содержащие физический путь к файловой системе (например, C:\inetpub\wwwroot
), не поддерживаются в СЛУЖБАх IIS.
Действие перезаписи имеет следующие параметры конфигурации:
URL-адрес — это строка подстановки, используемая при перезаписи текущего URL-адреса. URL-адрес подстановки — это строковое значение, которое может содержать следующее:
- Обратная ссылка на шаблоны условий и правил. (Дополнительные сведения см. в разделе об использовании обратных ссылок.)
- Переменные сервера. (Дополнительные сведения см. в разделе об использовании переменных сервера.)
appendQueryString — указывает, сохраняется ли строка запроса из текущего URL-адреса во время подстановки. По умолчанию, если значение флага appendQueryString не указано, предполагается, что значение равно TRUE. Это означает, что строка запроса из исходного URL-адреса добавляется к заменяемом URL-адресу.
Действие перенаправления
Действие перенаправления указывает модулю перезаписи URL-адресов, чтобы отправить ответ перенаправления клиенту. Код состояния перенаправления (3xx) можно указать в качестве параметра для этого действия. Поле "Расположение" ответа содержит строку подстановки, указанную в правиле.
URL-адрес подстановки правила перенаправления можно указать в одной из следующих форм:
- Относительный URL-путь — contoso/test/default.aspx
- Абсолютный универсальный код ресурса (URI) —
https://example.com/contoso/test/default.aspx
Использование действия перенаправления подразумевает, что последующие правила, вычисляемые для текущего URL-адреса после выполнения перенаправления.
Действие перенаправления имеет следующие параметры конфигурации:
URL- использует строку подстановки в качестве URL-адреса перенаправления. URL-адрес подстановки — это строка, которая может содержать следующее:
- Обратная ссылка на шаблоны условий и правил. (Дополнительные сведения см. в разделе об использовании обратных ссылок.)
- Переменные сервера. (Дополнительные сведения см. в разделе об использовании переменных сервера.)
appendQueryString — указывает, должна ли строка запроса из текущего URL-адреса сохраняться во время подстановки. По умолчанию, если флаг AppendQueryString не указан, предполагается, что он имеет значение TRUE. Это означает, что строка запроса из исходного URL-адреса добавляется к заменяемом URL-адресу.
redirectType — задает код состояния, используемый во время перенаправления:
- 301 — постоянный
- 302 — найдено
- 303 — см. другие
- 307 — временная
Действие CustomResponse
Действие CustomResponse приводит к тому, что модуль переопределения URL-адресов отвечает на HTTP-клиент с помощью указанного пользователем кода состояния, подкода и причины. Использование действия CustomResponse подразумевает, что последующие правила не вычисляются для текущего URL-адреса после выполнения этого действия.
Действие CustomResponse имеет следующие параметры конфигурации:
- statusCode— указывает код состояния, используемый в ответ на клиент.
- subStatusCode — указывает код подстатуса, используемый в ответ на клиент.
- statusReason — указывает фразу причины, используемую с кодом состояния.
- statusDescription — указывает одно описание строки, которое нужно поместить в текст ответа.
Действие AbortRequest
Действие AbortRequest приводит к тому, что модуль перезаписи URL-адресов удаляет HTTP-подключение для текущего запроса. Действие не имеет параметров. Использование этого действия подразумевает, что последующие правила не оцениваются для текущего URL-адреса после выполнения этого действия.
Действие none
Действие None используется для указания того, что действие не выполняется.
Использование переменных сервера в правилах перезаписи
Переменные сервера предоставляют дополнительные сведения о текущих HTTP-запросах. Эти сведения можно использовать для принятия решений по перезаписи или создания URL-адреса перезаписи. На переменные сервера можно ссылаться в следующих расположениях в правилах переопределения:
В строке ввода условия
В строках подстановки правил, в частности:
- Атрибут url-адреса действия перезаписи и перенаправления
- statusLine и responseLine действия CustomResponse
На переменные сервера можно ссылаться с помощью синтаксиса {VARIABLE_NAME}. Например, следующее условие использует переменную сервера QUERY_STRING:
<add input="{QUERY_STRING}" pattern="id=([0-9]+)" />
Переменные сервера также можно использовать для доступа к заголовкам HTTP из текущего запроса. Любой заголовок HTTP, предоставленный текущим запросом, представляется в виде переменной сервера, которая имеет имя, созданное в соответствии с этим соглашением об именовании:
- Все символы дефиса ("-") в имени заголовка HTTP преобразуются в символы подчеркивания ("_").
- Все буквы в имени заголовка HTTP преобразуются в регистр заглавной буквы.
- Префикс "HTTP_" добавляется в имя заголовка.
Например, чтобы получить доступ к заголовку HTTP "user-agent" из правила перезаписи, можно использовать переменную сервера {HTTP_USER_AGENT}.
Использование обратных ссылок в правилах перезаписи
Части входных данных правил или условий могут быть записаны в обратных ссылках. Затем их можно использовать для создания URL-адресов подстановки в действиях правил или создания входных строк для условий правила.
Обратные ссылки создаются различными способами в зависимости от типа синтаксиса шаблона, используемого для правила. При использовании синтаксиса шаблона ECMAScript можно создать обратную ссылку, поместив скобки вокруг части шаблона, которая должна записывать обратную ссылку. Например, шаблон ([0-9]+)/([a-z]+).html будет записывать 07 и статью в обратной ссылке из этого запрошенного URL-адреса: 07/article.html. Если используется синтаксис шаблона Wild карта, в шаблоне всегда создаются обратные ссылки при использовании символа звездочки (*). При использовании обратной ссылки в шаблоне не создаются. Например, шаблон */*.html будет записывать contoso и тестировать обратные ссылки из этого запрошенного URL-адреса: contoso/test.html.
Использование обратных ссылок одинаково независимо от того, какой синтаксис шаблона использовался для их записи. Обратные ссылки можно использовать в следующих расположениях в правилах перезаписи:
В входных строках условий
В действиях правила, в частности:
- Атрибут url-адреса действия перезаписи и перенаправления
- statusLine и responseLine действия CustomResponse
В параметре ключа для карты перезаписи
Обратные ссылки на шаблоны условий определяются {C:N}, где N составляет от 0 до 9. Обратные ссылки на шаблоны правил определяются {R:N}, где N — от 0 до 9. Обратите внимание, что для обоих типов обратных ссылок {R:0} и {C:0}будут содержать соответствующую строку.
Например, в этом шаблоне:
^(www\.)(.*)$
Для строки: www.foo.com
обратные ссылки будут индексированы следующим образом:
{C:0} - www.foo.com
{C:1} - www.
{C:2} - foo.com
В действии правила можно использовать обратные ссылки на шаблон правила и последнее соответствующее условие этого правила. В строке ввода условия можно использовать обратные ссылки на шаблон правила и ранее соответствующее условие.
В следующем примере правила показано, как создаются и ссылаются обратные ссылки:
<rule name="Rewrite subdomain">
<match url="^(.+)" /> <!-- rule back-reference is captured here -->
<conditions>
<add input="{HTTP_HOST}" type="Pattern" pattern="^([^.]+)\.mysite\.com$" /> <!-- condition back-reference is captured here -->
</conditions>
<action type="Rewrite" url="{C:1}/{R:1}" /> <!-- rewrite action uses back-references to condition and to rule when rewriting the url -->
</rule>
Взаимодействие с кэшированием выходных данных IIS
Модуль переопределения URL-адресов управляет поведением кэша выходных данных IIS, чтобы:
- Оптимально использовать режим ядра и кэширование выходных данных в пользовательском режиме для перезаписи URL-адресов, что повышает производительность веб-приложения, использующего модуль переопределения URL-адресов.
- Предотвращение кэширования ответов при нарушении логики кэширования из-за перезаписи URL-адресов.
Модуль управляет кэшированием выходных данных путем изменения определенных свойств кэширования или отключения кэширования в целом. Модуль не может включить кэширование выходных данных, если он был отключен конфигурацией IIS или любым другим модулем в конвейере IIS. Кэширование выходных данных контролируется следующим образом:
Модуль всегда задает параметр кэша пользовательского режима разнымиByHeader="HTTP_X_ORIGINAL_URL". Это гарантирует, что при включении кэширования в пользовательском режиме модуль учитывает исходный URL-адрес для создания ключа для записи кэша.
Если набор правил перезаписи использует переменные сервера со значениями, которые являются либо константой в течение всего процесса, либо производными от запрошенного URL-адреса, набор правил считается безопасным для кэширования выходных данных. Это означает, что модуль перезаписи URL-адресов не будет изменять существующую политику кэширования, отличной от параметра varyByHeader , как описано на шаге 1.
Следующие переменные сервера при использовании в правилах перезаписи не вызывают никакого влияния на политику кэширования выходных данных:
- "CACHE_URL"
- "DOCUMENT_ROOT"
- "HTTP_URL"
- "HTTP_HOST"
- "PATH_INFO"
- "PATH_TRANSLATED"
- "QUERY_STRING"
- "REQUEST_FILENAME"
- "REQUEST_URI"
- "SCRIPT_FILENAME"
- "SCRIPT_NAME"
- "SCRIPT_TRANSLATED"
- "UNENCODED_URL"
- URL-адрес
- "URL_PATH_INFO"
- ""APP_POOL_ID"
- "APPL_MD_PATH"
- "APPL_PHYSICAL_PATH"
- "GATEWAY_INTERFACE"
- "SERVER_SOFTWARE"
- "SSI_EXEC_DISABLED"
Если набор правил перезаписи использует любую переменную сервера, не упоминание в приведенном выше списке, набор правил считается небезопасным для кэширования выходных данных. Это означает, что модуль перезаписи URL-адресов отключает кэширование режима ядра для всех запросов, были ли перезаписаны ИЛИ нет. Кроме того, модуль изменит политику кэширования для кэша пользовательского режима, задав свойство кэширования varyByValue , чтобы содержать сцепленную строку всех значений переменных сервера, используемых в наборе правил.
Строковые функции
Существует три строковые функции, доступные для изменения значений в действии правила переопределения, а также для любых условий:
- ToLower — возвращает входную строку, преобразованную в нижний регистр.
- UrlEncode — возвращает входную строку, преобразованную в формат, закодированный URL-адресом. Эту функцию можно использовать, если URL-адрес подстановки в правиле перезаписи содержит специальные символы (например, не asCII или URI-unsafe символы).
- UrlDecode — декодирует входную строку, закодированную в URL-адресе. Эту функцию можно использовать для декодирования входных данных условия перед сопоставлением с шаблоном.
Функции можно вызвать с помощью следующего синтаксиса:
{function_name:any_string}
Где "function_name" может находиться в следующих параметрах: ToLower, UrlEncode, UrlDecode. "Any_string" может быть литеральной строкой или строкой, созданной с помощью переменных сервера или обратных ссылок. Например, ниже приведены допустимые вызовы строковых функций:
{ToLower:DEFAULT.HTM}
{UrlDecode:{REQUEST_URI}}
{UrlEncode:{R:1}.aspx?p=[résumé]}
Строковые функции можно использовать в следующих расположениях в правилах перезаписи:
В входных строках условий
В строках подстановки правил, в частности:
- Атрибут URL-адреса действий перезаписи и перенаправления
- Атрибуты statusLine и responseLine действия CustomResponse
Пример правила, использующего функцию ToLower :
<rule name="Redirect to canonical url">
<match url="^(.+)" /> <!-- rule back-reference is captured here -->
<conditions>
<!-- Check whether the requested domain is in canonical form -->
<add input="{HTTP_HOST}" type="Pattern" pattern="^www\.mysite\.com$" negate="true" />
</conditions>
<!-- Redirect to canonical url and convert URL path to lowercase -->
<action type="Redirect" url="http://www.mysite.com/{ToLower:{R:1}}" redirectType="Found" />
</rule>
Пример правила, использующего функцию UrlEncode :
<rules>
<rule name="UrlEncode example" stopProcessing="true">
<match url="resume" />
<action type="Rewrite" url="default.aspx?name={UrlEncode:résumé}"/>
</rule>
Пример правила, использующего функцию UrlDecode :
<rules>
<rule name="UrlDecode example">
<match url="default.aspx" />
<conditions>
<add input="{UrlDecode:{QUERY_STRING}}" pattern="résumé" />
</conditions>
<action type="Rewrite" url="default.aspx?type=resume" />
</rule>
</rules>
Перезапись карт
Карта перезаписи — это произвольная коллекция пар "имя-значение", которые можно использовать в правилах перезаписи для создания URL-адреса подстановки во время перезаписи. Перезапись карт особенно полезна, если у вас есть большой набор правил перезаписи, и все эти правила используют статические строки (то есть при отсутствии сопоставления шаблонов). В этих случаях вместо определения большого набора простых правил перезаписи можно поместить все сопоставления в карту перезаписи в виде ключей и значений между входным URL-адресом и URL-адресом подстановки. Затем, чтобы найти URL-адрес подстановки на основе входного URL-адреса, у вас будет одно правило перезаписи, которое ссылается на карту перезаписи.
Карта перезаписи определяет именованную коллекцию строк пар "имя-значение", как показано в следующем примере:
<rewriteMap name="MyRewriteMap" defaultValue="">
<add key="a.html" value="b.html" />
<add key="c.aspx" value="d.aspx" />
<add key="e.php" value="f.php" />
</rewriteMap>
Карта перезаписи однозначно определяется его именем и может содержать ноль или больше записей key-value. Кроме того, карта перезаписи может указать значение по умолчанию, используемое, если ключ не найден. Это управляется с помощью атрибута defaultValue . По умолчанию пустая строка используется в качестве значения по умолчанию.
На любом уровне конфигурации может быть любое количество карт перезаписи, кроме уровня файла. Карты перезаписи находятся в <элементе перезаписи Карты> коллекции.
Карты перезаписи ссылаются в правиле перезаписи с помощью следующего синтаксиса:
{RewriteMapName:Key}
Где параметр Key может быть любой произвольной строкой и может включать обратные ссылки на правила или шаблоны условий. Например, ниже приведены допустимые варианты использования карты перезаписи:
{MyRewriteMap:contoso/{R:1}/test/{C:1}}
{MyRewriteMap:a.html}
{MyRewriteMap:{R:1}?{C:1}&contoso=test}
Ссылка на карту перезаписи заменяется значением, которое было просмотрировано с помощью ключа, переданного в качестве параметра в ссылке на карту перезаписи. Если ключ не найден, используется значение по умолчанию для этой карты перезаписи.
На карту перезаписи можно ссылаться в следующих расположениях в правилах перезаписи:
В строке ввода условия
В строках подстановки правил, в частности:
- Атрибут URL-адреса действий перезаписи и перенаправления
- statusLine и responseLine действий CustomResponse
Пример 1. С помощью карты перезаписи, определенной следующим образом:
<rewrite>
<rewriteMaps>
<rewriteMap name="StaticRewrites" defaultValue="">
<add key="/diagnostics" value="/default.aspx?tabid=2&subtabid=29" />
<add key="/webcasts" value="/default.aspx?tabid=2&subtabid=24" />
<add key="/php" value="/default.aspx?tabid=7116" />
</rewriteMap>
</rewriteMaps>
</rewrite>
И правило перезаписи, определенное следующим образом:
<rewrite>
<rule name="Rewrite Rule">
<match url=".*" />
<conditions>
<add input="{StaticRewrites:{REQUEST_URI}}" pattern="(.+)" />
</conditions>
<action type="Rewrite" url="{C:1}"/>
</rule>
</rewrite>
Запрошенный URL-адрес /diagnostic будет перезаписан как /default.aspx?tabid=2&subtabid=29.
Запрошенный URL-адрес /webcasts будет перезаписан в /default.aspx?tabid=2&subtabid=24.
Запрошенный URL-адрес /php будет перезаписан в /default.aspx?tabid=7116.
Запрошенный URL-адрес /default.aspx не будет перезаписан, так как карта перезаписи не содержит элемент с ключом="/default.aspx"; поэтому карта перезаписи возвращает пустую строку, которая не будет соответствовать шаблону условия, поэтому действие правила не будет выполнено.
Пример 2. С помощью карты перезаписи, определенной следующим образом:
<rewrite>
<rewriteMaps>
<rewriteMap name="StaticRedirects" defaultValue="">
<add key="/default.aspx?tabid=2&subtabid=29" value="/diagnostics" />
<add key="/default.aspx?tabid=2&subtabid=24" value="/webcasts" />
<add key="/default.aspx?tabid=7116" value="/php" />
</rewriteMap>
</rewriteMaps>
</rewrite>
И правило перезаписи, определенное следующим образом:
<rewrite>
<rule name="Redirect rule">
<match url=".*" />
<conditions>
<add input="{StaticRedirects:{REQUEST_URI}}" pattern="(.+)" />
</conditions>
<action type="Redirect" url="http://www.contoso.com{C:1}" redirectType="Found" />
</rule>
</rewrite>
Запрошенный URL-адрес /default.aspx?tabid=2&subtabid=29 будет перенаправлен в http://www.contoso.com/diagnostics
.
Запрошенный URL-адрес /default.aspx?tabid=2&subtabid=24 будет перенаправлен в http://www.contoso.com/webcasts
.
Запрошенный URL-адрес /default.aspx?tabid=7116 будет перенаправлен в http://www.contoso.com/php
.
Запрошенный URL-адрес /default.aspx не будет перенаправлен, так как карта перезаписи не содержит элемента с ключом="/default.aspx"; поэтому карта перезаписи возвращает пустую строку, которая не будет соответствовать шаблону условия, поэтому действие правила не будет выполнено.