Маршрутизатор выбирает обработчика
Маршрутизатор сопоставляет входящий запрос с заданными условиями и направляет его к подходящему сервису через настроенные промежуточные обработчики. Условие может учитывать имя узла или путь. Важно различать выбор запроса и изменение самого запроса: одно не следует из другого автоматически. Если запрос содержит путь /shop/catalog, правило выбора по префиксу /shop определяет, подходит ли он этому маршруту. Сам факт совпадения не означает, что приложение получит только /catalog. Без соответствующего изменения пути оно может увидеть исходное значение и не найти ожидаемую страницу. Поэтому проверка маршрута должна включать сведения о запросе на входе приложения.
Удаление префикса выполняет отдельный обработчик
Промежуточный обработчик StripPrefix удаляет совпадающий префикс пути и сохраняет сведения о нём в заголовке X-Forwarded-Prefix. Это полезно, когда приложение работает от корня, а снаружи должно находиться под определённым префиксом. В нашем примере после удаления /shop запрос к /shop/catalog передаётся дальше как /catalog. Однако наличие обработчика в конфигурации ещё не означает, что нужный маршрутизатор его использует. Нужно проверить связь между ними и порядок промежуточной обработки. Если приложение изначально настроено обслуживать путь с префиксом, его удаление может оказаться ошибкой. Решение зависит от ожиданий приложения, а не только от внешнего адреса.
Проверьте обратную сторону страницы
Даже если основной документ открылся, он может содержать ссылки на изображения, стили и другие страницы. Если приложение формирует их так, будто размещено в корне внешнего сайта, браузер начнёт запрашивать другой путь. Тогда первая страница работает, а её оформление или переходы ломаются. Сведения о внешнем префиксе помогают только тогда, когда приложение умеет их учитывать или имеет подходящую настройку базового пути. Сам по себе заголовок не переписывает все ответы приложения. Поэтому проверяйте всю цепочку: исходный запрос, выбранный маршрут, преобразование пути, запрос к сервису и адреса, которые получает браузер. Это позволяет искать причину по наблюдениям, а не бесконечно менять правило наугад.
Попробуйте на практике
Проследите два вымышленных запроса на бумаге. Публикация сервиса в интернете, выдача доступа и изменение реальной конфигурации не требуются.
- Запишите внешний префикс /shop и условие приложения: оно ожидает пути от корня. Выберите два запроса: /shop/catalog и /shop/images/logo.png.
- Сначала покажите путь без промежуточного изменения. Затем отдельно запишите результат удаления префикса: /catalog и /images/logo.png.
- Добавьте вымышленную ссылку, которую приложение отдаёт браузеру от корня сайта. Объясните, почему такой запрос может не попасть в маршрут с внешним префиксом.
- Составьте список проверок: подключение обработчика, ожидания приложения и формирование адресов ресурсов. Отметьте, что успешное совпадение правила подтверждает только один этап.
Как проверить результат. Схема различает отбор запроса и преобразование пути. Видно, что должен получить сервис и какие адреса должен использовать браузер; работа основного документа не объявлена проверкой всех ресурсов.
Частые вопросы
Нужно ли удалять префикс у каждого приложения?
Нет. Некоторые приложения настроены работать под ним самостоятельно. Удаление должно соответствовать ожиданиям сервиса. Сначала выясните его базовый путь и способы формирования ссылок.
Если настроен защищённый доступ по HTTPS, проблема пути уже исключена?
Нет. Защищённое соединение и обработка маршрутов решают разные задачи. Успешное установление соединения не подтверждает, что приложение получило правильный путь или вернуло пригодные адреса ресурсов.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.