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

Строки 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). Это значение не может быть подстановочным знаком.

относительный код ресурса (URI)

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

Ниже приведены примеры правильно сформированных URLPrefixes:

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

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

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

строгий подстановочный знак (знак плюса)

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

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

явный

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

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

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

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

строке литерала IPv4

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

строка литерала IPv6

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

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

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

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

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

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

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

Например, можно было бы зарезервировать как явный 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. Например, предположим, что в разных очередях зарегистрированы следующие два URL-адреса:

  • 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 в Очередь1, так как самое длинное полное совпадение с https://www.adatum.com:80/ UrlPrefix, а не с url-адресом https://www.adatum.com:80/dir/sna UrlPrefix.