Строки UrlPrefix

  • Статья

В API HTTP-сервера UrlPrefix — это строка Юникода с расширенным символом (UTF-16) с канонической формой, указывающей раздел пространства имен URL-адреса. Он используется для резервирования раздела пространства имен URL-адреса для учетной записи пользователя или регистрации раздела пространства имен URL-адреса для процесса.

Формат UrlPrefix

UrlPrefix имеет следующий синтаксис:

"scheme://host:port/relativeURI"

Элементы схемы, узла и порта объекта UrlPrefix должны быть пустыми и соответствовать следующим правилам:

Схема

Должен быть либо http, либо https, все в нижнем регистре.

Узла

Должно быть полным доменным именем, строкой литерала IPv4 или IPv6 или подстановочным знаком. В отличие от схемы, которая должна быть в нижнем регистре, в хост-части регистр не учитывается. В зависимости от того, как указана его часть узла, UrlPrefix относится к одной из следующих четырех категорий маршрутизации, которые более подробно описаны ниже.

Строгий подстановочный знак
Явная
Слабый подстановочный знак с привязкой к IP-адресу
Слабый подстановочный знак

Порт

Десятичная числовая строка, которая не начинается с нуля и представляет допустимый номер TCP-порта (от 1 до 65 535). Это значение не может быть подстановочным знаком.

Relativeuri

Элемент relativeURI является необязательным, но при наличии всегда должен следовать символ косой черты ("/"). Это строка префикса, указывающая поддеревое в пространстве имен компьютера, указанное относительно схемы, узла и порта. В отличие от схемы, которая должна быть в нижнем регистре, относительная часть URI не учитывает регистр.

Примеры правильно сформированных urlPrefixes:

  • https://www.adatum.com:80/vroot/
  • https://adatum.com:443/secure/database/
  • https://+:80/vroot/

Категории Host-Specifier

Для гибкости и простоты использования API HTTP-сервера поддерживает четыре различных способа указания узлов. Ниже перечислены четыре категории описатель узла в порядке приоритета:

Сильный подстановочный знак (знак "плюс")

Если главный элемент UrlPrefix состоит из одного знака "плюс" (+), urlPrefix соответствует всем возможным именам узлов в контексте элементов схемы, порта и relativeURI и попадает в категорию строгих подстановочных знаков.

Строгий подстановочный знак полезен, когда приложению необходимо обслуживать запросы, адресованные одному или нескольким относительным URI, независимо от того, как эти запросы поступают на компьютер или какой сайт они указывают в заголовках узла. Использование строгого подстановочного знака в этой ситуации позволяет избежать необходимости указывать исчерпывающий список узлов и (или) IP-адресов.

Явные

Явное имя узла, например полное доменное имя в элементе узла, помещает UrlPrefix в категорию explicit. Этот тип ведущего элемента сопоставляется непосредственно с заголовками узла входящих запросов.

Явные спецификации узлов полезны для многосайтовых приложений, таких как веб-серверы, которые доставляют разное содержимое в зависимости от сайта, на который был направлен запрос.

Слабый подстановочный знак с привязкой к IP-адресу

Если IP-адрес отображается в качестве ведущего элемента, urlPrefix попадает в категорию Слабые подстановочные знаки с привязкой к IP-адресу. Этот тип UrlPrefix соответствует любому имени узла для указанного IP-интерфейса с указанной схемой, портом и относительным URI, который еще не был сопоставлен строгим подстановочным знаком или явным urlPrefix. IP-адрес принимает одну из двух форм в элементе host:

Строка-литерал IPv4

Литерал IPv4 состоит из четырех пунктирных десятичных чисел, каждое из которых в диапазоне от 0 до 255, например 192.168.0.0.

Строка-литерал IPv6

Строка литерала IPv6 заключена в квадратные скобки и содержит шестнадцатеричные числа, разделенные двоеточием; например: [::1] или [3ffe:ffff::6ECB:0101].

