Поделиться через


Справочник по конфигурации модуля переопределения 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-адресов обрабатывает набор правил с помощью следующего алгоритма:

  1. Во-первых, URL-адрес соответствует шаблону правила. Если он не соответствует, модуль перезаписи URL-адресов немедленно останавливает обработку этого правила и переходит к следующему правилу.
  2. Если шаблон совпадает и нет условий для правила, модуль перезаписи URL-адресов выполняет действие, указанное для этого правила, а затем переходит к следующему правилу, где он использует замененный URL-адрес в качестве входных данных для этого правила.
  3. Если шаблон соответствует правилу и есть условия, модуль перезаписи URL-адресов оценивает условия. Если оценка выполнена успешно, выполняется указанное действие правила, а в качестве входных данных для последующего правила используется URL-адрес перезаписи.

Правило может включать флаг StopProcessing . Когда действие правила выполняется (т. е. соответствующее правило) и этот флаг включен, это означает, что больше последующих правил не будет обработано, и запрос будет передан конвейеру запросов IIS. По умолчанию этот флаг отключен.

Наследование правил

Если правила определены на нескольких уровнях конфигурации, модуль перезаписи URL-адресов оценивает правила в следующем порядке:

  1. Оцените все глобальные правила.
  2. Оцените набор правил, включающий распределенные правила из родительских уровней конфигурации, а также правила из текущего уровня конфигурации. Оценка выполняется в порядке родительского к дочернему, что означает, что родительские правила вычисляются сначала, а правила, определенные на последнем дочернем уровне, оцениваются последним.

Сохранение исходного 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 и содержит HTTPS OFF.
  • Переменная сервера 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, предоставленный текущим запросом, представляется в виде переменной сервера, которая имеет имя, созданное в соответствии с этим соглашением об именовании:

  1. Все символы дефиса ("-") в имени заголовка HTTP преобразуются в символы подчеркивания ("_").
  2. Все буквы в имени заголовка HTTP преобразуются в регистр заглавной буквы.
  3. Префикс "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, чтобы:

  1. Оптимально использовать режим ядра и кэширование выходных данных в пользовательском режиме для перезаписи URL-адресов, что повышает производительность веб-приложения, использующего модуль переопределения URL-адресов.
  2. Предотвращение кэширования ответов при нарушении логики кэширования из-за перезаписи URL-адресов.

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

  1. Модуль всегда задает параметр кэша пользовательского режима разнымиByHeader="HTTP_X_ORIGINAL_URL". Это гарантирует, что при включении кэширования в пользовательском режиме модуль учитывает исходный URL-адрес для создания ключа для записи кэша.

  2. Если набор правил перезаписи использует переменные сервера со значениями, которые являются либо константой в течение всего процесса, либо производными от запрошенного 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"
  3. Если набор правил перезаписи использует любую переменную сервера, не упоминание в приведенном выше списке, набор правил считается небезопасным для кэширования выходных данных. Это означает, что модуль перезаписи 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&amp;subtabid=29" />
    <add key="/webcasts" value="/default.aspx?tabid=2&amp;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&amp;subtabid=29" value="/diagnostics" />
    <add key="/default.aspx?tabid=2&amp;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"; поэтому карта перезаписи возвращает пустую строку, которая не будет соответствовать шаблону условия, поэтому действие правила не будет выполнено.