Добавление бронирования

База данных маршрутизации содержит список бронирований. Список резервирования состоит из пользователей, которым разрешен доступ к пространству имен, а также уровню доступа для каждого пользователя, указанного в резервировании. При добавлении или удалении резервирования база данных маршрутизации проверяется для определения привилегий доступа.

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

Чтобы добавить новое бронирование

1. Если номер порта в UrlPrefix зарезервирован или зарегистрирован для схемы, отличающейся от указанной в UrlPrefix, регистрация завершается ошибкой. Http и HTTPS нельзя поддерживать в одном порту.

2. Найдите подходящую корзину для регистрации (см. раздел Маршрутизация входящих запросов) на основе типа узла. Остальные шаги относятся к этому контейнеру.

3. Выберите записи резервирования с компонентами схемы, узла и порта, которые соответствуют резервируемому UrlPrefix. Из них найдите запись с самым длинным совпадающим относительным URI, который не равен относительному URI в резерве (то есть родительский узел). Если запись существует, оцените права доступа на основе ACL, назначенной этой записи.

4. Если родительский узел не найден, это резервирование с пустым относительным URI или корневое резервирование. Предоставьте права доступа только в том случае, если вызывающий объект зарегистрирован в учетных записях LocalSystem или Administrator.

5. Если права доступа предоставлены, проверьте наличие повторяющихся резервирований. Если запись о бронировании существует с той же схемой, портом, узлом и относительным URI, возвращается код ERROR_ALREADY_EXISTS.

   Заметка

   Обновление существующей записи должно выполняться двумя шагами: удаление записи и добавление новой записи.

    

Если описанные выше шаги выполнены успешно, в базу данных резервирования вводится новая запись резервирования.

Заметка

Новая запись создается с указанным списком управления доступом (ACL) и не наследует ACL из родительской записи .

 

В следующих примерах показан процесс резервирования.

• Резервирование 1: https://+:80/vroot/subdir/ для пользователя A и пользователя C выполнено администратором успешно и заносится в список "+".
• Резервирование 2: https://adatum.com:80/vroot/ для пользователя B, выполненное администратором, успешно и внесено в корзину "Явный хост".
• Резервирование 3: https://adatum.com:80/vroot/subdir/otherdir/, которое пользователь B сделал для пользователя C, успешно выполнилось благодаря резервированию 2.
• Резервирование 4: https://+:80/vroot/subdir/otherdir/ пользователем A для пользователя E успешно выполнено благодаря резервированию 1.
• Резервирование 5 под номером https://adatum.com:80/vroot/subdir/otherdir/ для пользователя E, произведенное пользователем A, завершилось сбоем. Доступ запрещен из-за резервирования 2.
• Бронирование 6: https://+:80/vroot/subdir/ для пользователя A, выполненное администратором, завершилось неудачей. Резервирование конфликтует с резервированием 1.
• Резервирование 7 пользователем A для пользователя A не удалось из-за ошибки https://adatum.com:80/newroot/. Доступ запрещен из-за неявного корневого резервирования https://adatum.com:80/ для LocalSystem или администратора.

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

• Регистрация: https://adatum.com:80/vroot/ по заявке 1 для пользователя A.
• Запрос на https://adatum.com:80/vroot/subdir/file.htm передается приложению 1.
• Резервирование: https://+:80/vroot/subdir/ для пользователя B.
• Запрос на https://adatum.com:80/vroot/subdir/file.htm отклонён.
• Регистрация: https://adatum.com:80/vroot/subdir/ по заявке 2 для пользователя B.
• Запрос на https://adatum.com:80/vroot/subdir/file.htm передается приложению 2.