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

Маршрутизация входящих запросов

  • Статья

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

  • + : регистрация портов помещается в контейнер "Строгий подстановочный знак"

  • host: регистрация портов помещается в контейнер "Explicit"

  • IP: регистрация портов помещается в контейнер "Слабый подстановочный знак с привязкой к IP-адресу".

  • * : регистрация портов помещается в контейнер "Слабый подстановочный знак"

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

Алгоритм маршрутизации API HTTP-сервера находит наилучшее соответствие для UrlPrefix путем поиска записей регистрации и резервирования базы данных маршрутизации, начиная со строгого контейнера с подстановочными знаками и заканчивая слабым контейнером с подстановочными знаками. Лучшее совпадение в контейнере — это самое длинное совпадение в относительной части URI UrlPrefix (при условии точного совпадения для узлов, портов и схем в URL-адресе). После обнаружения совпадения в контейнере алгоритм маршрутизации останавливает поиск и пропускает все сегменты с более низким приоритетом.

Например, рассмотрим следующие регистрации (перечисленные в порядке убывания приоритета на основе типов контейнеров):

  • Регистрация: https://+:80/vroot/ регистрируется приложением 1.

  • Регистрация: https://adatum.com:80/ регистрируется приложением 2

  • Регистрация: https://\*:80/ регистрируется приложением 3

Входящий запрос для https://adatum.com:80/vroot/subdir/file.htm/ доставляется приложению 1. Входящий запрос для https://adatum.com:80/default.htm/ доставляется приложению 2. Входящий запрос для https://otheradatum.com:80/file.htm/ доставляется приложению 3.

Если лучше всего подходит запись резервирования, это означает, что приложение, которое должно получить запрос, не выполняется. Например, рассмотрим следующую регистрацию и резервирование:

  • Регистрация: https://\*:80/vroot/ регистрируется приложением 1, пользователем A.

  • Резервирование: https://adatum.com:80/ зарезервировано для пользователя B

Входящий запрос для https://adatum.com:80/vroot/file.htm/ не доставляется приложению 1, так как лучшее совпадение приводит к записи резервирования для пользователя B. Правила приоритета применяются в этом случае к резервированию, которое имеет более высокий приоритет. Если не активен процесс, авторизованный и зарегистрированный в запросах на обслуживание для полученного URL-адреса, запрос отклоняется с кодом состояния 400 (Недопустимый запрос).