ietf-corpus

rfc-5785

Defining Well-Known Uniform Resource Identifiers (URIs)

M. Nottingham, E. Hammer-Lahav
date2010-04 streamIETF wgnon working group statusPROPOSED STANDARD pages8 canonicalhttps://www.rfc-editor.org/rfc/rfc5785 doi10.17487/RFC5785 errataview
This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK]

obsoleted by

updates

Extracted elements (14)

design-rationale §B

Per-directory well-known locations (e.g., '/images/.well-known/') were not defined because they would increase collision risk with pre-existing URIs and tend not to scale well due to being too 'chatty'.

http

design-rationale §1

The mechanism was created as a 'sandbox' for the already-common practice of designating well-known locations, reducing risks of collision between specifications and minimizing impingement upon sites' existing URI space.

http

design-rationale §B

The '/.well-known/' prefix was chosen because it is short, descriptive, and according to search indices, not widely used — minimizing collision risk with pre-existing URIs.

http

design-rationale §1.1

Well-known URIs are not intended for general information retrieval or establishing large URI namespaces, but specifically to facilitate discovery of site-wide policy or metadata when other mechanisms (HTTP headers, WebDAV PROPFIND) are impractical due to latency or deployment overhead.

http

interoperability-note §3

This specification defines neither how to determine the authority to use for a particular context nor the scope of the metadata discovered by dereferencing the well-known URI; both must be defined by the application itself.

http

interoperability-note §3

This specification does not define a format or media-type for the resource located at '/.well-known/' and clients should not expect a resource to exist at that location.

http

normative-requirement §3 MAY

A well-known URI registration MAY contain additional information such as the syntax of additional path components, query strings, fragment identifiers, or protocol-specific details like HTTP method handling.

http

normative-requirement §3 MUST

Applications that wish to mint new well-known URIs MUST register them, following the procedures in Section 5.1.

http, registry

normative-requirement §3 MUST

Registered well-known URI names MUST conform to the segment-nz production in RFC 3986.

http

protocol-element §3

A well-known URI is a URI whose path component begins with '/.well-known/', and whose scheme is 'http', 'https', or another scheme that has explicitly been specified to use well-known URIs.

http

protocol-element §5.1.1

The Well-Known URI registration template requires: URI suffix (the name relative to '/.well-known/'), change controller, specification document(s), and optionally related information.

registry, http

registry §5.1

This document establishes the Well-Known URI Registry. Registrations require Specification Required review, with requests sent to wellknown-uri-review@ietf.org; Designated Experts must approve or deny within 14 days.

registry, http

security-consideration §4

Applications using well-known URIs must consider exposure of sensitive data, denial-of-service attacks, server and client authentication, DNS rebinding attacks, and attacks where limited server access grants the ability to affect how well-known URIs are served.

security, http

security-consideration §4

This memo does not specify the scope of applicability of metadata or policy obtained from a well-known URI, nor how to discover a well-known URI for a particular application; individual applications must define both aspects.

security, http