RFC 7320 | URI Дизайн и Владение

Аннотация

В разделе 1.1.1 RFC 3986 синтаксис URI определяется как «федеративная и расширяемая система именования, в которой спецификация каждой «схемы» может дополнительно ограничивать синтаксис и семантику идентификаторов, использующих эту схему». Другими словами, структура URI определяется его схемой. Несмотря на то, что схемы часто делегируют свою подструктуру владельцу URI, публикация независимых стандартов, которые предписывают определенные формы подструктуры URI, неуместна, поскольку по сути узурпирует владение. Этот документ дополнительно описывает эту проблемную практику и предоставляет некоторые приемлемые альтернативы для использования в стандартах.

Читать оригинальную версию документа на английском языке RFC 7320 PDF

1. Введение
1.1. Целевая аудитория
1.2. Условные обозначения
2. Лучшие современные практики стандартизации структурированных URI
2.1. Схемы в URI
2.2. Основания в URI
2.3. Пути в URI
2.4. Запросы в URI
2.5. Идентификаторы фрагмента URI
3. Альтернативы указанию структуры в URI
4. Вопросы безопасности
5. Ссылки
5.1. Нормативные ссылки
5.2. Информационные ссылки
Приложение А. Благодарности
Адрес автора

1. Введение

URI [RFC3986 #] очень часто включают структурированные данные приложения. Это может включать в себя артефакты из файловых систем (часто встречающиеся в компоненте «пути«) и пользовательскую информацию (часто в компоненте «запроса«). В некоторых случаях в компоненте «оснований» могут даже присутствовать специфичные для приложения данные (например, некоторые приложения распределены по нескольким именам хостов для обеспечения возможности разделения или распределения).

Кроме того, ограничения на структуру URI могут быть наложены реализацией; например, многие веб-серверы используют расширение имени файла последнего сегмента пути для определения типа носителя ответа. Аналогично, предварительно упакованные приложения часто имеют высоко структурированные URI, которые могут быть изменены только ограниченным образом (часто только имя хоста и порт, на котором они развернуты).

Поскольку владелец URI (как определено в разделе [webarch], раздел 2.2.2.1) выбирает использование сервера или приложения, это можно рассматривать как разумное делегирование полномочий. Однако, когда такие соглашения предписаны стороной, не являющейся владельцем, это может иметь несколько потенциально вредных последствий (Collisions, Dilution, Rigidity, Operational Difficulty, Client Assumptions):

Коллизии (Collisions). По мере того как стандартизируются все дополнительные соглашения для структуры URI, становится все более вероятным возникновение коллизий между ними (особенно с учетом того, что серверы, приложения и отдельные развертывания будут иметь свои собственные соглашения).
Разбавление (Dilution) — когда информация, добавляемая в URI, является эфемерной, это снижает ее полезность за счет снижения ее стабильности (см. [webarch] Раздел 3.5.1) и может привести к существованию нескольких альтернативных форм URI (см. [webarch] Раздел 2.3.1).
Жесткость (Rigidity) — фиксированный синтаксис URI часто мешает желаемым шаблонам развертывания. Например, если орган власти желает предложить несколько приложений для одного имени хоста, становится трудно или невозможно сделать это, если их URI не обеспечивают необходимую гибкость.
Операционная сложность (Operational Difficulty) — поддержка некоторых соглашений URI может быть затруднена в некоторых реализациях. Например, указание того, что конкретный параметр запроса будет использоваться с URI «HTTP», исключает использование веб-серверов, которые обслуживают ответ от файловой системы. Аналогично, приложение, которое фиксирует базовый путь для своей работы (например, «/v1»), делает невозможным развертывание других приложений с таким же префиксом на том же хосте.
Предположения клиента (Client Assumptions) — когда соглашения стандартизированы, некоторые клиенты неизбежно предполагают, что стандарты используются, когда эти соглашения видны. Это может привести к проблемам совместимости; например, если спецификация документирует, что параметр запроса URI «sig» указывает, что его полезная нагрузка является криптографической подписью для URI, это может привести к нежелательному поведению.

Публикация стандарта, который ограничивает существующую структуру URI способами, которые явно не разрешены в [RFC3986 #] (обычно путем обновления определения схемы URI), неуместна, поскольку структура URI должна находиться под жестким контролем ее владельца. И IETF (как и другие организации) не должны узурпировать это.

Этот документ объясняет некоторые лучшие современные практики для создания структур URI, соглашений и форматов в стандартах. Он также предлагает стратегии для спецификаций, чтобы избежать нарушения этих рекомендаций в Разделе 3.

1.1. Целевая аудитория

Требования этого документа предназначены для авторов спецификаций, которые ограничивают синтаксис или структуру URI или их частей. Два класса таких спецификаций вызываются специально:

Расширения протокола («расширения — extensions») — спецификации, которые предлагают новые возможности, которые могут применяться к любому идентификатору или к большому подмножеству возможных идентификаторов; например, новый механизм подписи для http-URI или метаданные для любого URI.
Приложения, использующие URI («приложения — applications») — спецификации, которые используют URI для удовлетворения конкретных потребностей; например, HTTP-интерфейс для конкретной информации на хосте.

Требования, нацеленные на общий класс «Спецификации» (Specifications), применяются ко всем спецификациям, включая перечисленные выше и другие.

Обратите внимание, что эта спецификация не должна интерпретироваться как предотвращающая распределение контроля над URI сторонами, которые законно владеют ими или делегировали это право собственности; например, спецификация может на законных основаниях определять семантику URI на веб-сайте IANA как часть создания реестра.

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

1.2. Условные обозначения

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119 #] [RFC8174 #].

2. Лучшие современные практики стандартизации структурированных URI

Этот раздел обновляет [RFC3986 #], устанавливая ограничения на то, как другие спецификации могут определять структуру и семантику в URI. Рекомендации различаются в зависимости от компонента URI, как описано ниже.

2.1. Схемы в URI

Приложения и расширения МОГУТ требовать использования определенных «схем» URI; например, вполне допустимо требовать, чтобы приложение поддерживало URI «http» и «https». Однако приложениям НЕ СЛЕДУЕТ препятствовать использованию других схем URI в будущем, если только они явно не могут использоваться только с назначенными схемами.

Спецификация, которая определяет подструктуру в конкретной схеме URI, ДОЛЖНА делать это в определяющем документе для этой схемы URI. НЕОБХОДИМО, чтобы спецификация, определяющая подструктуру для схем URI, изменила [BCP115] (исключительное обстоятельство).

2.2. Основания в URI

Определения схемы определяют наличие, формат и семантику компонента «оснований» в URI; все другие спецификации НЕ ДОЛЖНЫ ограничивать или определять структуру или семантику для оснований URI, если только они не обновляют саму регистрацию схемы.

Например, расширение или приложение не должны говорить, что префикс «foo» в «foo_app.example.com» имеет смысл или вызывает специальную обработку в URI.

Однако приложения МОГУТ назначать или ограничивать порт, который они используют, когда это применимо. Например, BarApp может работать через порт nnnn (при условии, что он правильно зарегистрирован).

2.3. Пути в URI

Определения схемы определяют наличие, формат и семантику компонента «пути» в URI; все другие спецификации НЕ ДОЛЖНЫ ограничивать или определять структуру или семантику для любого компонента пути.

Единственным исключением из этого требования являются зарегистрированные «хорошо известные» (well-known) URI, как указано в [RFC5785 #]. Смотри этот документ для описания применимости этого механизма.

Например, приложение не должно указывать фиксированный путь URI «/myapp», так как это нарушает контроль хоста над этим пространством.

Указание фиксированного пути относительно другого (например, {что угодно} / myapp) также является плохой практикой (даже если «что бы то ни было» обнаружено, как предложено в разделе 3); хотя это может предотвратить коллизии, это не исключает возможности возникновения операционных трудностей (например, реализация, которая предпочитает вместо этого использовать обработку запросов из-за ограничений реализации).

2.4. Запросы в URI

Наличие, формат и семантика компонента «запроса» URI зависят от многих факторов и МОГУТ быть ограничены определением схемы. Часто они определяются реализацией самого ресурса.

Приложения НЕ ДОЛЖНЫ напрямую указывать синтаксис запросов, поскольку это может вызвать эксплуатационные трудности для развертываний, которые не поддерживают конкретную форму запроса. Например, сайт может захотеть поддерживать приложение, использующее «статические» (static) файлы, которые не поддерживают параметры запроса.

Расширения НЕ ДОЛЖНЫ ограничивать формат или семантику запросов.

Например, расширение, которое указывает, что все параметры запроса с именем «sig» указывают на криптографическую подпись, вступит в конфликт с потенциально существующими параметрами запроса на сайтах и заставит клиентов предположить, что любой соответствующий параметр запроса является подписью.

HTML [W3C.REC-html401-19991224] ограничивает синтаксис строк запроса, используемых при отправке формы. Новые языки форм НЕ ДОЛЖНЫ имитировать его, а вместо этого позволяют создавать более широкий спектр URI (например, позволяя форме создавать новые компоненты пути и т. д.).

Обратите внимание, что «общеизвестные» URI (см. [RFC5785 #]) МОГУТ ограничивать собственный синтаксис запроса, поскольку эти пространства имен фактически делегируются регистрирующей стороне.

2.5. Идентификаторы фрагмента URI

Определения типа носителя (согласно [RFC6838 #]) ДОЛЖНЫ определять синтаксис (ы) идентификатора «фрагмента«, который будет использоваться с ними; другие спецификации НЕ ДОЛЖНЫ определять структуру внутри идентификатора фрагмента, если только они явно не определяют структуру для повторного использования определениями типа мультимедиа.

Например, приложение, которое определяет общие идентификаторы фрагментов для неконтролируемых им типов носителей, вызовет проблемы взаимодействия с обработчиками для этих типов носителей (потому что новый нестандартный синтаксис не ожидается).

3. Альтернативы указанию структуры в URI

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

[RFC5988 #] определяет типы отношений для веб-ссылок. Предоставляя среду для ссылок в Интернете, где каждая ссылка имеет тип отношения, контекст и цель, она позволяет приложениям определять семантику ссылки и возможность подключения.

[RFC6570 #] предоставляет стандартный синтаксис для шаблонов URI, который можно использовать для динамической вставки специфичных для приложения переменных в URI, чтобы включить такие приложения, избегая при этом воздействия на контроль владельцев URI над ними.

[RFC5785 #] позволяет «зарезервировать» (reserved) определенные пути для стандартного использования в схемах URI, которые используют этот механизм (по умолчанию «http» и «https»). Обратите внимание, однако, что это не общий «выпускной клапан» (escape valve) для приложений, которым требуются структурированные URI; см. эту спецификацию для получения дополнительной информации.

Указание более сложных структур в попытке избежать коллизий не является приемлемым решением и не решает проблемы, описанные в разделе 1. Например, префикс параметров запроса с помощью «myapp_» не помогает, поскольку сам префикс подвержен риску столкновение (так как оно не «зарезервировано»).

4. Вопросы безопасности

Этот документ не вводит новые артефакты протокола с соображениями безопасности. Он запрещает некоторые действия, которые могут привести к уязвимости; например, если вводится чувствительный к безопасности механизм, предполагая, что компонент пути URI или строка запроса имеет конкретное значение, могут возникнуть ложные срабатывания (из-за сайтов, которые уже используют выбранную строку). Смотрите также [RFC6943 #].

5. Ссылки

5.1. Нормативные ссылки

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, «Media Type Specifications and Registration Procedures», BCP 13, RFC 6838, January 2013.

[webarch] Jacobs, I. and N. Walsh, «Architecture of the World Wide Web, Volume One», December 2004, <http://www.w3.org/TR/2004/REC-webarch-20041215>.

5.2. Информационные ссылки

[BCP115] Hansen, T., Hardie, T., and L. Masinter, «Guidelines and Registration Procedures for New URI Schemes», RFC 4395, BCP 115, February 2006.

[RFC5785] Nottingham, M. and E. Hammer-Lahav, «Defining Well-Known Uniform Resource Identifiers (URIs)», RFC 5785, April 2010.

[RFC5988] Nottingham, M., «Web Linking», RFC 5988, October 2010.

[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, «URI Template», RFC 6570, March 2012.

[RFC6943] Thaler, D., «Issues in Identifier Comparison for Security Purposes», RFC 6943, May 2013.

[W3C.REC-html401-19991224] Raggett, D., Hors, A., and I. Jacobs, «HTML 4.01 Specification», World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.

Приложение А. Благодарности

Благодарим Дэвида Бута (David Booth), Дейва Крокера (Dave Crocker), Тима Брея (Tim Bray), Анну ван Кестерен (Anne van Kesteren), Мартина Томсона (Martin Thomson), Эрика Уайльда (Erik Wilde), Дейва Талера (Dave Thaler) и Барри Лейбу (Barry Leiba) за их предложения и отзывы.

Адрес автора

Mark Nottingham
EMail: mnot@mnot.net
URI: http://www.mnot.net/
Nottingham