Uniform Resource Identifier (URI): Generic Syntax
obsoletes
- rfc-1808 — Relative Uniform Resource Locators
- rfc-2396 — Uniform Resource Identifiers (URI): Generic Syntax
- rfc-2732 — Format for Literal IPv6 Addresses in URL's
updated by
updates
- rfc-1738 — Uniform Resource Locators (URL)
also
- std-66
Extracted elements (429)
A URI only provides identification; access to the resource is neither guaranteed nor implied by its presence. Operations on a URI are defined by the protocol or data format in which it appears, not by this specification — this separates identification from interaction.
A URI provides identification only; access to the resource is neither guaranteed nor implied. Operations on a URI are defined by the protocol element or data format in which it appears, not by the URI specification, allowing URIs to denote abstract concepts, people, and non-network-accessible resources.
A URI provides identification only; it does not imply or guarantee resource accessibility. Operations (access, update, retrieve) are defined by the protocols and data formats that use URIs, not by this specification. This separation allows URIs to be used purely as names.
A URI provides identification only; the presence of a URI does not imply that the resource is accessible or that access will be attempted. Operations on resources are defined by the protocols that use URIs, not by this specification, separating the concern of naming from the concern of access.
A URI provides only identification; access to the resource is neither guaranteed nor implied by the presence of a URI. Operations on a URI (access, update, replace) are defined by the protocols and data formats that use the URI, not by this specification.
Base URI establishment follows a precedence order (innermost highest): (1) base URI embedded in content, (2) base URI of the encapsulating entity, (3) URI used to retrieve the representation, (4) application-defined default. A sender of relative references is responsible for ensuring a well-defined base URI exists.
Fragment identifier semantics are defined by the media type of the retrieved representation rather than by the URI scheme, and fragment identifiers are processed solely client-side. This prevents scheme specifications from controlling selective referencing and makes new media types easier to deploy than new identification schemes.
Fragment identifiers are handled client-side by the user agent rather than by the server or scheme to prevent information providers from denying reference authors the right to refer selectively to parts of a resource. Fragment identifier semantics cannot be redefined by scheme specifications because fragment identification is orthogonal to scheme definition.
Fragment identifiers are intentionally processed client-side only and not sent to the origin server, preventing information providers from denying reference authors the right to selectively refer to portions of a resource. This also makes deploying new media types easier than defining new URI schemes, since fragment semantics are media-type-defined.
Fragment identifiers are processed solely by the user agent and never sent to the server. This design prevents resource providers from blocking selective referencing by clients and makes it easier to deploy new media types without defining new URI schemes.
Fragment identifiers are separated from the URI before any dereference and processed solely by the user agent. This prevents information providers from denying reference authors the right to link to specific portions of a resource, and keeps fragment semantics media-type-defined rather than scheme-defined.
Future specifications should use the general term "URI" rather than the more restrictive "URL" or "URN". The URL/URN distinction depends on persistence and naming authority practice, not on the scheme itself; any scheme's instances may have characteristics of both names and locators.
IPv6 literals are enclosed in square brackets ("[" and "]") to unambiguously distinguish them from the colon-delimited port in the authority component. Square brackets are the only place in URI syntax where these characters are allowed, and a version flag ("v" HEXDIG ".") is reserved for future IP literal formats.
The fragment identifier is handled client-side by design, preventing information providers from denying reference authors the right to selectively refer to information within a resource. This also allows new media types to be defined more easily than new URI schemes.
The fragment identifier is handled exclusively by the user agent and is separated from the URI before any scheme-specific dereference occurs. This design prevents resource providers from blocking selective referencing by authors and allows new media types to be deployed without new URI schemes.
The fragment identifier is processed client-side only and not passed to origin servers. This design prevents resource providers from denying reference authors the right to selectively reference portions of a resource, and makes new media types easier to deploy than new schemes.
The fragment identifier is processed exclusively by the user agent and is stripped from the URI before any scheme-specific dereference. This design prevents resource providers from denying authors the right to refer selectively to portions of a resource, and makes fragment semantics orthogonal to scheme definitions.
The fragment identifier is processed exclusively client-side (by the user agent) and is stripped from the URI before any dereference operation. This design prevents information providers from controlling how reference authors selectively identify portions of a resource, and allows fragment semantics to be defined by media type rather than URI scheme.
The fragment identifier is processed solely by the user agent rather than passed to the server or handled by scheme-specific logic. This prevents resource providers from denying reference authors the right to refer to sub-parts of a resource, and makes new media type definitions easier to deploy than new URI schemes.
The fragment identifier is resolved client-side rather than sent to the server in order to prevent information providers from denying reference authors the right to selectively refer to content within a resource. This also lets new media types define their own fragment semantics without requiring new URI schemes.
The fragment identifier is resolved entirely client-side and is not sent to the origin server. This design prevents information providers from denying reference authors the right to link selectively to portions of a resource, and keeps fragment semantics extensible via media type definitions without requiring new URI schemes.
The fragment identifier is separated from the rest of the URI prior to scheme-specific dereference and processed solely by the user agent, making it independent of URI scheme. This prevents information providers from denying reference authors the right to refer selectively to parts of a resource.
The fragment identifier is separated from the URI before any server interaction and processed solely by the user agent. This client-side handling prevents information providers from denying reference authors the right to selectively refer to parts of a resource, and makes it easier to add new media types than new URI schemes.
The generic URI syntax is a superset of all valid URIs so that a parser can extract the five major components without knowing scheme-specific requirements. This decouples the evolution of identification schemes from the evolution of protocols and implementations that use URIs, allowing future schemes to be defined independently.
The generic URI syntax is defined as a superset of all URI scheme syntaxes, enabling scheme-independent parsing of common components (scheme, authority, path, query, fragment) without knowing scheme-specific requirements. This decouples the evolution of identification schemes from the evolution of protocols, data formats, and implementations.
The generic URI syntax is intentionally a superset of all scheme-specific syntaxes, enabling scheme-independent parsing of URI references. This decouples the evolution of identification schemes from the protocols and data formats that use URIs.
The hierarchical syntax using "/", "?", and "#" enables relative references, allowing document trees to be portable across schemes and server locations. New URI scheme designers should use generic hierarchical syntax unless there are compelling reasons to forbid relative referencing within that scheme.
The hierarchical URI syntax uses "/", "?", and "#" to delimit components, enabling scheme-independent relative referencing. This allows document trees to be simultaneously accessible via multiple schemes (file, http, ftp) and moved without changing relative references — a key motivation for the relative-reference mechanism.
The host ABNF is intentionally ambiguous between IPv4address and reg-name; the "first-match-wins" rule resolves this: if host matches IPv4address, treat it as an IPv4 literal. Square brackets are used exclusively to delimit IP literals to allow future IP literal formats via the IPvFuture rule.
The host ABNF rule is intentionally ambiguous between IPv4address and reg-name; disambiguation uses a "first-match-wins" rule: if the host matches IPv4address, it is treated as an IPv4 literal rather than a registered name. This avoids introducing a more complex grammar.
The host subcomponent reuses DNS registration infrastructure to obtain globally unique names without deploying a separate registry — a recognized tradeoff since domain ownership can change over time in ways not anticipated by the URI producer.
The limited character set of URIs (basic Latin letters, digits, and a few symbols) was chosen primarily to support global transcription across keyboards, media, and languages; transcribability was prioritized over using the most semantically meaningful characters.
The slash ("/"), question mark ("?"), and number sign ("#") delimit the hierarchical components of a URI, enabling scheme-independent relative references. Relative references allow document trees to be partially independent of their location and access scheme, supporting portability across "file", "http", and "ftp" simultaneously.
The terms URL and URN are considered subsets of URI; future specifications should prefer the general term "URI". Whether a given URI acts as a locator or a name depends on the persistence and care of the naming authority's identifier assignment, not on the scheme itself.
The URI character set is deliberately limited to basic Latin letters, digits, and a few special characters to enable global transcription across diverse input devices, languages, and media. The ability to transcribe a URI from one medium to another (e.g., napkin to keyboard) was considered more important than using maximally meaningful character choices.
The URI character set is deliberately restricted to basic Latin letters, digits, and a small set of symbols to support global transcription across keyboards, input devices, and media (including ink on paper). Transcribability was prioritized over expressiveness with non-ASCII characters.
The URI character set is intentionally limited to basic Latin letters, digits, and a few special characters to support global transcription — the ability to write a URI on a napkin and correctly re-enter it into a computer. Transcribability was considered more important than having maximally meaningful component names.
The URI character set is limited to basic Latin letters, digits, and a few special characters to support global transcription — the ability to write a URI on a napkin and type it into any computer. Transcribability was given higher priority than using the most semantically meaningful characters.
The URI character set is limited to the basic Latin alphabet, digits, and a few special characters to permit global transcription across diverse media (paper, keyboards, screens). The ability to transcribe a URI from one medium to another was prioritized over using the most meaningful but potentially untypeable characters.
The URI character set is restricted to basic Latin letters, digits, and a few special characters to support global transcription: URIs must be enterable on keyboards across languages and locales, and readable from non-digital media (e.g., napkin, billboard). Transcribability was prioritized over expressiveness.
The URI character set is restricted to letters, digits, and a few graphic symbols from the basic Latin alphabet to support global transcription — the ability to write a URI on a napkin and type it into a computer. The ability to transcribe was considered more important than using the most meaningful characters.
The URI character set is restricted to US-ASCII letters, digits, and a few special characters to support global transcription: a URI written on a napkin must be re-enterable from any keyboard regardless of locale. Transcribability was explicitly considered more important than using the most semantically meaningful characters.
The URI generic syntax is defined as a superset of all valid URI schemes, allowing a scheme-independent parser to decompose any URI reference into its major components without knowing the scheme-specific grammar, decoupling protocol evolution from identifier evolution.
The URI syntax is a superset of all valid URI scheme syntaxes, enabling a scheme-independent generic parser to decompose any URI reference into its components without knowing scheme-specific semantics. This decouples the evolution of schemes from protocols and data formats that use URIs.
The URI syntax is hierarchically organized with components of decreasing significance from left to right, using "/", "?", and "#" as delimiters. This enables relative referencing, allowing document trees to be moved without changing internal references and to be served under multiple schemes simultaneously.
The URI syntax is intentionally a superset of all valid URI schemes, enabling a scheme-independent parser to extract major components without knowing scheme-specific requirements. This decouples the evolution of identification schemes from protocols and data formats.
The URI syntax is restricted to letters, digits, and a small set of special characters to support global transcription — the ability to write a URI on a napkin, read it, and type it on any keyboard. The ability to transcribe was considered more important than allowing the most semantically meaningful characters.
The URI syntax restricts characters to basic Latin letters, digits, and a few special characters to enable global transcription — i.e., a URI can be written on paper or a napkin and re-entered on any computer regardless of locale or keyboard. Transcribability was considered more important than meaningful components.
The URI syntax separates identification from interaction: a URI identifies a resource but neither guarantees nor implies that the resource is accessible. Operations on the resource (access, update, replace) are defined by the protocols that use URIs, not by the URI specification itself.
The URI syntax uses only basic Latin letters, digits, and a small set of special characters to prioritize global transcription across keyboards, languages, and media. The ability to reliably transcribe a URI from one medium to another was considered more important than maximizing component meaningfulness.
The URI syntax was designed with global transcription as a primary goal, restricting characters to the basic Latin alphabet, digits, and a few special characters so URIs can be written on paper and re-entered on any keyboard. The ability to transcribe a URI across media was considered more important than having maximally meaningful component names.
URI characters are restricted to a limited set (ASCII letters, digits, a few special characters) to support global transcription. The ability to copy a URI from one medium to another (e.g., from a napkin to a keyboard) was prioritized over allowing the most meaningful possible characters.
URI characters are restricted to basic Latin letters, digits, and a few special characters primarily to support global transcription: a URI must be writable on paper, typeable across keyboard layouts, and transferable between media. This requirement outweighed the goal of allowing maximally expressive component names.
URI identification is explicitly separated from interaction: a URI only identifies a resource; access is neither guaranteed nor implied by the presence of a URI. Operations on resources are defined by protocols that use URIs, not by the URI syntax itself.
URI identification is explicitly separated from resource interaction: a URI provides identification only, and access to the resource is neither guaranteed nor implied by the presence of a URI. Operations on the identified resource are defined by the protocols and data formats that use URIs, not by this specification.
URI identification is intentionally separated from interaction: the URI provides identification only; access to the resource is neither guaranteed nor implied. Operations on a URI are defined by the protocols that use it, not by the URI specification.
URI identification is intentionally separated from resource access: the URI provides identification only; the operations that may be performed on a resource are defined by the protocols that use URIs, not by the URI specification. A URI does not guarantee that a resource is accessible.
URI syntax is deliberately limited to the basic Latin alphabet, digits, and a few special characters to support global transcription—copying a URI between media such as paper and keyboard. The ability to transcribe a URI was considered more important than allowing the most semantically meaningful characters.
URI syntax is restricted to the basic Latin alphabet, digits, and a few special characters specifically to support global transcription — the ability to write a URI on paper and type it into any computer. The ability to transcribe was considered more important than having the most semantically meaningful component characters.
URI syntax uses a limited character set (letters, digits, and a few special characters) to support global transcription—the ability to write a URI on a napkin and accurately enter it on any keyboard. The ability to transcribe an identifier from one medium to another was considered more important than allowing maximally meaningful or locale-specific component names.
URIs are designed for global transcription: they consist only of basic Latin letters, digits, and a few special characters so they can be written on paper, read aloud, or entered on any keyboard. The ability to transcribe a resource identifier from one medium to another was considered more important than using the most meaningful components.
URIs provide identification, not access; the presence of a URI neither guarantees nor implies resource accessibility. Operations on a resource are defined by the protocols and data formats that use URIs — URI 'resolution' (determining an access mechanism) and 'dereferencing' (performing an action) are conceptually distinct from identification.
URIs provide identification only; access to the identified resource is neither guaranteed nor implied. Operations on URIs are defined by the protocols and data formats that use them, not by this specification — intentionally decoupling identification from interaction.
A non-strict parser may ignore a scheme in a relative reference if it is identical to the base URI's scheme — a loophole from RFC 1630 that should be avoided but is permitted for backward compatibility.
Fragment identifier semantics are defined by the media type of the potentially retrieved representation and cannot be redefined by URI schemes. If a primary resource has multiple representations, the fragment should identify the same secondary resource consistently across all of them.
IPv6 and future IP literal addresses in the host subcomponent must be enclosed in square brackets—the only place square brackets are permitted in URI syntax. An application encountering an IPvFuture literal with an unknown version flag should return an "address mechanism not supported" error rather than attempt resolution.
Non-strict parsers may treat a URI reference as relative even when it contains a scheme component identical to the base URI's scheme, a behavior identified as a loophole in RFC 1630. Strict parsers must not apply this rule; its use should be avoided but is allowed for backward compatibility.
Older, erroneous implementations may fail to separate a reference's query and/or fragment components from the path before merging with the base path, causing interoperability failures when query or fragment data contains the strings "/../" or "/./". All parsers must handle abnormal examples where more ".." segments exist than hierarchical levels in the base URI path.
Older implementations may fail to separate a reference's query or fragment component from its path before merging with the base path and removing dot-segments. This causes incorrect resolution when query strings contain the substrings "/../" or "/./".
Some older, erroneous implementations fail to separate a reference's query and/or fragment components from the path component before merging with the base path and removing dot-segments. This causes interoperability failures when query or fragment strings contain "/./" or "/../".
Some older, erroneous implementations fail to separate the query and/or fragment component from the path before merging with the base path and removing dot-segments, causing incorrect resolution when query strings contain "/../" or "/./" sequences.
Some older implementations fail to distinguish query data from path data when looking for hierarchical separators, causing incorrect behavior when "/" or "?" appear in a query component used as a base URI for relative references. URI producers may avoid percent-encoding these characters in queries for usability, but should be aware of this bug.
Some older implementations fail to separate a reference's query and fragment components from the path before merging with the base path and removing dot-segments. This causes incorrect resolution when query data contains the strings "/../" or "/./", an error that is rarely noticed in typical usage.
Some older implementations fail to separate the query and/or fragment component from the path before merging with the base path and removing dot-segments, causing interoperability failures when query components contain "/../" or "/./" strings.
Some older parsers fail to separate a reference's query or fragment from the path before merging with the base path and removing dot-segments, causing failures when query strings contain "/./" or "/../". Compliant implementations must separate all components prior to path merge.
Some parsers allow a scheme name in a relative reference when it matches the base URI's scheme (non-strict mode). This is a loophole from prior specifications; its use should be avoided but is allowed for backward compatibility.
Some parsers allow a scheme name to appear in a relative reference if it matches the base URI scheme — a loophole from RFC 1630. Its use should be avoided but is allowed for backward compatibility. Strict parsers and non-strict parsers will resolve "http:g" against an http base URI differently.
Some parsers allow a scheme name to be present in a relative reference when it is identical to the base URI scheme — a loophole in prior specifications. Its use should be avoided but is permitted for backward compatibility with implementations following RFC 1630.
Some parsers allow the same scheme name to appear in a relative reference when it matches the base URI scheme, a loophole from RFC 1630. Its use should be avoided but is allowed for backward compatibility; strict parsers treat a reference with a defined scheme as absolute.
Some parsers allow the scheme name in a relative reference if it matches the base URI scheme (a loophole in RFC 1630). Its use should be avoided but is allowed for backward compatibility; strict parsers treat it as an absolute URI.
Some parsers treat a relative reference as scheme-relative when its scheme equals the base URI's scheme (e.g., "http:g" resolved against an http base). This loophole from RFC 1630 should be avoided in new implementations but is permitted for backward compatibility; strict mode MUST treat it as an absolute URI reference.
Some parsers treat a URI reference that carries the same scheme as the base URI as a relative reference (ignoring the scheme). This is a known loophole from RFC 1630; its use should be avoided but is permitted for backward compatibility with legacy implementations.
Suffix references (e.g., "www.example.com/path") lack a standard set of disambiguation heuristics and those heuristics change over time. They should be avoided whenever possible and never used where long-term references are expected.
The "/" and "?" characters may represent data within query and fragment components, but some older erroneous implementations do not handle this correctly when such components are used as a base URI for relative reference resolution.
The fragment identifier is separated from the rest of the URI prior to any dereference and resolved solely by the user agent, regardless of URI scheme. In standard HTTP, the fragment is never transmitted to the origin server.
The host ambiguity between IPv4address and reg-name is resolved by a first-match-wins rule: if host matches IPv4address, it is treated as an IPv4 literal, not a registered name.
The IPv6address grammar in this document does not support IPv6 scoped addressing zone identifiers. The IP-literal syntax includes an IPvFuture rule to accommodate future IP literal address formats, with a version flag distinct from IP version numbers.
The "user:password" format in the userinfo field is deprecated. Applications should not render clear-text password data and may ignore or reject such data when received, as passing authentication information in clear text has proven to be a security risk.
URI equivalence should be determined using a comparison ladder: simple string comparison (always required), syntax-based normalization (percent-encoding case, default port removal, dot-segment removal), scheme-based normalization, and protocol-based normalization (e.g., HTTP HEAD). Stronger normalization reduces false inequalities at the cost of additional processing.
URI suffix references (e.g., "www.example.com/path" without a scheme) are common in traditional media but depend on context-based heuristics that change over time. They should be avoided whenever possible and must never be used where long-term references are expected.
A base URI for relative reference resolution MUST conform to the absolute-URI syntax rule and MUST be stripped of any fragment component before use. When a retrieval was the result of a redirect, the last URI used (the URI that resulted in actual retrieval) SHALL be considered the base URI.
A base URI must be established before parsing URI references that might be relative, must conform to the absolute-URI syntax rule (no fragment allowed), and must be in absolute form. If obtained from a URI reference, it must be converted to absolute form and stripped of any fragment component.
A base URI MUST conform to the absolute-URI syntax rule and MUST be stripped of any fragment component before use. Relative references can only be used reliably when the base URI is well defined; a sender of relative references is responsible for ensuring base URI establishment.
A base URI used for relative reference resolution MUST conform to the absolute-URI syntax rule and MUST be stripped of any fragment component before use. If obtained from a URI reference, it must first be converted to absolute form.
A base URI used for resolving relative references MUST conform to the absolute-URI syntax rule (scheme, hier-part, optional query, no fragment). If the base URI is obtained from a URI reference, that reference must be converted to absolute form and stripped of any fragment prior to use.
A non-ASCII registered name representing an internationalized domain name intended for DNS resolution must be transformed to IDNA encoding [RFC3490] prior to name lookup. URI producers should provide registered names in IDNA encoding rather than percent-encoding to maximize interoperability with legacy resolvers.
A path segment that contains a colon character (e.g., "this:that") MUST NOT be used as the first segment of a relative-path reference, as it would be mistaken for a scheme name; such a segment must be preceded by a dot-segment (e.g., "./this:that").
An implementation SHOULD accept uppercase letters as equivalent to lowercase in scheme names (e.g., "HTTP" as well as "http") for robustness, but SHOULD produce only lowercase scheme names for consistency.
Applications SHOULD NOT render as clear text any data after the first colon in a userinfo subcomponent unless that data is empty (indicating no password). The "user:password" format in userinfo is deprecated, as passing authentication information in clear text has proven to be a security risk in almost every case.
Applications SHOULD NOT render as cleartext any data after the first ":" in a userinfo subcomponent unless that data is an empty string. Applications MAY ignore or reject such data and SHOULD reject its storage in unencrypted form.
Data octets corresponding to reserved characters MUST be percent-encoded before a URI is formed if they would conflict with the reserved character's delimiter role. Once formed, a URI is always in its percent-encoded form.
Data that conflicts with a reserved character's delimiter role must be percent-encoded before the URI is formed. If a reserved character is found in a URI component and no delimiting role is known for it, it must be interpreted as the data octet for that character's US-ASCII encoding.
Data that would conflict with a reserved character's delimiter role must be percent-encoded before the URI is formed. A reserved character found in a component with no known delimiting role must be interpreted as the data octet for that character's US-ASCII encoding.
For consistency, URI producers and normalizers SHOULD use uppercase hexadecimal digits for all percent-encodings, and SHOULD decode percent-encoded unreserved characters to their unencoded equivalents.
For syntax-based normalization, percent-encoded octets in the ranges of unreserved characters (ALPHA, DIGIT, "-", ".", "_", "~") should not be created by URI producers and should be decoded by URI normalizers. Scheme and host components should be lowercased.
For URI comparison and normalization, implementations SHOULD perform syntax-based normalization including case normalization (scheme and host to lowercase), percent-encoding normalization (decode unreserved characters), and path segment normalization (remove dot-segments). URIs that differ only in these normalized forms are equivalent.
Fragment identifier semantics are independent of the URI scheme and cannot be redefined by scheme specifications. The fragment is separated from the rest of the URI prior to dereference and resolved solely by the user agent.
If a URI contains an authority component, the path MUST either be empty or begin with "/". If authority is absent, the path MUST NOT begin with "//".
If data for a URI component conflicts with a reserved character's delimiter role, the conflicting data MUST be percent-encoded before the URI is formed. A reserved character found in a component with no known delimiter role must be interpreted as representing the data octet for that character's US-ASCII encoding.
If data for a URI component would conflict with a reserved character's delimiter role, the conflicting data MUST be percent-encoded before the URI is formed.
Implementations MUST NOT percent-encode or decode the same string more than once, as doing so can cause a percent data octet to be misinterpreted as the start of a percent-encoding or vice versa.
Implementations SHOULD accept uppercase letters as equivalent to lowercase in scheme names for robustness, but SHOULD only produce lowercase scheme names for consistency. Documents that specify schemes MUST do so with lowercase letters.
Implementations should accept uppercase scheme names as equivalent to lowercase for robustness but should only produce lowercase scheme names for consistency. Documents specifying scheme names must use lowercase.
IPv6 literal addresses are enclosed in square brackets (the only place square brackets appear in URI syntax): IP-literal = "[" ( IPv6address / IPvFuture ) "]". An unknown IPvFuture version flag SHOULD cause an "address mechanism not supported" error.
Non-ASCII characters in a registered name MUST first be encoded as UTF-8 octets, then each octet percent-encoded. URI producing applications MUST NOT use percent-encoding in the host component unless representing a UTF-8 character sequence.
Non-ASCII registered names intended for DNS resolution MUST be transformed to the IDNA encoding [RFC3490] prior to name lookup. URI producers SHOULD supply registered names in IDNA encoding rather than percent-encoding to maximize interoperability with legacy URI resolvers.
Non-ASCII registered names MUST be encoded as UTF-8 and each octet of the UTF-8 sequence percent-encoded for representation as URI characters. URI producing applications MUST NOT use percent-encoding in the host component unless it represents a UTF-8 character sequence.
Non-ASCII registered names must first be encoded according to UTF-8 and then each octet percent-encoded. URI producing applications must not use percent-encoding in host unless it represents a UTF-8 character sequence. For internationalized domain names intended for DNS resolution, the name must be transformed to IDNA encoding prior to lookup.
Non-ASCII registered names representing internationalized domain names intended for DNS resolution MUST be transformed to IDNA encoding prior to name lookup. URI producers MUST NOT use percent-encoding in the host subcomponent unless it represents a UTF-8 character sequence.
Only the dotted-decimal form of four decimal octets (0–255) is allowed for IPv4 addresses in URIs. URI producing applications MUST NOT use percent-encoding in host unless it is used to represent a UTF-8 character sequence. Non-ASCII registered names for DNS MUST be transformed to IDNA encoding prior to name lookup.
Percent-encoded octets corresponding to unreserved characters SHOULD NOT be created by URI producers and SHOULD be decoded to their unreserved character equivalents by URI normalizers.
Percent-encoded octets in the unreserved ranges (ALPHA, DIGIT, hyphen, period, underscore, tilde) should not be created by URI producers and should be decoded to their unreserved character equivalents by URI normalizers.
Percent-encoded octets in unreserved ranges (ALPHA, DIGIT, hyphen, period, underscore, tilde) should not be produced by URI producers, and normalizers should decode them to their unreserved character equivalents.
Scheme-based normalization allows applying scheme-specific default values: for example, omitting an empty port or default port (e.g., port 80 for http), normalizing an empty path to "/" when an authority is present, and treating an absent userinfo the same as an empty userinfo.
Scheme names are case-insensitive; an implementation SHOULD accept uppercase letters as equivalent to lowercase (e.g., "HTTP" as well as "http") for robustness but SHOULD produce only lowercase scheme names for consistency.
Scheme names are case-insensitive, but canonical form is lowercase. Documents specifying schemes MUST use lowercase letters. Implementations SHOULD accept uppercase letters as equivalent to lowercase for robustness but SHOULD only produce lowercase scheme names.
Scheme names are case-insensitive, but the canonical form is lowercase. Documents specifying schemes MUST use lowercase letters, and implementations SHOULD accept uppercase equivalents for robustness but SHOULD only produce lowercase.
Scheme names are case-insensitive; implementations should accept uppercase letters as equivalent to lowercase but should only produce lowercase scheme names for consistency.
Scheme names begin with a letter followed by any mix of letters, digits, "+", "-", or ".". Although schemes are case-insensitive, the canonical form is lowercase; implementations should accept uppercase for robustness but must only produce lowercase scheme names.
Scheme-specific resolution processes should flag a URI reference that violates scheme-specific restrictions as an error rather than silently ignoring unused parts, reducing equivalent URIs and helping detect abuses of the generic syntax.
Scheme-specific resolution SHOULD flag a URI that violates scheme-specific restrictions as an error rather than silently ignoring the unused parts, to reduce equivalent URIs and detect potential misleading constructions.
Syntax-based normalization requires: percent-encoded unreserved characters should be decoded; empty port delimiter should be omitted; scheme and host are case-insensitive and should be lowercased. Normalizing percent-encoded octets that correspond to reserved characters changes URI semantics and MUST NOT be done.
Syntax-based normalization requires that percent-encoded octets in the unreserved character ranges (ALPHA, DIGIT, "-", ".", "_", "~") should be decoded, and scheme names and host names should be lowercased, to produce a canonical URI for comparison.
Syntax-based normalization SHOULD decode percent-encoded unreserved characters, normalize scheme and host to lowercase, and omit the port delimiter and value when the port is empty or equals the scheme default.
The remove_dot_segments algorithm must be applied after path extraction to eliminate "." and ".." complete path segments from the target URI path. More ".." segments than hierarchical levels in the base path are silently consumed rather than treated as errors.
The use of "user:password" format in the userinfo subcomponent is deprecated. Applications SHOULD NOT render as clear text any data after the first colon in userinfo unless it is the empty string, and SHOULD reject storage of such data in unencrypted form.
The 'user:password' format in the userinfo field is deprecated. Applications SHOULD NOT render as clear text any data after the first colon in userinfo (unless empty), and SHOULD reject storage of such data in unencrypted form, as passing authentication in clear text has proven a security risk.
The "user:password" format in userinfo is deprecated. Applications should not render as clear text any data after the first colon in userinfo unless that data is empty, and should reject storage of such data in unencrypted form.
URI normalization requires that percent-encoded octets for unreserved characters SHOULD be decoded, the default port SHOULD be omitted, and the scheme and host SHOULD be lowercased. URIs differing only in these normalized forms are equivalent.
URI normalizers should decode percent-encoded octets in the ranges of ALPHA, DIGIT, hyphen (%2D), period (%2E), underscore (%5F), or tilde (%7E) to their corresponding unreserved characters, since such encodings are equivalent to their literal form.
URI producers and normalizers should decode percent-encoded octets in the unreserved character ranges (ALPHA, DIGIT, "-", ".", "_", "~") and should use uppercase hex digits for all percent-encodings that are retained.
URI producers and normalizers SHOULD omit the ":" delimiter separating host from port if the port component is empty, and SHOULD omit the port component entirely if its value equals the scheme's default port.
URI producers and normalizers SHOULD omit the port component and its ":" delimiter when port is empty or equals the scheme's default. A scheme MAY define a default port (e.g., HTTP defines port 80); the port type (TCP, UDP, SCTP) is defined by the URI scheme.
URI producers and normalizers SHOULD use uppercase hexadecimal digits for all percent-encodings, and SHOULD NOT create percent-encodings for characters in the unreserved set (ALPHA, DIGIT, "-", ".", "_", "~").
URI producers MUST NOT provide the IPvFuture version flag ("v" prefix) for existing IPv4 and IPv6 literal address forms. Applications encountering an IP-literal with an unknown version flag SHOULD return an error for "address mechanism not supported".
URI producers SHOULD NOT create percent-encoded octets for unreserved characters (ALPHA, DIGIT, "-", ".", "_", "~"). URI normalizers SHOULD decode such encodings to their corresponding unreserved characters, as URIs differing only in that way identify the same resource.
URI producers should use names that conform to DNS syntax for registered names even when DNS is not immediately apparent, and should limit these names to no more than 255 characters in length.
URI producing applications MUST NOT use percent-encoding in the host component unless it is used to represent a UTF-8 character sequence. Non-ASCII registered names must first be encoded as UTF-8, then each octet percent-encoded.
URI producing applications SHOULD percent-encode data octets corresponding to reserved characters unless the URI scheme explicitly allows those characters as data. If a reserved character appears with no known delimiting role, it MUST be interpreted as the data octet for that character in US-ASCII.
URI scheme specifications MUST define their own syntax so that all strings matching the scheme-specific syntax also match the absolute-URI grammar. Scheme specifications must not define fragment identifier syntax, as fragment identification is orthogonal to scheme definition.
Use of the format "user:password" in the userinfo field is deprecated. Applications SHOULD NOT render as clear text any data after the first colon in a userinfo subcomponent unless the data after the colon is the empty string.
Use of the "user:password" format in the userinfo field is deprecated. Applications SHOULD NOT render as clear text any data after the first colon in a userinfo subcomponent, and SHOULD reject storage of such data in unencrypted form.
Use of "user:password" format in the userinfo subcomponent is deprecated. Applications SHOULD NOT render as clear text any data after the first colon in userinfo unless that data is empty, and SHOULD reject storage of such data in unencrypted form.
Use of "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon in userinfo unless that data is the empty string, and should reject storage of such data in unencrypted form.
When a new URI scheme component represents Universal Character Set text, data SHOULD first be encoded as UTF-8 octets, and only those octets outside the unreserved set should be percent-encoded. This ensures non-ASCII characters are represented uniformly.
When a new URI scheme defines a component representing textual data from UCS, the data SHOULD first be encoded as UTF-8 octets; then only those octets not in the unreserved set SHOULD be percent-encoded.
When a new URI scheme defines components representing Unicode text, the data SHOULD first be encoded as UTF-8 octets, and then only octets outside the unreserved set SHOULD be percent-encoded.
When a new URI scheme defines textual components from the Universal Character Set (UCS), data SHOULD first be encoded as UTF-8 octets, then only octets not corresponding to unreserved characters SHOULD be percent-encoded.
When a new URI scheme represents textual data from UCS, the data SHOULD first be encoded as UTF-8 octets, then only octets outside the unreserved set should be percent-encoded.
When a non-ASCII registered name is an internationalized domain name intended for DNS resolution, it MUST be transformed to IDNA encoding prior to name lookup. URI producers SHOULD provide such names in IDNA encoding rather than percent-encoding to maximize interoperability with legacy resolvers.
When a non-ASCII registered name represents an internationalized domain name intended for DNS resolution, the name MUST be transformed to the IDNA encoding prior to name lookup. URI producers SHOULD provide IDNA-encoded names rather than percent-encoding to maximize interoperability.
When a scheme-specific parser encounters a URI violating scheme-specific restrictions, it SHOULD flag the reference as an error rather than silently ignoring unused parts, to reduce equivalent URIs and detect potential misleading constructions.
When a URI contains an authority component, the path MUST either be empty or begin with a slash ("/"). When authority is absent, the path MUST NOT begin with two slash characters ("//").
When a URI contains an IP-literal starting with "v" (an IPvFuture version flag) that an application does not recognize, the application should return an error for "address mechanism not supported" rather than attempting to dereference it.
When a URI is dereferenced, components significant to scheme-specific processing MUST be parsed and separated before percent-encoded octets within those components can be safely decoded, to prevent data being mistaken for component delimiters.
When a URI scheme defines a component carrying UCS textual data, the data SHOULD first be encoded as UTF-8 octets and only non-unreserved octets percent-encoded. URI producing applications MUST NOT use percent-encoding in the host component unless it is used to represent a UTF-8 character sequence.
When comparing URIs, syntax-based normalization requires that percent-encoded octets corresponding to unreserved characters be decoded, that scheme and host be lowercased, and that empty or default port numbers be normalized. Protocol-based normalization may use knowledge of scheme defaults (e.g., default port 80 for http) to further reduce equivalent forms.
When dereferencing a URI, components significant to scheme-specific processing MUST be parsed and separated before percent-encoded octets within those components can be safely decoded; premature decoding may cause delimiter confusion.
A fragment identifier is indicated by "#" and terminated by end of URI. Fragment semantics are defined by the media type of the retrieved representation, are independent of the URI scheme, and are processed solely by the user agent; the fragment is separated from the rest of the URI prior to any dereference and is never sent to the server.
A relative reference has the form: relative-ref = relative-part [ "?" query ] [ "#" fragment ]. It can be a network-path reference ("//…"), absolute-path reference ("/…"), or relative-path reference; a first segment containing ":" must be preceded by "./".
A relative reference is parsed as: relative-ref = relative-part [ "?" query ] [ "#" fragment ]. Three forms exist: network-path reference (begins "//"), absolute-path reference (begins "/"), and relative-path reference (no leading slash). A first path segment containing ":" must be preceded by "./" to avoid misinterpretation as a scheme.
A relative reference may be a network-path reference (begins with "//"), an absolute-path reference (begins with "/"), or a relative-path reference (no leading slash). A relative-path reference's first segment cannot contain a colon, as it would be mistaken for a scheme name; such segments must be preceded by "./".
A relative reference (relative-ref = relative-part [ "?" query ] [ "#" fragment ]) may be a network-path reference (begins "//"), absolute-path reference (begins "/"), or relative-path reference (begins with a non-slash). A path segment containing ":" cannot be the first segment of a relative-path reference and must be preceded by "./".
A relative reference uses the hierarchical URI syntax to express a target relative to a base URI: relative-ref = relative-part [ "?" query ] [ "#" fragment ]. Types include network-path references ("//"), absolute-path references ("/"), and relative-path references (no leading slash).
A scheme name must begin with a letter and may be followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-"): scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Scheme names are case-insensitive; canonical form is lowercase.
A URI consists of a hierarchical sequence of five components: scheme, authority, path, query, and fragment. The generic ABNF is: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]. The scheme and path are required; path may be empty.
A URI consists of five hierarchical components — scheme, authority, path, query, and fragment — delimited by ":" (after scheme), "//" (before authority), "?" (before query), and "#" (before fragment). Each component serves a distinct role in resource identification.
A URI has five hierarchical components: scheme, authority, path, query, and fragment, with the ABNF: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]. The scheme and path are required (path may be empty); authority, query, and fragment are optional.
A URI is composed of five hierarchical components: scheme, authority, path, query, and fragment. ABNF: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]. The scheme and path are required; path may be empty.
A URI-reference is either a URI or a relative-ref. A relative reference is identified when its prefix does not match a scheme followed by ":". Relative references may be network-path ("//"-prefixed), absolute-path ("/"-prefixed), or relative-path (no slash prefix).
A URI-reference is either an absolute URI or a relative-ref. A relative reference is resolved against a base URI using the algorithm in Section 5.2, which produces a target URI by conditionally inheriting scheme, authority, path, and query components from the base.
Base URI is established in order of precedence: (1) embedded in content, (2) from the encapsulating entity, (3) from the retrieval URI (the last URI after redirects), (4) application-defined default. A base URI must conform to the absolute-URI syntax rule.
Base URI is established with four levels of precedence (highest to lowest): (1) base URI embedded in content, (2) base URI of the encapsulating entity, (3) URI used to retrieve the representation, (4) application-defined default base URI.
Base URI precedence for resolving relative references, from highest to lowest: (1) base URI embedded in content (e.g., HTML base element), (2) base URI of the encapsulating entity (message/multipart), (3) the retrieval URI (last URI after redirects), (4) application-dependent default.
Base URI precedence from highest to lowest: (1) base URI embedded in content, (2) base URI from the encapsulating entity, (3) retrieval URI (last URI after redirects), (4) application-defined default. The innermost (highest-precedence) defined base wins.
Base URI precedence (highest to lowest): (1) base URI embedded in content (e.g., HTML <base>), (2) base URI of the encapsulating entity, (3) URI used to retrieve the representation (last URI after redirects), (4) application-defined default base URI.
Base URI precedence (highest to lowest): (1) embedded in content, (2) from the encapsulating entity, (3) the retrieval URI (last URI after redirects), (4) application-defined default. A sender of content containing relative references must ensure a base URI can be established.
Base URI precedence (innermost wins): (1) base URI embedded in content, (2) base URI from the encapsulating entity, (3) URI used to retrieve the entity, (4) application-defined default base URI. A sender of content with relative references is responsible for ensuring a base URI can be established.
Base URI precedence is established in four layers from highest to lowest: base URI embedded in content (5.1.1), base URI from the encapsulating entity such as a MIME container (5.1.2), the URI used to retrieve the representation after any redirects (5.1.3), and a default application-defined base URI (5.1.4).
Component recomposition assembles a URI string by appending scheme+":", then "//"+authority if defined, then path, then "?"+query if defined, then "#"+fragment if defined. An undefined component (separator absent) must be distinguished from an empty component (separator present with empty value).
Component recomposition assembles a URI string from parsed components by appending scheme+":", then "//"+authority if defined, then path, then "?"+query if defined, then "#"+fragment if defined. The distinction between undefined (delimiter absent) and empty (delimiter present, no value) components must be preserved.
Component recomposition reconstructs a URI string from parsed components: scheme+":", "//"+authority (if defined), path, "?"+query (if defined), "#"+fragment (if defined). An undefined component (no separator) is distinct from an empty component (separator present but empty).
Fragment identifier semantics are defined by the media type of the retrieved representation, are independent of the URI scheme, and cannot be redefined by scheme specifications. The fragment is separated from the URI before server-side dereferencing and resolved solely by the user agent.
Fragment identifiers are separated from the rest of the URI prior to dereference and are resolved solely by the user agent, independent of the URI scheme. This prevents information providers from denying reference authors the right to refer selectively to resource content.
IPv6 and future-format IP literals are enclosed in square brackets: IP-literal = "[" ( IPv6address / IPvFuture ) "]". Square brackets are not allowed anywhere else in the URI syntax. IPvFuture format uses a version flag: "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ).
Reference resolution transforms a URI reference R against a base URI into a target URI T: if R has a defined scheme, use R's components; if R has authority, take R's authority and remove_dot_segments(R.path); if R's path is empty, inherit base path and optionally query; if R's path starts with "/", use remove_dot_segments(R.path); otherwise merge base path with R.path then remove dot-segments.
Relative reference resolution is defined by a four-step precedence hierarchy for establishing the base URI: (1) base embedded in content, (2) base from the encapsulating entity, (3) the retrieval URI, (4) application-defined default. The innermost-defined base has highest precedence.
Relative references (relative-ref = relative-part [ "?" query ] [ "#" fragment ]) take advantage of the hierarchical URI syntax to express a target URI relative to a base URI. Network-path references begin with "//", absolute-path references with "/", and relative-path references with neither.
Reserved characters are divided into gen-delims (: / ? # [ ] @) and sub-delims (! $ & ' ( ) * + , ; =). Data that conflicts with a reserved character's delimiter role must be percent-encoded before the URI is formed.
Reserved characters are divided into gen-delims (":" "/" "?" "#" "[" "]" "@") used as component delimiters, and sub-delims ("!" "$" "&" "'" "(" ")" "*" "+" "," ";" "=") available for subcomponent use. URIs differing only in whether a reserved character is percent-encoded are NOT equivalent.
Reserved characters are split into gen-delims (":", "/", "?", "#", "[", "]", "@") and sub-delims ("!", "$", "&", "'", "(", ")", "*", "+", ",", ";", "="). Data that conflicts with a reserved character's delimiter role must be percent-encoded before the URI is formed.
Reserved characters are split into gen-delims (: / ? # [ ] @) used as generic component delimiters, and sub-delims (! $ & ' ( ) * + , ; =) usable as subcomponent delimiters within components.
Section 5.2 defines a normative pseudocode algorithm for resolving a relative reference against a base URI into a target URI, covering cases where the reference has a scheme, authority, empty path, absolute path, or relative path. Implementations may use other algorithms if results match.
The authority component has the form: authority = [ userinfo "@" ] host [ ":" port ]. It is introduced by "//" and terminated by the next "/", "?", "#", or end of URI. When present, the path must be empty or begin with "/".
The authority component has the form [ userinfo "@" ] host [ ":" port ], preceded by "//" and terminated by the next "/", "?", "#", or end of URI. The host subcomponent may be an IP literal enclosed in brackets, an IPv4 dotted-decimal address, or a registered name.
The authority component has the structure: authority = [ userinfo "@" ] host [ ":" port ]. It is preceded by "//" and terminated by the next "/", "?", "#", or end of URI. When authority is present, the path must be empty or begin with "/".
The base URI for resolving relative references is established in order of precedence: (1) base URI embedded in content, (2) base URI from the encapsulating entity, (3) the retrieval URI (using the last URI after redirects), (4) application-defined default. The base URI must conform to the absolute-URI syntax.
The fragment component (fragment = *( pchar / "/" / "?")) begins after "#" and extends to end of URI. Fragment semantics are defined by the media type of the retrieved representation, not by the URI scheme; fragment identifier semantics cannot be redefined by schemes.
The fragment component (fragment = *( pchar / "/" / "?" )) is indicated by "#" and is separated from the URI before dereferencing. Fragment resolution is performed solely by the user agent; its semantics are defined by the media type of the retrieved representation, not by the URI scheme.
The fragment identifier component is indicated by "#" and terminated by end of URI. Its semantics are defined by the media type of the retrieved representation and are processed solely by the user agent; fragment identifier syntax cannot be redefined by scheme specifications.
The fragment identifier (fragment = *( pchar / "/" / "?" )) is separated from the URI before dereference and is processed solely by the user agent; its semantics are defined by the media type of the retrieved representation, not by the URI scheme.
The fragment identifier (indicated by "#") allows indirect identification of a secondary resource. Its semantics are defined by the media type of the primary resource, are independent of the URI scheme, and cannot be redefined by scheme specifications. The fragment is separated before dereference and processed solely by the user agent.
The fragment identifier is indicated by "#" and terminated by end of URI. Fragment semantics are defined by the media type of the retrieved representation, are independent of the URI scheme, and cannot be redefined by scheme specifications. The fragment is separated from the URI before dereferencing and is resolved solely by the user agent.
The fragment identifier is separated from the rest of the URI by "#" and is processed solely by the user agent; it is not sent to the origin server. Fragment semantics are defined by the media type of the retrieved representation, not by the URI scheme.
The fragment identifier is separated from the URI before any dereference and is resolved solely by the user agent; it is never passed to the server. Fragment semantics are defined by the media type of the retrieved representation, not the URI scheme, and cannot be redefined by scheme specifications.
The generic URI syntax consists of five hierarchical components: scheme, authority, path, query, and fragment, expressed as: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]. The scheme and path components are required, though the path may be empty.
The host subcomponent is identified by an IP literal in square brackets (IPv6 or IPvFuture), an IPv4 address in dotted-decimal form, or a registered name. Host is case-insensitive. IPv6 literals use: IP-literal = "[" ( IPv6address / IPvFuture ) "]" — the only place square brackets are permitted in URI syntax.
The host subcomponent is IP-literal (IPv6 or IPvFuture address enclosed in square brackets), IPv4address in dotted-decimal notation, or reg-name. The first-match-wins algorithm disambiguates IPv4address from reg-name; host is case-insensitive.
The host subcomponent is one of: an IP-literal (IPv6 or IPvFuture address enclosed in "[" and "]"), an IPv4address in dotted-decimal form, or a reg-name. The first-match-wins rule disambiguates IPv4address from reg-name. IPv6 literals are the only context where square brackets are allowed in URI syntax.
The host subcomponent is one of: IP-literal (IPv6address or IPvFuture enclosed in "[" "]"), IPv4address in dotted-decimal, or reg-name. The "first-match-wins" rule disambiguates IPv4address from reg-name; host is case-insensitive.
The path component has five ABNF variants (path-abempty, path-absolute, path-noscheme, path-rootless, path-empty) to disambiguate context. If authority is present the path must be empty or begin with "/"; without authority the path cannot begin with "//".
The path component is always present (though it may be empty) and contains hierarchical identifying data. Five ABNF rules—path-abempty, path-absolute, path-noscheme, path-rootless, path-empty—cover all valid path forms. Dot-segments "." and ".." are resolved during reference resolution.
The path component is defined by five mutually exclusive ABNF rules (path-abempty, path-absolute, path-noscheme, path-rootless, path-empty) to disambiguate URI reference contexts. Dot-segments "." and ".." indicate relative hierarchy and are removed during resolution.
The path component uses five ABNF rules: path-abempty (begins with "/" or is empty), path-absolute (begins with "/" not "//"), path-noscheme (no colon in first segment), path-rootless, and path-empty. Dot-segments ("." and "..") represent relative position in the hierarchy and are removed during resolution.
The path uses five ABNF rules: path-abempty (begins with "/" or empty), path-absolute (begins with "/" but not "//"), path-noscheme (non-colon first segment), path-rootless (segment first), and path-empty. Dot-segments "." and ".." express relative position in the hierarchy and are removed during reference resolution.
The port subcomponent matches *DIGIT and follows host after a ":" delimiter. URI producers and normalizers should omit the ":" delimiter and port value if the port is empty or equals the scheme's default port.
The query component begins at the first "?" and ends at "#" or end of URI; it may contain pchar, "/", and "?". The fragment component begins at "#" and extends to end of URI; its semantics are defined by the resource's media type and processed solely by the user agent.
The query component is indicated by the first "?" and terminated by "#" or end of URI (query = *( pchar / "/" / "?" )). The fragment is indicated by "#" and extends to end of URI; fragment semantics are defined by the retrieved representation's media type, not the URI scheme, and cannot be redefined by scheme specifications.
The query component (query = *( pchar / "/" / "?")) begins after the first "?" and ends at "#" or end of URI. It carries non-hierarchical identifying data alongside the path.
The query component (query = *( pchar / "/" / "?" )) is indicated by "?" and terminated by "#" or end of URI. Query data is non-hierarchical and identifies a resource within the scope of the scheme and authority.
The reference resolution algorithm (Section 5.2.2) transforms a URI reference R against a base URI into a target URI T by selecting scheme, authority, path, query, and fragment according to which components are defined in R, always calling remove_dot_segments on the resulting path.
The reference resolution algorithm transforms a URI reference R against base URI Base into target URI T: if R has a scheme, T copies R's components directly; otherwise T inherits Base components left-to-right as R's components are absent, merging paths when both authorities are absent and R's path is non-empty and non-absolute. remove_dot_segments is always applied to the result path.
The reference transformation algorithm (Section 5.2.2) resolves a URI reference R against a base URI by selecting scheme, authority, path, and query from R or the base depending on which components of R are defined, then always taking R's fragment. The remove_dot_segments routine is applied to all resulting paths.
The relative-reference resolution algorithm (Section 5.2.2) builds a target URI by preferring the reference's own scheme, authority, and path when defined, merging paths when the reference is path-only, and always copying the reference's fragment component.
The remove_dot_segments algorithm eliminates "." and ".." complete path segments using an input/output buffer loop. Excess ".." segments beyond the root are silently absorbed; they cannot change the authority component.
The remove_dot_segments algorithm eliminates "." and ".." path segments using an input/output buffer loop, consuming prefixes "../", "./", "/./", "/../" in priority order, discarding excess ".." segments beyond the root, and never allowing dot-segments to change the authority component.
The remove_dot_segments algorithm iterates over an input buffer: prefixes "../" and "./" are removed; "/./ " and "/." are replaced with "/"; "/../" and "/.." cause removal of the last output segment; remaining segments are moved to the output buffer.
The remove_dot_segments algorithm iteratively processes a path input buffer, removing "./" and "../" prefixes, replacing "/./" with "/", removing the last output segment when "/../" is encountered, and finally removing lone "." or ".." from the buffer. The result is the normalized path.
The remove_dot_segments algorithm iteratively processes "." and ".." path segments: "./" and "../" prefixes are stripped; "/./" is replaced by "/"; "/../" removes the last output segment; isolated "." or ".." are discarded.
The remove_dot_segments algorithm processes a path input buffer left-to-right: "../" and "./" prefixes are stripped; "/./" and "/." are replaced by "/"; "/../" and "/.." remove the last output segment; lone "." or ".." are removed; otherwise the first segment is moved to output.
The remove_dot_segments algorithm processes "." and ".." complete path segments using two buffers: the input is consumed left-to-right, removing "../" and "./" prefixes, replacing "/." with "/", treating "/.." as removal of the last output segment, and moving all other segments to output. Excess ".." segments beyond the hierarchy root are silently discarded.
The remove_dot_segments algorithm processes "." and ".." path segments using an input buffer and output buffer loop, interpreting dot-segments relative to the hierarchical path and removing them before forming the target URI.
The remove_dot_segments algorithm removes "." and ".." complete path segments from a resolved path using two buffers: input is processed left-to-right handling "../", "./", "/./", and "/../" prefixes, moving segments to the output buffer.
The remove_dot_segments algorithm resolves "." and ".." complete path segments using an input/output buffer loop: "./" and "../" prefixes are stripped; "/." prefix is replaced with "/"; "/.." prefix is replaced with "/" and the last output segment is removed; lone "." or ".." are deleted; otherwise the first path segment moves to output. Excess ".." segments cannot traverse above the root.
The remove_dot_segments algorithm (Section 5.2.4) processes "." and ".." path segments using an input buffer and output buffer, consuming the input left-to-right and adjusting the output accordingly. Extra ".." segments beyond the root do not change the authority component.
The remove_dot_segments algorithm uses two string buffers to iteratively process "." (current directory) and ".." (parent directory) path segments, absorbing excess ".." segments that would escape the path root rather than treating them as errors.
The scheme component begins with a letter followed by any combination of letters, digits, "+", "-", or ".". Scheme names are case-insensitive but the canonical form is lowercase; documents specifying schemes must use lowercase letters.
The scheme component matches ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ), is case-insensitive, and must begin with a letter. Canonical form is lowercase; implementations should accept uppercase for robustness but produce only lowercase.
The scheme component matches ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Scheme names are case-insensitive but the canonical form is lowercase; documents specifying schemes must use lowercase letters.
The userinfo subcomponent matches *( unreserved / pct-encoded / sub-delims / ":" ). The "user:password" format is deprecated; applications must not render clear-text data after the first colon and should reject storage of such data unencrypted.
The userinfo subcomponent may contain a username and optional scheme-specific authorization data, delimited from the host by "@". The "user:password" format is deprecated; data after the first ":" must not be rendered as cleartext.
Unreserved characters (ALPHA / DIGIT / "-" / "." / "_" / "~") are allowed in any URI component without encoding. A URI differing from another only in the percent-encoding of an unreserved character is equivalent to it.
Unreserved characters (ALPHA / DIGIT / "-" / "." / "_" / "~") carry no special delimiting meaning and need not be percent-encoded. A URI differing from another only by replacing an unreserved character with its percent-encoded equivalent identifies the same resource.
Unreserved characters — ALPHA, DIGIT, hyphen, period, underscore, and tilde — may appear unencoded in any URI component. A URI differing only in percent-encoding of an unreserved character is equivalent to the unencoded form.
Unreserved characters—ALPHA, DIGIT, hyphen, period, underscore, tilde—may appear unencoded in any URI component. URIs differing only in replacement of an unreserved character with its percent-encoded equivalent identify the same resource.
Unreserved characters (ALPHA / DIGIT / "-" / "." / "_" / "~") may appear in a URI without percent-encoding. URIs that differ only in whether an unreserved character is percent-encoded are equivalent and identify the same resource.
Unreserved characters (ALPHA / DIGIT / "-" / "." / "_" / "~") may appear unencoded in any URI component. URIs differing only by replacement of an unreserved character with its percent-encoded equivalent are equivalent and identify the same resource.
Unreserved characters (ALPHA, DIGIT, "-", ".", "_", "~") may appear without percent-encoding in any URI component. URIs differing only in whether an unreserved character is percent-encoded or literal are equivalent and identify the same resource.
URI component recomposition reconstructs a URI string from parsed components by conditionally prepending "scheme:", "//authority", appending path, then "?query" and "#fragment" if defined. An undefined component (separator absent) is distinct from an empty component (separator present but no value).
URI normalization and comparison proceeds through a ladder of equivalence tests: simple string comparison, syntax-based normalization (case normalization, percent-encoding normalization, path segment normalization), scheme-based normalization, and protocol-based normalization. URIs differing only in percent-encoding of unreserved characters are equivalent.
IANA maintains the registry of URI schemes; the process for registering new URI schemes is defined by BCP35. This specification establishes the generic syntax that all scheme-specific syntaxes must satisfy, and the URI scheme registry maps scheme names to their defining specifications.
The IANA URI scheme registry maps scheme names to their defining specifications. Registration of new URI schemes is governed by BCP 35. Each scheme specification must define its own syntax such that all scheme-specific URIs also match the absolute-URI grammar.
The URI scheme registry, maintained by IANA, maps scheme names to their specifications. Registration of new URI schemes is governed by BCP35. Each scheme specification must define syntax ensuring all conforming strings match the absolute-URI grammar.
The URI scheme registry maintains the mapping between scheme names and their specifications. New URI scheme registration is governed by BCP35. Scheme specifications must define their own syntax so that all matching strings also match the absolute-URI grammar.
This document does not create new IANA registries but references the URI scheme registry maintained by IANA. Registration of new URI schemes is governed by BCP 35, and the scheme registry maps scheme names to their specifications.
URI schemes are registered in the URI scheme registry maintained by IANA. The process for registering new URI schemes is defined by BCP35; this document explicitly defers individual scheme syntax and semantics to separate scheme specifications.
Back-end systems that decode percent-encoded URIs before parsing component boundaries introduce path traversal and injection risks. Percent-encoded octets must not be decoded until the relevant component has been fully parsed and separated from its delimiters.
Back-end transcoding after percent-decoding can introduce unsafe characters. Systems that decode percent-encoded octets before passing data to back-end processes must ensure decoded data cannot be misinterpreted as control sequences or delimiters in the target system.
Back-end transcoding between character encodings (e.g., EBCDIC to UTF-8) can introduce double-encoding or incorrect decoding of percent-encoded octets if implementations fail to decode before transcoding, potentially producing incorrect resource identifiers.
Back-end transcoding of URI characters (e.g., when a gateway translates between character encodings) can introduce security vulnerabilities if percent-encoded reserved characters are decoded and re-encoded under a different encoding, potentially changing their interpretation as delimiters.
Back-end transcoding of URI components from one character encoding to another can expose vulnerabilities if percent-decoded octets are passed directly through the transcoding layer without re-encoding. Percent-encoded octets must be decoded only after components are fully parsed, and only before the reverse transcoding is applied.
Back-end transcoding of URI octets between character encodings can silently alter percent-encoded sequences and cause a URI to reference a different resource or bypass security checks. Percent-encoded octets must be decoded only after components are fully separated.
Back-end transcoding of URIs between character encodings can produce or consume percent-encoding sequences that represent reserved characters, changing URI semantics. Implementations must decode percent-encoded octets before applying reverse transcoding to recover local names.
Back-end transcoding of URIs by intermediaries (gateways, proxies) that re-encode percent-encoded octets under a different character set can silently transform a URI into one identifying a different resource, potentially bypassing access controls.
Back-end transcoding — where a server decodes percent-encoded URIs and re-encodes them using a different character encoding — can produce URIs that resolve to unintended resources and may be exploited to bypass access controls or inject characters not present in the original URI.
Malicious parties may construct URIs with misleading userinfo that appears to be a trusted host name (e.g., "http://good.example.com@bad.example.com/"). Applications rendering URIs for user feedback should distinguish the userinfo visually from the host component.
Malicious URIs can be constructed to mislead users about the resource being accessed, for example by embedding misleading userinfo that resembles a trusted domain name (e.g., "http://www.trusted.example.com@evil.example.com/"). Applications rendering URIs for user feedback should display userinfo distinctly.
Malicious URIs can be constructed using percent-encoding to obscure the true target, or by using relative paths that escape expected boundaries. Applications should display decoded URIs to users but must process encoded forms for access control decisions.
Malicious URIs can be crafted to mislead users, for example by embedding a trusted-looking domain in the userinfo subcomponent (e.g., "http://trusted.example.com@malicious.example.com/"). Scheme-specific parsers should flag references that violate scheme restrictions as errors rather than silently ignoring unused parts.
Malicious URIs may be crafted to mislead users, for example by embedding userinfo that visually resembles a trusted domain name (e.g., 'http://trusted.example.com@attacker.example/'). Applications should render userinfo distinctly and scheme-specific parsers should flag constraint violations as errors rather than silently ignoring unused parts.
Maliciously constructed URIs can contain misleading userinfo crafted to look like a trusted domain name (e.g., "http://trusted.example.com@evil.example.net/"). Applications rendering URIs for user feedback should visually distinguish the userinfo subcomponent from the host.
Maliciously constructed URIs can exploit alternate percent-encodings or unexpected path traversal to bypass access controls. Applications enforcing security checks on URI components must fully parse, decode, and normalize URIs before comparison, as subtle encoding differences can disguise the true target.
Maliciously constructed URIs can exploit percent-encoding to obscure the true nature of a URI (e.g., using "%2F" instead of "/" to traverse directory boundaries after server-side decoding, or encoding hostnames to bypass access controls). Implementations should apply percent-decoding only after parsing and separating the relevant component.
Maliciously constructed URIs can mislead users about the nature of the referenced resource, for example by embedding a trusted-looking string in a component that is ignored by the scheme-specific resolver. User agents should render the userinfo subcomponent visually distinct from the host to expose such deception.
Maliciously constructed URIs can mislead users, e.g., by embedding deceptive userinfo that resembles a trusted domain name before the "@" (semantic attack). Applications rendering URIs for user feedback SHOULD distinguish the userinfo subcomponent visually.
Maliciously constructed URIs can use percent-encoding, uncommon syntax, or lookalike characters to obscure the true nature of a URI from both users and automated security checks. Implementations should not blindly decode URIs before applying security policies, and scheme-specific parsers should flag references that violate scheme restrictions rather than silently ignoring unused parts.
Maliciously constructed URIs exploit percent-encoding to mislead users or bypass access controls; attackers may encode characters to avoid pattern-matching filters or to construct a URI that appears to point to a trusted host but does not. Applications must normalize before comparison.
Maliciously constructed URIs may contain misleading components such as userinfo crafted to appear like a trusted authority (e.g., "http://trusted.example.com@attacker.example.com/"). Applications rendering URIs for user feedback should distinguish userinfo visually from the host to counter such semantic attacks.
Maliciously constructed URIs may disguise the actual target resource through unusual percent-encoding, deceptive path forms, or misleading authority components. Scheme-specific resolution processes should flag URIs that violate scheme restrictions as errors rather than silently ignoring unused parts.
Maliciously constructed URIs may mislead users or exploit parsing inconsistencies. When a URI violates scheme-specific restrictions, the resolution process should flag the reference as an error rather than silently ignoring unused parts, to reduce equivalent URIs and help detect abuse of the generic syntax.
Maliciously constructed URIs may use percent-encoding, dot-segments, or scheme-specific syntax to bypass security checks in gateways or parsers. Software that validates URIs must normalize and fully parse URIs before making access-control decisions, applying the same transformation as the eventual dereference agent.
Maliciously constructed URIs may use percent-encoding, non-standard IP address formats, or unusual syntax to confuse back-end processing or bypass access controls. When a scheme-specific resolution process encounters a URI violating scheme restrictions, it should flag an error rather than silently ignore unused components.
Maliciously constructed URIs may use percent-encoding obfuscation, misleading userinfo, or unusual syntax to confuse applications or bypass access controls. Scheme-specific parsers should flag scheme-restriction violations as errors rather than silently ignoring unused parts, to reduce the set of equivalent URIs and detect abuses.
Maliciously constructed URIs may use percent-encoding tricks, obscured characters, or syntactic ambiguity to mislead users or bypass security controls. When a URI violates scheme-specific restrictions, the resolution process should flag it as an error rather than silently ignore unused parts.
Maliciously crafted userinfo subcomponents can be made to visually resemble trusted domain names (e.g., "http://trusted.example@evil.example/"). Applications should visually distinguish userinfo from the host; scheme-specific parsers should flag such URIs as errors.
Non-standard or rare IP address formats (e.g., octal, hex, mixed dotted notation) may be interpreted by some platforms but are not allowed by this grammar. An attacker can use such forms to bypass access controls or mislead users; only standard dotted-decimal IPv4 and bracket-enclosed IPv6 are valid.
Rare IP address formats — dotted-octal, dotted-hex, and single-number decimal — may be accepted by some platforms but are not valid URI syntax; only dotted-decimal IPv4 (four decimal octets) is permitted. Applications that silently normalize such forms may allow bypassing access controls based on URI comparison.
Rare IP address formats (octal, hexadecimal, fewer than four dotted-decimal octets) are accepted by some platforms but are outside the URI grammar. Implementations should reject them to prevent spoofing of IP addresses.
Rare IP address formats (octal notation, hexadecimal, or fewer than four dotted-decimal octets) may be accepted by some host platforms but are not valid URI syntax. An implementation accepting such formats could be tricked into connecting to an unexpected host.
Rare IP address formats — such as dotted notation with fewer than four parts, hexadecimal, or octal octets — may be accepted by some platforms but are not allowed by the URI grammar. Implementations accepting such forms risk being deceived about the actual network address being accessed.
Semantic attacks craft a URI whose userinfo subcomponent resembles a trusted host name (e.g., "http://trusted.example.com@evil.example.net/") to mislead users. Applications rendering URIs for user feedback SHOULD visually distinguish the userinfo subcomponent from the host.
Semantic attacks craft the userinfo subcomponent to mimic a trusted hostname, e.g., "http://trusted.example.com@evil.example.com/". Browsers and clients must distinguish userinfo from the host component; scheme-specific resolvers should flag references violating scheme syntax as errors rather than silently ignoring them.
Semantic attacks craft URIs (e.g., "http://trusted.example.com@hostile.example.com/") that visually appear to identify a trusted resource but actually identify a hostile one. Applications should render the userinfo portion distinctly and warn users.
Semantic attacks craft URIs whose display appearance suggests a trusted authority while the actual authority differs — for example, by placing a trusted domain name in the userinfo component ("http://trusted.example@evil.example/"). Applications should render userinfo in a visually distinct way to alert users.
Semantic attacks craft URIs whose userinfo or other visible components resemble trusted domain names, misleading users about the resource's actual origin. Applications rendering URIs for user feedback should visually distinguish the userinfo component from the host to prevent this confusion.
Semantic attacks craft userinfo to resemble a trusted hostname, e.g., "http://trusted.example.com@malicious.example.com/". Applications rendering URIs for user feedback SHOULD visually distinguish the userinfo subcomponent from the host to prevent such deception.
Semantic attacks exploit the complexity of URI syntax — particularly the authority component — to craft URIs that display as trustworthy to humans but resolve to malicious resources. Scheme-specific resolution should flag violations rather than silently ignoring unused parts.
Semantic attacks exploit the gap between a URI's visual appearance and its actual meaning; for example, using look-alike characters or misleading path structures to cause a user to believe they are accessing a trusted resource. URI scheme resolution processes should flag references that violate scheme-specific restrictions rather than silently ignoring unused parts.
Semantic attacks exploit the rendering of URIs to make a malicious URI appear to identify a trusted resource, for example by crafting a userinfo subcomponent that resembles a trusted domain name. Applications SHOULD render userinfo distinctly from the host to help users detect such deception.
Semantic attacks exploit the rendering of userinfo or misleading subdomains to make a URI appear to identify a trusted resource when it does not (e.g., "http://trusted.example.com@evil.example.com/"). Applications should render userinfo in a visually distinct way to aid user recognition.
Semantic attacks exploit the userinfo subcomponent to craft URIs that visually appear to identify a trusted authority but actually identify a different one — for example, 'http://trusted.example.com@evil.example.com/'. Applications rendering URIs for user feedback should distinguish the userinfo portion from the host.
Semantic attacks exploit the visual difference between what a URI appears to identify and what it actually denotes — for example, userinfo crafted to resemble a trusted domain name, or IDN homograph attacks. Applications rendering URIs for user feedback should visually distinguish the userinfo subcomponent from the host.
Semantic attacks exploit visual similarity between different URIs to mislead users. A userinfo subcomponent can be crafted to look like a trusted domain name (e.g., "http://trusted.example.com@evil.example.com/"). Applications should render userinfo distinctly from the host, and scheme-specific resolution should flag violations rather than silently ignoring unused parts.
Semantic attacks exploit visual similarity of IRIs and URIs to deceive users into trusting a hostile resource (e.g., internationalised characters that resemble ASCII). When a scheme-specific restriction is violated, the resolver should flag it as an error rather than silently ignoring unused parts.
Semantic attacks exploit visually similar characters or structures to construct a URI that appears to identify a trusted resource but actually identifies a malicious one. Scheme-specific resolution processes should flag violations as errors rather than silently ignoring unused parts.
Semantic attacks exploit visually similar characters—particularly internationalized characters that resemble ASCII letters—in registered names to construct URIs that appear to reference a trusted authority but actually dereference to a different resource. Applications rendering URIs should display userinfo distinctly and consider visual spoofing risks.
Semantic attacks exploit visually similar characters to craft URIs that appear to refer to a trusted site but actually reference a malicious one. Applications rendering URIs for user display should distinguish the userinfo subcomponent from the host to prevent misleading presentations (Section 7.6). The "user:password" format in userinfo is deprecated because transmitting credentials in clear text is a security risk.
Semantic attacks use the userinfo subcomponent (the part before "@") to make a URI appear to identify a trusted domain (e.g., "http://trusted.example.com@attacker.example.com/"). Applications rendering URIs for user feedback should visually distinguish userinfo from the host portion.
Semantic (visual spoofing) attacks craft the userinfo or path subcomponents of a URI to resemble a trusted domain name when displayed. Applications rendering URIs for users should distinguish the userinfo subcomponent visually, and scheme-specific resolution should flag URIs that violate scheme syntax rather than silently ignoring unused parts.
Sensitive information (e.g., access credentials, session tokens) should not be embedded in URIs, as URIs may appear in server logs, Referer headers, browser history, or other accessible locations. Use of 'user:password' in userinfo is explicitly deprecated for this reason.
Sensitive information — including passwords, session tokens, and personal data — should not be placed in the URI, as URIs may be stored in browser history, server logs, referrer headers, and other locations not under the user's control.
Sensitive information (passwords, session tokens, personal data) should not be embedded in a URI, as URIs appear in browser history, server logs, Referer headers, and other locations where they may be inadvertently exposed.
Sensitive information such as passwords embedded in a URI should be avoided; if present, applications must not render it in clear text. Back-end transcoding of percent-encoded octets can expose data or alter interpretation if decoding occurs before scheme-specific parsing separates components.
Sensitive information such as passwords embedded in the userinfo component is exposed in every request, referrer headers, server logs, and browser history. Passing authentication information in clear text in a URI has proven a security risk in almost every case.
Sensitive information such as passwords in the userinfo component may be inadvertently exposed in log files, referrer headers, or browser history. The use of the "user:password" format in URIs has proven to be a security risk and is deprecated.
Sensitive information such as passwords in userinfo or credentials in query components should not be included in URIs, as such data may be stored in logs, referrer headers, or browser history. The passing of authentication information in clear text has proven to be a security risk in virtually every case it has been used.
Sensitive information such as passwords MUST NOT be stored in the userinfo subcomponent as clear text. The "user:password" format in userinfo is deprecated; applications should not render data after the first ":" in userinfo and should reject storing it unencrypted.
Sensitive information such as passwords or personal data should not be included in a URI, as URIs are often displayed, bookmarked, logged, or transmitted in the clear. The deprecated userinfo "user:password" format in particular exposes credentials in every context where the URI appears.
Sensitive information such as passwords or private keys should not be included in URIs, as URIs are frequently logged, cached, bookmarked, and exposed in Referer headers. The userinfo subcomponent is a particular risk; its use for authentication credentials should be rejected.
Sensitive information such as passwords, session tokens, or personal data should not be included in URI components, as URIs routinely appear in HTTP Referer headers, server access logs, browser history, and bookmarks, making such data visible to unintended parties.
Sensitive information such as passwords SHOULD NOT be embedded in URIs, as URIs appear in server logs, Referer headers, and browser history in plaintext. The deprecated userinfo password field is a primary vector for accidental credential exposure.
Some platforms accept IP address forms other than dotted-decimal (octal octets, hex notation, fewer than four parts) that map to unexpected hosts. URIs containing such formats may bypass access controls; implementations should only accept the dotted-decimal IPv4 form defined in the grammar.
Some platforms accept non-decimal octet notations for IPv4 addresses (octal, hexadecimal). A URI constructed with such a form may be used to bypass access controls or security checks that compare the host string textually. Only dotted-decimal notation of four decimal octets is allowed by the grammar.
Some platforms accept non-standard dotted IP address notation (octal, hexadecimal, fewer than four octets). Only the standard dotted-decimal four-octet form is valid per this grammar; other forms may bypass security checks relying on address matching.
Some platforms accept non-standard IP address formats (octal notation, fewer than four octets, hexadecimal) that may bypass access controls. Only the standard dotted-decimal four-octet IPv4 form is permitted by the URI grammar; implementations should reject other dotted-notation forms.
Some platforms accept non-standard IP address forms (octal notation, hexadecimal, fewer than four dotted octets) that resolve to valid IPv4 addresses but are not recognized as IP literals by naive parsers. These can be used to bypass access controls; parsers should reject non-dotted-decimal IPv4 forms.
Some platforms accept non-standard IP address notations (octal, hex, fewer than four octets) that may be interpreted differently than the URI producer intended. Only the standard four-octet dotted-decimal form is permitted by the URI grammar; applications should reject other forms.
Some platforms accept rare IP address formats (octal, hexadecimal, or fewer than four dotted-decimal octets) that are not allowed by the URI grammar. These non-standard formats may bypass security checks that rely on recognizing address forms, and implementations should be alert to their use.
Some platforms interpret non-standard dotted IP address notations (octal, hexadecimal, fewer than four octets) that differ from the dotted-decimal form required by this grammar. This can be exploited to bypass access controls that compare the textual host string rather than the resolved address.
Some platforms interpret non-standard IP address formats (octal, hexadecimal, fewer than four dotted-decimal parts) that differ from the RFC 3986 grammar. An application may be misled into connecting to a different host than expected if it fails to reject these forms.
Some platforms interpret non-standard IP address notations (octal, hexadecimal, fewer than four octets) that appear to differ from well-known addresses but resolve to them. Only dotted-decimal quad notation is allowed by this grammar; implementations should be alert to non-standard forms that may bypass address-based access controls.
URIs can be constructed maliciously to look like a trusted resource while actually directing the user elsewhere. Scheme-specific parsers should flag scheme-constraint violations as errors rather than ignoring unused parts, to detect potential misleading URIs.
URIs can be maliciously constructed to mislead users, particularly via the userinfo subcomponent crafted to look like a trusted host name (e.g., "http://trusted.example.com@evil.example.net/"). Applications should render userinfo distinctly from the host to aid user recognition.
Use of the "user:password" format in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon within a userinfo subcomponent and should reject storage of such data in unencrypted form. The passing of authentication information in clear text has proven to be a security risk in nearly every case.
Relative reference resolution (Section 5.2.2) transforms a reference R against base URI B into target URI T: if R has a scheme, use R entirely; else if R has an authority, use R's authority and apply remove_dot_segments to R's path; else if R's path is empty, inherit base path (and optionally base query); else merge paths and remove dot segments. The fragment always comes from R.
Relative reference resolution transforms reference R against base URI B via a precedence algorithm: if R has a scheme, use R almost directly; if R has authority, use B's scheme with R's remaining parts; if R has empty path, inherit B's path (and optionally B's query); otherwise merge B's path with R's relative path. Dot-segments are removed from the target path at each applicable step. The fragment always comes from R.
The reference resolution algorithm (Section 5.2.2) transforms a URI reference R into target URI T by: if R has a scheme, use R's components verbatim; else if R has authority, use base scheme plus R's components; else merge paths from base URI and apply remove_dot_segments.
The reference resolution algorithm transforms a URI reference R against a base URI Base into target URI T. If R has a scheme, T takes R's components directly (with dot-segments removed). If R lacks a scheme but has an authority, T takes R's authority and path. Otherwise, T inherits base components progressively: authority, then path (merged with base path and dot-segments removed), then query, always appending R's fragment.
The remove_dot_segments algorithm processes a path using two buffers: remove leading "../" or "./"; replace "/./" or "/." (as complete segment) with "/"; replace "/../" or "/.." with "/" and pop the last output segment; remove final lone "." or ".."; otherwise move the first path segment to the output. This normalizes all dot-segments in a referenced path.
The remove_dot_segments algorithm processes path input iteratively: removing leading "../" or "./" prefixes, replacing "/./ " with "/", replacing "/../" with "/" while removing the last output segment, discarding lone "." or "..", and otherwise moving the first segment to output.
The remove_dot_segments algorithm processes two buffers: (A) strip leading "../" or "./"; (B) replace "/./" or "/. (end)" with "/"; (C) replace "/../" or "/.. (end)" with "/" and remove last output segment; (D) remove isolated "." or ".."; (E) otherwise move the first path segment to the output. This removes invalid or extraneous dot-segments before forming the target URI.
A percent-encoded octet is encoded as a character triplet: the percent character "%" followed by two hexadecimal digits representing the octet's numeric value (e.g., "%20" for SP). Uppercase hex digits A-F are equivalent to lowercase a-f.
A percent-encoded octet is represented as a character triplet: pct-encoded = "%" HEXDIG HEXDIG. The uppercase hexadecimal digits A–F are equivalent to lowercase a–f, and URIs differing only in the case of hex digits in percent-encoded octets are equivalent.
A scheme name consists of a letter followed by letters, digits, "+", "-", or ".": `scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )`. Schemes are case-insensitive; the canonical form is lowercase.
A scheme name is defined as: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Schemes are case-insensitive but the canonical form is lowercase; documents that specify schemes must use lowercase letters.
A URI consists of a scheme, hier-part, optional query, and optional fragment: `URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]`. The hier-part may begin with authority (preceded by "//") followed by a path, or one of several path-only forms.
A URI scheme name must begin with a letter and be followed by any combination of letters, digits, plus (+), period (.), or hyphen (-). ABNF: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). The canonical form is lowercase.
An IP literal address (IPv6 or future versions) in a URI host is encapsulated within square brackets: IP-literal = "[" ( IPv6address / IPvFuture ) "]". This is the only place where square brackets are allowed in the URI syntax. The full IPv6address ABNF with eight 16-bit hex pieces and elision via "::" is specified.
Authority subcomponent: authority = [ userinfo "@" ] host [ ":" port ]. The host is one of: IP-literal (IPv6 or IPvFuture in square brackets), IPv4address in dotted-decimal, or reg-name. Port is *DIGIT.
IPv4 addresses in the host are represented as four decimal octets in dotted-decimal notation (dec-octet "." dec-octet "." dec-octet "." dec-octet), where dec-octet covers values 0–255. Only this form is allowed by the grammar; other dotted notations accepted by some platforms are not valid URI syntax.
IPv4 addresses in URIs must use dotted-decimal notation: four decimal octets 0–255 separated by ".". Other dotted-notation forms accepted by some platforms (octal, hex) are not allowed by the URI grammar.
IPv4 addresses in URIs must use strictly dotted-decimal notation (dec-octet "." dec-octet "." dec-octet "." dec-octet), where each octet is 0–255. Other dotted forms such as octal or hex are not permitted by the grammar.
IPv4 addresses must use strict dotted-decimal notation with four decimal octets in the range 0–255 (dec-octet). IPv6 addresses consist of eight 16-bit hex pieces separated by colons, optionally with a "::" elision for consecutive zeros, enclosed in square brackets.
IPv6 addresses in URI host are encapsulated in square brackets as IP-literal = "[" ( IPv6address / IPvFuture ) "]"; this is the only place square brackets are allowed in URI syntax. Future IP literal formats use an IPvFuture rule starting with "v" followed by a version number.
IPv6 addresses in URI host literals are enclosed in square brackets without a version flag, encoding eight 16-bit pieces in case-insensitive hex separated by colons, with optional "::" elision for consecutive zero groups and optional IPv4 representation for the least-significant 32 bits.
IPv6 addresses in URIs are enclosed in square brackets without a version flag. IPv6 syntax allows eliding consecutive zero-valued 16-bit pieces as "::" and optionally representing the least-significant 32 bits in IPv4 dotted-decimal form.
IPv6 addresses in URIs are encoded as eight colon-separated 16-bit hex pieces (h16), with optional double-colon elision of consecutive zero groups, and optionally an IPv4 suffix for the least-significant 32 bits (ls32).
IPv6 addresses in URIs must be enclosed in square brackets: IP-literal = "[" ( IPv6address / IPvFuture ) "]". Square brackets are permitted nowhere else in URI syntax. IPvFuture reserves a version-flagged extension point: "v" 1*HEXDIG "." 1*(unreserved / sub-delims / ":").
IPv6 and future IP literal addresses are enclosed in square brackets: IP-literal = "[" ( IPv6address / IPvFuture ) "]". Square brackets are permitted only in this position in the URI syntax. IPvFuture uses a version flag prefix "v" 1*HEXDIG ".".
IPv6 and future IP literal addresses in URIs are enclosed in square brackets: IP-literal = "[" ( IPv6address / IPvFuture ) "]". IPvFuture uses a version flag "v" followed by hex digits and a dot; this bracketed form is the only place square brackets are permitted in URI syntax.
IPv6 and future IP literals in the host subcomponent are enclosed in square brackets: IP-literal = "[" ( IPv6address / IPvFuture ) "]". Square brackets are permitted only here in URI syntax. IPvFuture uses a version flag: "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ).
IPv6 literal addresses are enclosed in square brackets: `IP-literal = "[" ( IPv6address / IPvFuture ) "]"`. Future address formats use an optional version flag `IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )`.
IPv6 literals are enclosed in square brackets and encoded as eight colon-separated 16-bit hex pieces; consecutive zero groups may be elided with "::". IPv4 address in dotted-decimal notation (four dec-octets 0–255 separated by ".") is the only allowed dotted form.
IPv6 literals are enclosed in square brackets: IP-literal = "[" ( IPv6address / IPvFuture ) "]". IPvFuture uses a version flag: "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":"). This is the only place square brackets are allowed in URI syntax.
Path ABNF defines five mutually exclusive rules: path-abempty (empty or starts with /), path-absolute (/ but not //), path-noscheme (no leading colon), path-rootless (begins with a segment), and path-empty. The applicable rule is determined by context (presence/absence of authority).
Percent-encoding encodes a data octet as a character triplet: "%" followed by two hexadecimal digits representing the octet's numeric value (e.g., "%20" for the space character). The ABNF rule is: pct-encoded = "%" HEXDIG HEXDIG.
Percent-encoding encodes a data octet as the character triplet "%" followed by two hexadecimal digits representing the octet's numeric value (e.g., "%20" for space). Uppercase and lowercase hex digits are equivalent, but producers and normalizers should use uppercase.
Percent-encoding represents a data octet as a triplet: the percent character "%" followed by two uppercase hexadecimal digits (`pct-encoded = "%" HEXDIG HEXDIG`). Uppercase and lowercase hex digits are equivalent; producers and normalizers should use uppercase.
Percent-encoding represents a data octet as the character triplet pct-encoded = "%" HEXDIG HEXDIG, where the two hex digits encode the octet's numeric value. Uppercase and lowercase hex digits are equivalent, but producers SHOULD use uppercase for consistency.
Query and fragment both match *( pchar / "/" / "?" ). The query begins after the first "?" and ends at "#" or end-of-URI; the fragment begins after "#" and extends to end-of-URI.
Reserved characters are divided into gen-delims (: / ? # [ ] @) and sub-delims (! $ & ' ( ) * + , ; =). These serve as delimiters within URI syntax; data conflicting with a reserved character's delimiter role must be percent-encoded before the URI is formed.
Reserved characters are split into gen-delims (`":" "/" "?" "#" "[" "]" "@"`) and sub-delims (`"!" "$" "&" "'" "(" ")" "*" "+" "," ";" "="`). Unreserved characters are `ALPHA / DIGIT / "-" / "." / "_" / "~"`.
Scheme names conform to: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Schemes are case-insensitive; the canonical form is lowercase, and scheme specifications must define their scheme names using lowercase letters.
Scheme names follow: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Schemes are case-insensitive but canonical form is lowercase; documents specifying schemes must use lowercase letters.
Scheme syntax: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Schemes are case-insensitive; the canonical form is lowercase. Implementations should accept uppercase but must produce lowercase.
The authority component has the form `authority = [ userinfo "@" ] host [ ":" port ]`. It is preceded by "//" and terminated by the next "/", "?", "#", or end of URI.
The authority component has the form [userinfo "@"] host [":" port]. IPv6 and future IP literals are enclosed in square brackets (IP-literal = "[" (IPv6address / IPvFuture) "]"), the only place square brackets are allowed in URI syntax.
The authority component has the structure: authority = [ userinfo "@" ] host [ ":" port ], preceded by "//" and terminated by the next "/", "?", "#", or end of URI. The userinfo subcomponent uses the format *( unreserved / pct-encoded / sub-delims / ":" ).
The authority component has the structure: [ userinfo "@" ] host [ ":" port ]. The host subcomponent is an IP-literal (IPv6 or future formats in square brackets), an IPv4address in dotted-decimal form, or a registered name.
The authority component is: authority = [ userinfo "@" ] host [ ":" port ]. The host is one of: IP-literal (IPv6 or IPvFuture in square brackets), IPv4address in four-octet dotted-decimal notation, or reg-name. The first-match-wins rule disambiguates IPv4address from reg-name.
The authority component is encoded as: authority = [ userinfo "@" ] host [ ":" port ]. It is preceded by "//" and terminated by the next "/", "?", "#", or end of URI.
The authority subcomponent has the structure [ userinfo "@" ] host [ ":" port ]. It is preceded by "//" and terminated by the next "/", "?", "#", or end of URI. The port delimiter ":" should be omitted when the port is empty.
The fragment identifier is indicated by "#" and terminated by end of URI. ABNF: fragment = *( pchar / "/" / "?" ). Fragment semantics are defined by the media type of the primary resource, not by the URI scheme.
The generic URI structure is: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ], where hier-part may begin with "//" authority followed by a path, or may be a path alone. Scheme and path are always present (path may be empty); authority, query, and fragment are optional.
The generic URI syntax consists of five hierarchical components: scheme, authority, path, query, and fragment. The ABNF is: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]. The scheme and path are required; path may be empty.
The generic URI syntax is defined as: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ], where hier-part may begin with "//" authority followed by path-abempty, or be a path-absolute, path-rootless, or path-empty. The scheme and path components are required, though path may be empty.
The generic URI syntax is: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ], where hier-part may be an authority with path-abempty, a path-absolute, path-rootless, or path-empty. Both the scheme and path components are required, though the path may be empty.
The host subcomponent is an IP-literal (IPv6 or IPvFuture enclosed in square brackets), an IPv4address in dotted-decimal form (four dec-octets 0–255 separated by "."), or a reg-name. Square brackets are allowed only here in URI syntax. A "first-match-wins" rule disambiguates IPv4address from reg-name.
The host subcomponent is: host = IP-literal / IPv4address / reg-name. IPv6 and future IP literal addresses are enclosed in square brackets (IP-literal = "[" ( IPv6address / IPvFuture ) "]"); IPv4 is dotted-decimal notation only.
The host subcomponent is one of: an IP-literal (IPv6 or future address in square brackets), an IPv4 address in dotted-decimal form, or a registered name (`host = IP-literal / IPv4address / reg-name`). IPv4 is disambiguated from reg-name by first-match-wins.
The host subcomponent is one of: IP-literal (IPv6address or IPvFuture enclosed in "[" and "]"), IPv4address (dotted-decimal, four octets 0-255), or reg-name (sequence of unreserved / pct-encoded / sub-delims characters). The first-match-wins rule disambiguates IPv4address from reg-name.
The host subcomponent may be an IP-literal (IPv6 or IPvFuture enclosed in square brackets), an IPv4address in dotted-decimal form, or a reg-name. ABNF: host = IP-literal / IPv4address / reg-name. The host is case-insensitive.
The path component has five ABNF variants (path-abempty, path-absolute, path-noscheme, path-rootless, path-empty) to handle the constraints that arise from the presence or absence of authority and the context of use as a relative reference.
The path component is defined by five ABNF rules (path-abempty, path-absolute, path-noscheme, path-rootless, path-empty) covering the valid combinations depending on whether authority is present and whether the path is relative. The dot-segments "." and ".." express relative position in the hierarchy.
The path component is defined by five mutually exclusive rules: path-abempty (begins with "/" or empty), path-absolute (begins with "/" but not "//"), path-noscheme (no leading colon), path-rootless, and path-empty. Dot-segments "." and ".." are removed during resolution.
The path is defined by five mutually exclusive ABNF rules (path-abempty, path-absolute, path-noscheme, path-rootless, path-empty) that enforce structural constraints: with authority, path must be empty or start with "/"; without authority, path cannot start with "//"; a relative-path reference's first segment cannot contain ":".
The port subcomponent is an optional decimal integer following the host, delimited by a single colon: port = *DIGIT. Producers and normalizers should omit the port and its ":" delimiter when port is empty or equals the scheme's default port.
The port subcomponent is defined as port = *DIGIT, an optional decimal number following the host delimited by a single colon. Producers and normalizers should omit the port and its ":" delimiter when the port is empty or equals the scheme's default.
The query component begins after the first "?" and ends at "#" or end of URI: query = *( pchar / "/" / "?" ). The fragment component begins after "#" and ends at end of URI: fragment = *( pchar / "/" / "?" ). Both allow "/" and "?" as data characters within them.
The query component begins at the first "?" and ends at "#" or end of URI (`query = *( pchar / "/" / "?" )`). The fragment begins at "#" and runs to end of URI with the same character set.
The query component begins at the first "?" character and is terminated by "#" or end of URI. ABNF: query = *( pchar / "/" / "?"). The fragment begins at "#" and extends to end of URI. ABNF: fragment = *( pchar / "/" / "?").
The query component begins with "?" and is terminated by "#" or end of URI: query = *( pchar / "/" / "?" ). The fragment component begins with "#" and extends to end of URI: fragment = *( pchar / "/" / "?" ).
The query component is indicated by "?" and terminated by "#" or end of URI: query = *( pchar / "/" / "?"). The fragment component is indicated by "#" and terminated by end of URI: fragment = *( pchar / "/" / "?").
The query component (query = *( pchar / "/" / "?" )) begins at the first "?" and ends at "#" or end of URI. The fragment component (fragment = *( pchar / "/" / "?" )) begins at "#" and extends to end of URI; both allow "/" and "?" as data characters.
The scheme component begins with a letter followed by letters, digits, "+", "-", or ".". The ABNF is: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Schemes are case-insensitive; canonical form is lowercase.
The scheme component grammar is: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ), beginning with a letter. Canonical form is lowercase; implementations should accept uppercase as equivalent but must only produce lowercase scheme names.
The scheme component is defined as: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Schemes are case-insensitive; the canonical form is lowercase, and documents specifying schemes MUST use lowercase letters.
The scheme component is encoded as: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) — it must begin with a letter. The canonical form is lowercase.
The scheme component must begin with a letter and may be followed by letters, digits, plus, period, or hyphen: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Schemes are case-insensitive; the canonical form is lowercase.
The scheme component must match: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ), i.e., it starts with a letter followed by letters, digits, plus, hyphen, or period.
The top-level URI grammar is: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ], where hier-part accommodates authority+path or path-only forms. Scheme and path are required; authority, query, and fragment are optional.
The URI generic syntax defines five hierarchical components: URI = scheme ":" hier-part ["?" query] ["#" fragment]. The scheme and path are required; authority, query, and fragment are optional.
The URI generic syntax is defined as: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ], where hier-part covers authority+path variants. The scheme and path components are required; path may be empty.
The URI generic syntax is: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ], where hier-part covers four path variants with optional authority. Scheme and path are required; authority, query, and fragment are optional components delimited by ":" "/" "?" and "#" respectively.
The URI syntax is defined as: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ], where hier-part may include an authority preceded by "//" and a path. The scheme and path components are required, though the path may be empty.
Unreserved characters (ALPHA / DIGIT / "-" / "." / "_" / "~") may appear in a URI without percent-encoding. A URI differing only in whether an unreserved character is percent-encoded identifies the same resource.
Unreserved characters (ALPHA, DIGIT, "-", ".", "_", "~") may appear unencoded in a URI; their percent-encoded equivalents identify the same resource. ABNF: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~".
Unreserved characters are defined as: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~". URIs differing only in the percent-encoding of unreserved characters identify the same resource and are semantically equivalent.
Unreserved characters — unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" — may appear in a URI without encoding. URIs that differ only in whether an unreserved character is percent-encoded or literal are equivalent and identify the same resource.