Per-directory well-known locations (e.g., '/images/.well-known/') were deliberately not defined because they increase the risk of colliding with preexisting site URIs and such solutions generally do not scale well due to being too 'chatty'.

http

The '/.well-known/' path prefix was chosen as a centralized 'sandbox' for well-known locations to reduce collision risks and minimize impact on preexisting URIs, rather than allowing arbitrary ad-hoc well-known locations that would usurp origin control over URI space.

http

This specification does not define how to determine the hostname for a well-known URI or the scope of discovered metadata; both are intentionally left to individual applications. Leaving scope undefined at the base level avoids encoding assumptions about inter-host relationships.

http

Well-known URIs are rooted at the top of the path hierarchy; they are not well-known in other parts of the path. '/.well-known/example' is a well-known URI, whereas '/foo/.well-known/example' is not.

http

Well-known URIs can only be used with URI schemes whose definitions explicitly allow it. The 'http' and 'https' schemes are updated by this document; 'ws' and 'wss' support is defined in RFC 8307. Other schemes must update their definitions independently.

http, websocket

Applications that wish to mint new well-known URIs MUST register them following the procedures in Section 5.1. Unregistered well-known URIs must not be created to avoid collisions.

http, registry

At a minimum, a well-known URI registration must reference a specification that defines the format and associated media type(s) to be obtained by dereferencing the well-known URI, along with the URI scheme(s) it can be used with. If no URI schemes are explicitly specified, 'http' and 'https' are assumed.

http, registry

If an application uses an alternative port rather than the default port for the given scheme, it MUST be explicitly specified by the application in question.

http

Registered names for a specific application SHOULD be correspondingly precise; 'squatting' on generic terms is not encouraged. For example, 'example-metadata' rather than 'metadata'.

http, registry

Registered names MUST conform to the 'segment-nz' production in RFC 3986, which means they cannot contain the '/' character.

http, registry

A well-known URI is a URI whose path component begins with '/.well-known/', provided that the scheme is explicitly defined to support well-known URIs. This specification enables origins to expose site-wide metadata at a predictable, registered location.

http, registry

A well-known URI registration must include at minimum: URI suffix (the name relative to '/.well-known/'), change controller, specification document(s), and status ('permanent' or 'provisional'). Optional fields include related information.

http, registry

The 'Uniform Resource Identifier (URI) Schemes' registry gains a new 'Well-Known URI Support' field (default value '-'). Initial non-default values include coap, coap+tcp, coap+ws, coaps, coaps+tcp, coaps+ws (RFC 7252/8323), http/https (RFC 8615), ws/wss (RFC 8307).

registry, http, websocket

The 'Well-Known URIs' registry at IANA (<https://www.iana.org/assignments/well-known-uris/>) tracks registered well-known URI suffixes. Registration requires Specification Required review. This document updates the procedure from RFC 5785 and adds a 'Status' column (permanent/provisional) to all entries.

registry, http

Applications must define both the scope of applicability and how to discover well-known URIs; undefined scope can cause implementation deviations and confusion. Using a well-known URI to bootstrap a separate service (e.g., finding email policy via HTTPS) can trigger floods of requests resembling DoS attacks.

security, http

Applying metadata from a well-known URI to resources on other origins (e.g., subdomains, different ports) risks administrative and security issues by implying relationships between hosts where none may exist, potentially giving an attacker control across multiple hosts.

security, http

Because well-known locations effectively represent the entire origin, server operators should appropriately control write access to them. This is especially critical when more than one entity is co-located on the same origin, and care should be taken against both external configuration and local filesystem permissions granting unwanted write access.

security, http

Some server administrators may be unaware of the '.well-known' directory's existence (especially on OSes that hide dot-prefixed directories). If an attacker gains write access to it, they can control its contents without the administrator noticing.

security, http

Well-known resources for 'http' or 'https' are accessible to Web browsers and can be manipulated by content from the same origin, including via XSS attacks. Applications should use mitigations such as application-specific media types, HttpOnly/Path-scoped cookies, X-Content-Type-Options, Content-Security-Policy, and Referrer-Policy.

security, http