Base URL precedence is defined in four layers from innermost (highest) to outermost: (1) base URL embedded in document content, (2) base URL of encapsulating entity, (3) URL used to retrieve the entity, (4) empty string (undefined). This layering allows composite documents to override retrieval context without affecting components that define their own base.

http

Parameters (';'-delimited) are excluded from relative path resolution because they do not form part of the URL path. In particular, the ';type=d' parameter on an ftp URL must not affect interpretation of relative paths, making parameter-carrying URLs safe base URLs for relative references.

http

Relative addressing allows document trees to be partially independent of their location and access scheme. A single set of hypertext documents can be simultaneously accessible via 'file', 'http', and 'ftp' schemes, and trees can be moved as a whole without changing any embedded URLs. Experience in the Web demonstrated this capability is necessary for long-term usability.

http

The resolution algorithm in Section 4 is defined as an example against which implementations can be tested; implementation of the algorithm itself is not required. Equivalent implementations (e.g., segment stacks instead of string pattern matches) are acceptable as long as they produce the same output.

http

For ftp URLs, the ';type=d' parameter to indicate a directory resource should not be used within contexts that allow relative URLs. If the retrieved directory contains relative URLs, the base URL path must include a trailing slash; using ';type=d' instead of a trailing slash creates ambiguity.

http

Path names containing a colon ':' character cannot be used as the first component of a relative URL path (e.g., 'this:that') because parsers will mistake it for a scheme name. Authors must prefix such paths with './' (preferred) or percent-encode the colon as '%3A'.

http

RFC 1738 specifies that '?' is allowed in ftp or file path segments and ';' is allowed within http path segments without defined semantics. These are believed to be errors; this document defines ';' within http paths as introducing <params> per the generic-RL syntax, and '?' in ftp/file paths is not supported in practice.

http

Some older parsers allow the scheme name to be present in a relative URL if it matches the base URL scheme (e.g., 'http:g' when base is also http). This is considered a loophole in prior specifications and should be avoided; compliant parsers must treat 'http:g' as an absolute URL resolving to '<URL:http:g>', not as a relative path.

http

The schemes 'mailto', 'news', and 'telnet' are never appropriate for use with relative URLs. Schemes 'gopher', 'prospero', and 'wais' allow reserved characters outside generic-RL syntax but may be used with relative URLs when the base URL follows generic-RL. Schemes 'file', 'ftp', 'http', and 'nntp' can always be parsed using generic-RL syntax.

http

When '..' segments outnumber hierarchical levels in the base path, the excess '..' segments cannot change the <net_loc>; the result retains the original net_loc while the path may include literal '..' components (e.g., '../../../g' from base 'http://a/b/c/d' resolves to 'http://a/../g').

http

Fragment identifiers are only inherited from the base URL when the entire embedded URL is empty. Parameters do not form part of the URL path and do not affect resolution of relative paths.

http

If retrieval of the base document was the result of a redirected request, the last URL used (i.e., that which resulted in actual retrieval) SHALL be considered the base URL, not the original request URL.

http

It is the responsibility of the distributor(s) of a document containing relative URLs to ensure that the base URL for that document can be established. Relative URLs cannot be used reliably when the document's base URL is not well-defined.

http

New URL schemes intended to be used with relative URLs are RECOMMENDED to be designed to be parsable via the generic-RL syntax, and a description of allowed relative forms should be included when a new scheme is registered per RFC 1738 Section 4.

http, registry

Parsers must be capable of consistently resolving abnormal relative URL examples, including cases with more '..' segments than hierarchical levels in the base path and cases where '.' or '..' appear as non-complete path components.

http

Systems that support relative URLs MUST be able to recognize them as part of the URL parsing process, since a relative URL may appear in any context that could hold an absolute URL.

http

The Base URL can be embedded in RFC 822-style message headers using the format: 'Base: <URL:absoluteURL>', where 'Base' is case-insensitive and whitespace inside angle brackets is ignored. This header serves as the base for relative URLs in both message headers and enclosed documents.

http, email

The generic-RL URL syntax consists of six components: <scheme>://<net_loc>/<path>;<params>?<query>#<fragment>. Each component except <scheme> may be absent. The fragment identifier is not considered part of the URL but must be recognized and set aside by parsers.

http

There are no security considerations specific to the use or parsing of relative URLs themselves. However, once a relative URL has been resolved to its absolute form, the same security considerations apply as those described in RFC 1738 for absolute URLs.

security, http

Relative URL resolution is a seven-step algorithm: (1) establish base URL; (2) parse both URLs and check if embedded is empty (inherit base) or has a scheme (treat as absolute); (3) inherit net_loc if embedded net_loc is empty; (4) if embedded path starts with '/', skip to step 7; (5) if embedded path is empty, inherit base path/params/query; (6) merge paths, removing './' and '<segment>/../' patterns iteratively; (7) recombine all components into absolute URL.

http

URL parsing proceeds through six ordered steps: (1) extract fragment after '#', (2) extract scheme before first ':', (3) extract net_loc after '//', (4) extract query after '?', (5) extract params after ';', (6) remainder is the path. Each matched substring including its delimiter is removed from the parse string before the next step.

http

The BNF grammar for relative URLs defines relativeURL as net_path | abs_path | rel_path, where net_path begins with '//', abs_path begins with '/', and rel_path may include optional params (';'-delimited) and query ('?'-delimited). The scheme is 1*(alpha | digit | '+' | '-' | '.') and escape sequences use '%' hex hex encoding.

http