Описатели узла со слабыми подстановочными знаками с привязкой к IP-адресу предназначены для приложений, которые изменяют обслуживаемое содержимое в зависимости от маршрута, взятого входящими запросами. Не полагайтесь на описатели узла со слабым подстановочными знаками, привязанные к IP-адресу, для обеспечения безопасности.

Слабый подстановочный знак (звездочка)

Если в качестве ведущего элемента отображается звездочка (*), urlPrefix попадает в категорию слабых подстановочных знаков. Этот тип UrlPrefix соответствует любому имени узла, связанному с указанной схемой, портом и относительным URI, которые еще не были сопоставлены строгим подстановочным знаком, явным или слабым подстановочным знаком URLPrefix с ip-привязкой.

В некоторых случаях эту спецификацию узла можно использовать как универсальный шаблон по умолчанию или использовать для указания большого раздела пространства имен URL-адресов без необходимости использовать много urlPrefixes.

Обнаружение конфликтов UrlPrefix во время резервирования и регистрации

В целях резервирования и регистрации четыре различные категории UrlPrefix обрабатываются отдельно, без ссылки друг на друга. Конфликтующие urlPrefixes можно регистрировать, если они находятся в разных категориях. Только в той же категории конфликт приводит к сбою попытки резервирования.

Например, можно зарезервировать как явный UrlPrefix https://www.adatum.com:80/vroot/ , так и конфликтующий сильный подстановочный знак UrlPrefix https://+:80/vroot/, так как они относятся к разным категориям. Однако последующая попытка резервирования https://+:80/vroot/ для другого пользователя завершится ошибкой, так как она конфликтует с существующим резервированием в собственной категории.

Поведение маршрутизации

При маршрутизации входящего HTTP-запроса API HTTP-сервера начинается со строгой категории подстановочных знаков и сравнивает входящий URL-адрес с зарегистрированными и зарезервированными URL-адресами в этой категории.

Если входящий URL-адрес соответствует резервированию, но не регистрации, API HTTP-сервера не выполняет запрос. Это предотвращает возможность регистрации с более низким приоритетом получать запросы, не предназначенные для нее. Состояние ошибки — 400 ("Недопустимый запрос"), а не 503 ("Служба недоступна"), так как возвращаемое значение 503 иногда ошибочно интерпретируется шлюзами балансировки нагрузки как указывающее на перегрузку сервера.

Если в категории найдена соответствующая регистрация, запрос направляется в очередь запросов, связанную с этой регистрацией. Запрос всегда направляется в очередь, связанную с самым длинным соответствующим urlPrefix в категории.

Если совпадение в категории не найдено, API HTTP-сервера переходит к явной категории и повторяет ту же процедуру. Подытожим, что порядок, в котором проверяются категории, выглядит следующим образом:

  1. Строгий подстановочный знак
  2. Явная
  3. IP-Bound слабый подстановочный знак
  4. Слабый подстановочный знак

Если совпадение не найдено ни в одной из категорий, API HTTP-сервера отправляет ответ с кодом состояния 400, чтобы указать, что запрос не может быть перенаправлен.

Правило для самых длинных совпадений

В каждой категории UrlPrefix API HTTP-сервера направляет запрос в очередь, связанную с самым длинным совпадающим urlPrefix. Например, предположим, что следующие два объекта UrlPrefix зарегистрированы в разных очередях:

  • Queue1 https://www.adatum.com:80/
  • Queue2 https://www.adatum.com:80/dir/sna/

API HTTP-сервера направляет запрос в https://www.adatum.com:80/default.htm Queue1, а запрос https://www.adatum.com:80/dir/sna/snadefault.htm — в Queue2. Он направляет запрос в https://www.adatum.com:80/dir/app.htm Queue1, так как самое длинное полное совпадение выполняется с https://www.adatum.com:80/ UrlPrefix, а не с https://www.adatum.com:80/dir/sna UrlPrefix.