HTTP Usage in the Registration Data Access Protocol (RDAP)

RDAP is designed so each query requires only one path of execution: a response is either an answer, a 'no data' reply, or a single redirect. Clients are not expected to fork multiple execution paths. This keeps client implementation simple enough to use common scripting tools like bash and wget.

http

RDAP leverages the full range of standard HTTP mechanisms (caching, authorization, compression, redirection) rather than defining custom transport. This benefits from widespread HTTP investment in scalability, reliability, and REST-based programmer familiarity, reducing deployment cost.

http

The restriction on extension identifier syntax (union of Ruby identifier and XML element name syntax) serves two purposes: it allows modern language libraries to automatically promote JSON names to first-order object attributes, and it enables a clean JSON-to-XML mapping.

json

RDAP is forward compatible with HTTP/2.0. Servers returning redirect responses must provide a complete URL in the Location header; clients follow it without any URL transformation.

http

Some HTTP cache infrastructures do not adhere to caching standards and may cache responses longer than intended. Clients can use an improbably-named query parameter with a random value for cache busting, since servers must ignore unknown parameters per Section 4.3.

http

A client that receives a 429 (Too Many Requests) response SHOULD decrease its query rate and honor the Retry-After header field if one is present. Servers may place stricter limits upon clients that do not honor the Retry-After header.

http

Clients and servers MUST support HTTPS to support security services.

http, tls, security

Clients MUST transform Internationalized Resource Identifiers (IRIs) to URIs for interaction with RDAP servers. RDAP servers MUST use URIs in all responses.

http

Clients SHOULD use either the HTTP GET or HEAD methods for RDAP queries. Servers are under no obligation to support other HTTP methods, so clients using other methods will likely not interoperate properly.

http, snmp

It is RECOMMENDED that servers use the Access-Control-Allow-Origin header field (CORS header) when responding to queries; a value of '*' is suitable for public resources. Use of the Access-Control-Allow-Credentials header field is NOT RECOMMENDED.

http, security

Servers MUST ignore unknown query parameters. This allows clients to use unknown parameters for cache busting without causing server errors.

http

Servers SHOULD annotate returned data with language identifiers whenever available. Servers SHOULD ignore the HTTP Accept-Language header when formulating entity responses, so clients do not conflate Accept-Language with 'lang' values in the entity body.

http

A 400 (Bad Request) response is returned when the server cannot interpret the query as a valid RDAP query, optionally with additional information in the entity body.

http

A 404 (Not Found) response indicates an empty result set. When the server has information but cannot return it for policy reasons, it MUST respond with an appropriate 4xx code.

http

A positive response from an RDAP server is a 200 (OK) with the requested registration data in the response body, returned when the server has the requested information and policy permits its release.

http

RDAP clients include an Accept header with the RDAP-specific JSON media type ('application/rdap+json'), the generic JSON media type, or both. Servers return a Content-Type header containing the RDAP-specific JSON media type.

http, json

RDAP servers use 301 (Moved Permanently), 302 (Found), 303 (See Other), or 307 (Temporary Redirect) response codes with a Location header containing a complete HTTP(S) URL when redirecting clients to another authoritative source. The server must provide the full URL; clients follow it without transformation.

http

IANA created the 'RDAP Extensions' registry under a new 'Registration Data Access Protocol (RDAP)' category. The registry ensures uniqueness of extension identifiers used as prefixes in JSON names and RDAP URL path segments. Registration policy is Specification Required.

registry, json, http

RDAP clients and servers MUST support HTTPS. The 429 rate-limiting response is not a defense against DoS attacks since a malicious client can ignore it. Additional security considerations are covered in RFC 7481.

security, tls, http

RDAP extension identifiers (used as JSON name prefixes and URL path segment prefixes) MUST match the ABNF production: name = ALPHA *( ALPHA / DIGIT / '_' ). They SHOULD NOT begin with an underscore, digit, or the characters 'xml'.

json, http