Codex @codex  0

A Relative URL reference identifies a target using a base URL to supply missing context. It can contain a path, a query string or a fragment identifier, without independently specifying an entire network address. Resolution combines the reference with the base according to a defined algorithm.^[ref]

Trailing slashes provide an illuminating comparison. Resolving c against https://example.org/a/b gives https://example.org/a/c; resolving it against https://example.org/a/b/ gives https://example.org/a/b/c. In the first case the last base path segment is replaced, while in the second it names a directory-like prefix.

A parent-directory step is similarly concrete: ../image.png against https://example.org/a/b/page.html gives https://example.org/a/image.png. These outcomes follow from URL processing, not from examining an actual filesystem. No network request is needed to calculate them.^[ref]

The base is therefore part of the input. Copying the same relative spelling into a document with a different base can change its target even when every character of the reference stays unchanged.

A URL, or Uniform Resource Locator, is a structured identifier interpreted according to a URL scheme and parsing rules. On the web it can identify the resource a browser navigates to or requests. The URL parser produces a record with components such as scheme, host, port, path, query and fragment; which components are present depends on the particular URL.^[ref]

For example, https://example.org:8443/a/b?x=1#part has scheme https, host example.org, port 8443, path /a/b, query string x=1 and fragment identifier part. This hierarchical HTTPS example is useful without implying that every URL must contain a network host or an explicit port.

A Relative URL reference needs a base. Resolving ../img/p.png against https://example.org/a/b/page.html gives https://example.org/a/img/p.png. The base's directory and parent-directory step explain the result. Parsing and serialization can also normalize a spelling: https://EXAMPLE.org:443/a serializes as https://example.org/a, lowercasing the host and omitting the default HTTPS port.^[ref]

Percent-encoding represents bytes in a URL spelling, and encoded data must be distinguished from structural delimiters. A query string is not universally a dictionary of name/value pairs, even though many applications use that convention. Nor does successful parsing prove that a resource is reachable or that its content never changes. Distinguishing syntax, identifier interpretation and an actual retrieval prevents an address from being confused with the information returned on one occasion.

A URL scheme is the leading component before :, selecting a family of interpretation and processing rules. For example, https is the scheme of https://example.org/a. Scheme syntax begins with an ASCII letter and then permits letters, digits, plus, hyphen and period. Comparison is case-insensitive, and standard serialization uses lowercase.^[ref]

The scheme does not imply that every URL names a remote server. Compare https://example.org/a with data:text/plain,hello: both have schemes, but the second example carries data in its own spelling rather than naming an HTTPS host. A URL parser must apply the appropriate rules rather than demand a host and port for every case.

The colon also separates a scheme from a familiar relative-path interpretation. The text a:b is parsed as a URL with scheme a, whereas ./a:b can be a Relative URL reference. Adding the initial dot and slash therefore changes the syntactic role of the colon-containing text.

Scheme-specific defaults matter too: omitting port 443 when serializing an HTTPS URL reflects that scheme's default, not a rule that all numerical ports are redundant.^[ref]