Аннотация
Этот документ является одной из коллекции, которая вместе описывает протокол доступа к регистрационным данным (RDAP). Он описывает, как RDAP транспортируется с использованием протокола передачи гипертекста (HTTP). RDAP является протоколом-преемником очень старого протокола WHOIS. Цель этого документа — разъяснить использование стандартных механизмов HTTP для этого приложения.
Скачать оригинальный документ на английском языке RFC 7480 PDF
Оглавление
1. Введение
2. Терминология
3. Дизайн целей
4. Запросы
4.1. Методы HTTP
4.2. Заголовок Приёма
4.3. Параметры запроса
5. Типы HTTP-ответа
5.1. Положительные ответы
5.2. Перенаправление
5.3. Отрицательные ответы
5.4. Неверно сформированные запросы
5.5. Ограничения скорости
5.6. Обмен ресурсами между источниками (CORS)
6. Расширяемость
7. Вопросы безопасности
8. Соображения IANA
8.1. Реестр расширений RDAP
9. Вопросы интернационализации
9.1. URI и IRI
9.2. Языковые идентификаторы в запросах и ответах
9.3. Идентификаторы языка в заголовках HTTP
10. Ссылки
10.1. Нормативные ссылки
10.2. Информационные ссылки
Приложение А. Пример протокола
Приложение B. Разрушение кэша
Приложение C. Начальная загрузка и перенаправление
Благодарности
Адреса авторов
Статус этой заметки
Это документ по отслеживанию стандартов Интернета.
Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 5741.
Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc7480.
Уведомление об авторских правах
Copyright (c) 2015 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.
На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.
1. Введение
В этом документе описывается использование протокола передачи гипертекста (HTTP) [RFC7230] для протокола доступа к регистрационным данным (RDAP). Цель этого документа состоит в том, чтобы связать шаблоны использования HTTP в общий профиль, применимый к различным типам служб каталогов, обслуживающих регистрационные данные, с использованием методов, основанных на архитектурном стиле переноса представительного состояния (REST) [REST]. Предоставляя различным службам каталогов общее поведение, один клиент может лучше получать данные из служб каталогов, придерживаясь этого поведения.
Регистрационные данные, которые будут представлены этой службой, являются регистрационными данными интернет-ресурса — регистрацией доменных имен и номерных интернет-ресурсов. Эти данные обычно предоставляются службами WHOIS [RFC3912], но протокол WHOIS недостаточен для современных требований к службе регистрации данных. Ожидается, что протокол замены сохранит простой транзакционный характер WHOIS, предоставляя спецификацию для запросов и ответов, перенаправление на авторитетные источники, поддержку интернационализированных доменных имен (IDN) [RFC5890] и поддержку локализованных регистрационных данных, таких как адреса и имена организаций или лиц.
При разработке этих общих шаблонов использования в этом документе представлены соображения по простому использованию HTTP. Там, где может возникнуть сложность, цель этого документа — разместить его на сервере и сделать клиента максимально простым. Реализация клиента должна быть возможной с использованием стандартных инструментов сценариев операционной системы (например, bash и wget).
Это базовый шаблон использования для этого протокола:
1. Клиент определяет соответствующий сервер для запроса вместе с соответствующим базовым унифицированным указателем ресурса (URL) для использования в таких запросах. [RFC7484] описывает один метод для определения сервера и базового URL. См. Приложение C для получения дополнительной информации.
2. Клиент отправляет запрос HTTP (или HTTPS), используя GET [RFC7231]. Например, URL-адрес запроса для регистрации сети 192.0.2.0 может быть
http://example.com/rdap/ip/192.0.2.0
[RFC7482] детализирует различные запросы, используемые в RDAP.
3. Если принимающий сервер имеет информацию для запроса, он проверяет поле заголовка Accept запроса и возвращает ответ 200 с объектом ответа, соответствующим запрошенному формату. [RFC7483] подробно описывает ответ в нотации объектов JavaScript (JSON).
4. Если принимающий сервер не имеет информации для запроса, но знает, где можно найти эту информацию, он вернет ответ о перенаправлении (3xx) с полем заголовка Location, содержащим URL-адрес HTTP (S), указывающий на информация или другой сервер, о котором известно, что он знает, где находится информация. Ожидается, что клиент запросит, используя этот HTTP URL.
5. Если принимающий сервер не имеет запрашиваемой информации и не знает, где эта информация может быть найдена, он возвращает ответ 404.
6. Если принимающий сервер не ответит на запрос по соображениям политики, он вернет ответ об ошибке (4xx), указывающий причину отсутствия ответа.
Целью этого документа не является переопределение значения и семантики HTTP. Цель этого документа — разъяснить использование стандартных механизмов HTTP для этого приложения.
2. Терминология
Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].
Как отмечается в «Отчете Консультативного комитета по безопасности и стабильности (SSAC) по терминологии и структуре WHOIS» [SAC-051], термин «WHOIS» перегружен и часто относится к протоколу, услуге и данным. В соответствии с [SAC-051] этот документ описывает базовое поведение для RDAP. [SAC-051] описывает профиль протокола RDAP для реестров доменных имен (DNR), протокол доступа к данным регистрации доменных имен (DNRD-AP).
В этом документе клиент RDAP является агентом пользователя HTTP, выполняющим запрос RDAP, а сервер RDAP является сервером HTTP, предоставляющим ответ RDAP. Форматы запросов и ответов RDAP описаны в [RFC7482] и [RFC7483], а в этом документе описывается, как клиенты и серверы RDAP используют HTTP для обмена запросами и ответами. [RFC7481] описывает соображения безопасности для RDAP.
3. Дизайн целей
Есть несколько критериев проектирования, которым этот документ пытается соответствовать.
Во-первых, для получения каждого запроса требуется только один путь выполнения. Ответ может содержать ответ, отсутствие ответа или перенаправление, и от клиентов не ожидается, что они выполнят несколько путей выполнения для выполнения запроса.
Во-вторых, семантика запроса / ответа учитывает будущие и / или нестандартные форматы ответов. В этом документе отмечается только тип носителя ответа JSON [RFC7159], причем содержание ответа будет описано отдельно (см. [RFC7483]). Этот документ только описывает, как RDAP транспортируется с использованием HTTP с этим форматом.
В-третьих, этот протокол предназначен для использования всего спектра механизмов, доступных для использования с HTTP. HTTP предлагает ряд механизмов, не описанных далее в этом документе. Операторы могут использовать эти механизмы в соответствии со своей локальной политикой, включая управление кэшем, авторизацию, сжатие и перенаправление. HTTP также извлекает выгоду из масштабных инвестиций в масштабируемость, надежность и производительность, а также из-за широкого понимания программистами поведения клиентов для веб-сервисов, разработанных после REST [REST], что снижает стоимость развертывания служб каталогов регистрационных данных и клиентов. Этот протокол напрямую совместим с HTTP 2.0.
4. Запросы
4.1. Методы HTTP
Клиенты используют метод GET для получения тела ответа и метод HEAD для определения наличия данных на сервере. Клиенты ДОЛЖНЫ использовать методы HTTP GET или HEAD (см. [RFC7231]). Серверы не обязаны поддерживать другие методы HTTP; следовательно, клиенты, использующие другие методы, вероятно, не будут взаимодействовать должным образом.
Клиенты и серверы ДОЛЖНЫ поддерживать HTTPS для поддержки служб безопасности.
4.2. Заголовок Приёма
Чтобы указать серверам, что требуется ответ RDAP, клиенты включают поле заголовка Accept с типом носителя JSON, специфичным для RDAP, универсальный тип носителя JSON или оба. Серверы, получающие запрос RDAP, возвращают сущность с заголовком Content-Type, содержащим специфичный для RDAP тип носителя JSON.
Эта спецификация не определяет ответы, которые сервер возвращает на запрос с любыми другими типами мультимедиа в поле заголовка Accept или без поля заголовка Accept. Одной из возможностей будет возвращение ответа в типе носителя, подходящем для рендеринга в веб-браузере.
4.3. Параметры запроса
Серверы ДОЛЖНЫ игнорировать неизвестные параметры запроса. Использование неизвестных параметров запроса для очистки кэша описано в Приложении B.
5. Типы HTTP-ответа
В этом разделе описываются различные типы ответов, которые сервер может отправлять клиенту. Хотя ни один стандартный код ответа HTTP не запрещен к использованию, в этом разделе определяется минимальный набор кодов ответов, обычно используемых серверами, которые клиент должен понимать. Хотя некоторые клиенты могут быть построены с использованием простого инструментария, который не учитывает все эти коды ответов, более надежный клиент, учитывающий эти коды, вероятно, обеспечит лучший пользовательский опыт. Ожидается, что использование кодов и типов ответов для этого приложения, не определенных здесь, будет описано в последующих документах.
5.1. Положительные ответы
Если сервер имеет информацию, запрошенную клиентом, и желает ответить клиенту информацией в соответствии с его политиками, он возвращает этот ответ в теле ответа 200 (ОК) (см. [RFC7231]).
5.2. Перенаправление
Если сервер желает сообщить клиенту, что ответ на данный запрос можно найти в другом месте, он возвращает либо код ответа 301 (перемещено постоянно), чтобы указать постоянное перемещение, либо 302 (найдено), 303 (см. Другое) или Код ответа 307 (временное перенаправление) для указания непостоянного перенаправления, и он включает URL-адрес HTTP (S) в поле заголовка Location (см. [RFC7231]). Ожидается, что клиент выполнит последующий запрос для удовлетворения исходного запроса с использованием данного URL-адреса без какой-либо обработки URL-адреса. Другими словами, сервер должен вернуть полный URL-адрес, и клиенту не нужно преобразовывать URL-адрес, чтобы следовать ему. Серверы не обязаны возвращать URL-адрес, соответствующий [RFC7482].
Для этого приложения таким примером постоянного перемещения может быть оператор домена верхнего уровня (TLD), информирующий клиента о том, что запрашиваемая информация может быть найдена у другого оператора TLD (т. Е. Запрос на панель домена в foo.example is находится по адресу http: //foo.example/domain/bar).
Например, если клиент использует
http://serv1.example.com/weirds/domain/example.com
сервер, перенаправляющий на
https://serv2.example.net/weirds2/
установит в поле Location: значение
https://serv2.example.net/weirds2/domain/example.com
5.3. Отрицательные ответы
Если сервер желает ответить, что у него есть пустой набор результатов (то есть нет данных, соответствующим образом удовлетворяющих запросу), он возвращает код ответа 404 (не найден). Необязательно, он МОЖЕТ включать дополнительную информацию относительно отрицательного ответа в теле объекта HTTP.
Если сервер желает сообщить клиенту, что информация о запросе доступна, но не может включить эту информацию в ответ клиенту по соображениям политики, сервер ДОЛЖЕН ответить соответствующим кодом ответа вне диапазона HTTP 4xx. Клиент МОЖЕТ повторить запрос, если это соответствует соответствующему коду ответа.
5.4. Неверно сформированные запросы
Если сервер получает запрос, который он не может интерпретировать как запрос RDAP, он возвращает код ответа 400 (неверный запрос). Необязательно, он МОЖЕТ включать дополнительную информацию об этом отрицательном ответе в тело сущности HTTP.
5.5. Ограничения скорости
Некоторые серверы применяют ограничения скорости для предотвращения соскоба адреса и других злоупотреблений. Когда сервер отказывается отвечать на запрос из-за ограничений скорости, он возвращает код ответа 429 (слишком много запросов), как описано в [RFC6585]. Клиент, который получает ответ 429, ДОЛЖЕН уменьшить свою частоту запросов и соблюдать поле заголовка Retry-After, если оно есть. Серверы могут устанавливать более строгие ограничения для клиентов, которые не соблюдают заголовок Retry-After. Опционально, сервер МОЖЕТ включать дополнительную информацию об ограничении скорости в теле объекта HTTP.
Обратите внимание, что это не защита от атак типа «отказ в обслуживании» (DoS), поскольку злонамеренный клиент может игнорировать код и продолжать отправлять запросы с высокой скоростью. Сервер может использовать другой код ответа, если он не хочет сообщать клиенту, что ограничение скорости является причиной отказа в ответе.
5.6. Обмен ресурсами между источниками (CORS)
При ответе на запросы РЕКОМЕНДУЕТСЯ, чтобы серверы использовали поле заголовка Access-Control-Allow-Origin, как указано в [W3C.REC-cors-20140116]. Значение «*» подходит, когда RDAP используется для общедоступных ресурсов.
Этот заголовок (часто называемый заголовком CORS) помогает веб-приложениям в браузере, снимая ограничение «одного и того же источника» (т. Е. Браузер может загружать клиентский код RDAP с одного веб-сервера, но запрашивать данные RDAP у других).
По умолчанию браузеры не отправляют файлы cookie, если разрешены перекрестные запросы. Если для поля заголовка Access-Control-Allow-Credentials установлено значение «true», файлы cookie будут отправляться. Использование поля заголовка Access-Control-Allow-Credentials НЕ РЕКОМЕНДУЕТСЯ.
6. Расширяемость
В целях расширения этот документ определяет реестр IANA для префиксов, используемых в сериализации данных JSON [RFC7159] и сегментах пути URI (см. Раздел 8).
Префиксы и идентификаторы ДОЛЖНЫ состоять только из буквенных символов USASCII от A до Z в верхнем и нижнем регистре, числовых цифр от 0 до 9 и символа подчеркивания, и они НЕ ДОЛЖНЫ начинаться с символа подчеркивания, числовой цифры или символов «xml». ». Далее описывается создание имен JSON в ABNF [RFC5234].
name = ALPHA *( ALPHA / DIGIT / «_» )
Рисунок 1: ABNF для имен JSON
Это ограничение является объединением синтаксиса идентификатора языка программирования Ruby и синтаксиса имени элемента XML и имеет две цели. Во-первых, разработчики клиента, использующие современные языки программирования, такие как Ruby или Java, могут использовать библиотеки, которые автоматически переводят имена JSON в атрибуты или члены объекта первого порядка. Во-вторых, с помощью этих правил легко выполнить чистое сопоставление между JSON и XML.
7. Вопросы безопасности
Этот документ не предъявляет строгих требований к безопасности протокола RDAP. Однако это не ограничивает использование механизмов безопасности, предлагаемых протоколом HTTP. Это требует, чтобы клиенты и серверы RDAP ДОЛЖНЫ поддерживать HTTPS.
В этом документе даются рекомендации для реализации серверов в зависимости от DoS (раздел 5.5) и взаимодействия с существующими механизмами безопасности в клиентах HTTP (раздел 5.6).
Дополнительные соображения безопасности к протоколу RDAP описаны в [RFC7481].
8. Соображения IANA
8.1. Реестр расширений RDAP
IANA создала новую категорию в реестрах протоколов, помеченную как «Протокол доступа к регистрационным данным (RDAP)», и в этой категории создала автономный реестр с ссылками на URL-адреса, помеченный как «Расширения RDAP». Целью этого реестра является обеспечение уникальности идентификаторов расширений. Идентификатор расширения используется в качестве префикса в именах JSON и в качестве префикса сегментов пути в URL-адресах RDAP.
Производственное правило для этих идентификаторов указано в разделе 6.
В соответствии с [RFC5226] политика IANA для назначения новых значений должна быть «Требуется спецификация»: значения и их значения должны быть задокументированы в RFC или в какой-либо другой постоянной и легкодоступной ссылке, достаточно подробно, чтобы была возможна совместимость между независимыми реализациями.
Ниже приведен шаблон для регистрации расширения RDAP:
- Extension identifier (Идентификатор расширения): идентификатор расширения
- Registry operator (Оператор реестра): имя оператора реестра
- Published specification (Опубликованная спецификация): номер RFC, библиографическая ссылка или URL-адрес постоянной и легкодоступной спецификации
- Person & email address to contact for further information (Контактное лицо и адрес электронной почты для получения дополнительной информации): имена и адреса электронной почты лиц, с которыми необходимо связаться в отношении этой записи реестра
- Intended usage (Предполагаемое использование): краткие причины для этой записи реестра (как определено в [RFC5226]).
Ниже приведен пример регистрации в реестре расширений RDAP:
Идентификатор расширения: lunarNic
Оператор реестра: The Registry of the Moon, LLC
Опубликованная спецификация: http: //www.example/moon_apis/rdap
Персона и адрес электронной почты для связи для получения дополнительной информации: профессор Бернардо де ла Пас <berny@moon.example>
Использование по назначению: COMMON
9. Вопросы интернационализации
9.1. URI и IRI
Клиенты могут использовать интернационализированные идентификаторы ресурсов (IRI) [RFC3987] для внутреннего использования по своему усмотрению, но ДОЛЖНЫ преобразовывать их в URI [RFC3986] для взаимодействия с серверами RDAP. Серверы RDAP ДОЛЖНЫ использовать URI во всех ответах, и снова клиенты могут преобразовывать эти URI в IRI для внутреннего использования, как они считают нужным.
9.2. Языковые идентификаторы в запросах и ответах
В большинстве случаев клиенты, запрашивающие данные, не будут сигнализировать, что данные будут возвращены на определенном языке или сценарии. С другой стороны, когда серверы возвращают данные и знают, что данные на языке или в скрипте, данные ДОЛЖНЫ быть помечены идентификаторами языка, когда они доступны, что позволяет клиентам обрабатывать и отображать данные соответствующим образом.
[RFC7483] предоставляет такой механизм.
9.3. Идентификаторы языка в заголовках HTTP
Учитывая описание использования языковых идентификаторов в Разделе 9.2, если не указано иное, серверам СЛЕДУЕТ игнорировать поле заголовка HTTP [RFC7231] Accept-Language при формулировании ответов объекта HTTP, чтобы клиенты не связывали заголовок Accept-Language с ‘ lang ‘значения в теле сущности.
Однако серверы МОГУТ возвращать языковые идентификаторы в поле заголовка Content-Language, чтобы информировать клиентов о предполагаемом языке сообщений уровня HTTP.
10. Ссылки
10.1. Нормативные ссылки
[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3987] Duerst, M. and M. Suignard, «Internationalized Resource Identifiers (IRIs)», RFC 3987, January 2005, <http://www.rfc-editor.org/info/rfc3987>.
[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC6585] Nottingham, M. and R. Fielding, «Additional HTTP Status Codes», RFC 6585, April 2012, <http://www.rfc-editor.org/info/rfc6585>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content», RFC 7231,
June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7481] Hollenbeck, S. and N. Kong, «Security Services for the Registration Data Access Protocol (RDAP)», RFC 7481,
February 2015, <http://www.rfc-editor.org/info/rfc7481>.
[RFC7482] Newton, A. and S. Hollenbeck, «Registration Data Access Protocol (RDAP) Query Format», RFC 7482, February 2015,
<http://www.rfc-editor.org/info/rfc7482>.
[RFC7483] Newton, A. and S. Hollenbeck, «JSON Responses for the Registration Data Access Protocol (RDAP)», RFC 7483,
February 2015, <http://www.rfc-editor.org/info/rfc7483>.
[RFC7484] Blanchet, M., «Finding the Authoritative Registration Data (RDAP) Service», RFC 7484, February 2015,
<http://www.rfc-editor.org/info/rfc7484>.
[W3C.REC-cors-20140116] Kesteren, A., «Cross-Origin Resource Sharing», W3C Recommendation, REC-cors-20140116, January 2014,
<http://www.w3.org/TR/2014/REC-cors-20140116/>.
10.2. Информационные ссылки
[REST] Fielding, R. and R. Taylor, «Principled Design of the Modern Web Architecture», ACM Transactions on Internet Technology, Vol. 2, No. 2, May 2002.
[RFC3912] Daigle, L., «WHOIS Protocol Specification», RFC 3912, September 2004, <http://www.rfc-editor.org/info/rfc3912>.
[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5890] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>.
[RFC7159] Bray, T., Ed., «The JavaScript Object Notation (JSON) Data Interchange Format», RFC 7159, March 2014,
<http://www.rfc-editor.org/info/rfc7159>.
[SAC-051] Piscitello, D., Ed., «SSAC Report on Domain Name WHOIS Terminology and Structure», A report from the ICANN Security and Stability Advisory Committee (SSAC), September 2011.
[lacnic-joint-whois] LACNIC, «Joint Whois», December 2005, <ftp://anonymous@ftp.registro.br/pub/gter/gter20/02-jwhois-lacnic.pdf>.
Приложение А. Пример протокола
Чтобы продемонстрировать типичное поведение клиента и сервера RDAP, ниже приведен пример обмена, включая перенаправление. Данные в ответе были опущены для краткости, так как формат данных не описан в этом документе. Используемый здесь тип носителя описан в [RFC7483].
Пример обмена клиентом и сервером RDAP:
Client:
<TCP connect to rdap.example.com port 80>
GET /rdap/ip/203.0.113.0/24 HTTP/1.1
Host: rdap.example.com
Accept: application/rdap+jsonrdap.example.com:
HTTP/1.1 301 Moved Permanently
Location: http://rdap-ip.example.com/rdap/ip/203.0.113.0/24
Content-Length: 0
Content-Type: application/rdap+json
<TCP disconnect>Client:
<TCP connect to rdap-ip.example.com port 80>
GET /rdap/ip/203.0.113.0/24 HTTP/1.1
Host: rdap-ip.example.com
Accept: application/rdap+jsonrdap-ip.example.com:
HTTP/1.1 200 OK
Content-Type: application/rdap+json
Content-Length: 9001{ … }
<TCP disconnect>
Приложение B. Разрушение кэша
Некоторые инфраструктуры кэширования HTTP [RFC7230] не соответствуют стандартам кэширования должным образом и могут кэшировать ответы дольше, чем предусмотрено сервером. Чтобы преодолеть эти проблемы, клиенты могут использовать специальный и невероятно используемый параметр запроса со случайным значением по своему выбору. Как указано в разделе 4.3, серверы должны игнорировать неизвестные параметры, это совместимо с определением RDAP.
Пример использования неизвестного параметра запроса для очистки кэшей:
http://example.com/ip/192.0.2.0?__fuhgetaboutit=xyz123
Использование неизвестного параметра для преодоления неправильного поведения кэшей не является частью какой-либо спецификации и предлагается здесь в информационных целях.
Приложение C. Начальная загрузка и перенаправление
Традиционная модель развертывания WHOIS [RFC3912] не предоставляет механизма для определения авторитетного источника информации.
Некоторые подходы были реализованы в прошлом, в частности совместная инициатива WHOIS [lacnic-joint-whois]. Однако, помимо других недостатков, совместная WHOIS-служба реализуется с использованием прокси-серверов и сторонних рефералов.
Эти проблемы решаются в RDAP с использованием перенаправлений HTTP и начальной загрузки. Начальная загрузка обсуждается в [RFC7484]. В стесненных условиях процессы, описанные в [RFC7484], могут быть нежизнеспособными, и может возникнуть необходимость в серверах, действующих в качестве «перенаправителя».
Серверы перенаправления выдают HTTP-перенаправления клиентам, используя таблицу перенаправлений, сообщаемую [RFC7484]. На рисунке 2 показан клиент, использующий перенаправитель для начальной загрузки.
В некоторых случаях, в частности, в случае делегирования между региональными интернет-регистратурами (RIR), известными как «пространство ERX», и передачи сетей, будет выдано несколько перенаправлений HTTP. На рисунке 3 показан такой сценарий.
Благодарности
Джон Левин предоставил текст, чтобы ужесточить использование поля заголовка Accept и текст для раздела 429 ответов.
Марк Бланшет предоставил некоторые поясняющие тексты относительно использования URL-адресов с перенаправлениями, а также очень полезные отзывы во время последнего вызова рабочей группы (WGLC).
Нормативные языковые обзоры были предоставлены Мюрреем С. Кучерови, Эндрю Салливаном, Томом Харрисоном, Эдом Льюисом и Александром Майрхофером.
Жан-Филипп Дионн предоставил текст для раздела «Вопросы безопасности».
Концепция сервера перенаправителя, информативно обсуждаемая в Приложении C, была задокументирована Карлосом М. Мартинесом и Херардо Рада из LACNIC и Линлин Чжоу из CNNIC и впоследствии включена в этот документ.
Этот документ является рабочим продуктом рабочей группы IIRF «Странности», председателями которой были Олаф Колкман и Мюррей Кучерови.
Адреса авторов
Andrew Lee Newton
American Registry for Internet Numbers
3635 Concorde Parkway
Chantilly, VA 20151
United States
EMail: andy@arin.net
URI: http://www.arin.net
Byron J. Ellacott
Asia Pacific Network Information Centre
6 Cordelia Street
South Brisbane QLD 4101
Australia
EMail: bje@apnic.net
URI: http://www.apnic.net
Ning Kong
China Internet Network Information Center
4 South 4th Street, Zhongguancun, Haidian District
Beijing 100190
China
Phone: +86 10 5881 3147
EMail: nkong@cnnic.cn
