Один из авторов спецификации Well-Known URI и действующий эксперт по реестру рассказал, как правильно использовать этот механизм и в какие ловушки попадают разработчики протоколов.
Well-known locations решают конкретную задачу: клиент (браузер, бот или другое ПО) уже знает сайт и хочет быстро узнать что-то про этот сайт в целом. Классический пример — robots.txt. Кравлеру не нужно проверять заголовки каждого ответа, достаточно заглянуть в один известный файл. Другой пример — change-password, позволяющий клиентам менять пароль на сайте.
Но многие регистрируют well-known location просто потому, что так «положено» или надеются, что запись в реестре придаст протоколу вес. Это ошибка. Well-known locations решают узкую проблему; если её нет, регистрация только создаст новые сложности и не увеличит adoption.
Особая проблема — когда well-known location используют как URL-сокращатель. Вместо того чтобы передавать полный URL в протоколе, передают только имя сайта, а путь добивается автоматически. Такой подход жёстко привязывает сервис к сайту в соотношении 1:1. Если понадобится развернуть несколько сервисов, придётся плодить отдельные сайты и изобретать, как направлять пользователей на правильный. Если протокол может нести настоящий URL, well-known location не нужен.
Даже когда механизм выбран верно, возникают проблемы с обнаружением. Например, клиент стартует с login.example.com. Где искать well-known location — на этом поддомене или на example.com? Нужно ли следовать редиректам? Особенно остро это стоит, когда протокол не про веб-сайты, а просто использует HTTP для других целей. Соблазнительно повесить well-known location на apex домена, но операционно это бывает сложно.
Ещё одна ловушка — метаданные контента. Кажется логичным положить их в центральное место, как robots.txt. Но многие сайты обслуживают множество издателей (например, по старой схеме /~username/). В таком случае центральное хранилище либо отрезает этих пользователей от механизма, либо требует от администратора сложной инфраструктуры для управления. Возникает конфликт между удобством и детализацией, и часто приходится создавать параллельный механизм (через HTTP-заголовки или в самом контенте), а затем сводить их воедино.
Наконец, несколько практических советов. Если у протокола уже закреплён путь в корне (вроде robots.txt), нужен план перехода на well-known location. Не стоит предполагать, что работают только http и https URL — схемы надо перечислять явно. И главное: регистрировать своё well-known location нужно обязательно, иначе шансов на успешное прохождение ревью почти нет.