ietf-corpus

rfc-1738

Uniform Resource Locators (URL)

T. Berners-Lee, L. Masinter, M. McCahill
date1994-12 streamLegacy statusPROPOSED STANDARD pages25 canonicalhttps://www.rfc-editor.org/rfc/rfc1738 doi10.17487/RFC1738 errataview
This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. [STANDARDS-TRACK]

obsoleted by

updated by

Extracted elements (29)

design-rationale §3.6

The news: URL scheme is deliberately location-independent (no host component) because USENET articles are replicated across many servers. Embedding a specific server would break access for users whose server does not carry that article.

design-rationale §3.9

The WAIS URL includes an explicit `<wtype>` field because many WAIS implementations require the client to know an object's type before retrieval, and type is returned in the search response; embedding it in the URL avoids a round-trip type lookup.

interoperability-note §3.2.2

For FTP, the '/' in a URL path does NOT necessarily correspond to the FTP root; a leading encoded slash ('%2F') in a path component forces an absolute CWD. Clients keeping control connections open across multiple URL accesses must reconnect if paths differ, because there is no common hierarchical model in FTP.

http

interoperability-note §3.7

The nntp: URL specifies a globally unique but locally inaccessible location because most NNTP servers are configured for local-client-only access. The news: form is therefore preferred for identifying news articles in a location-independent way.

email

interoperability-note §3.2.3

The `;type=<typecode>` portion of an FTP URL is optional; if omitted, the client must guess the appropriate transfer mode (ASCII vs binary) from the file name or content. This can cause interoperability problems when type detection is wrong.

http

interoperability-note §Appendix

When URLs appear in free text (email, Usenet, print), the recommended convention is to delimit them with angle brackets and a 'URL:' prefix: `<URL:...>`. Extra whitespace added for line-breaking should be ignored; whitespace must not be introduced after a hyphen because typesetters may add spurious hyphens at line ends.

normative-requirement §2.2 MUST

All unsafe characters (space, '<', '>', '"', '#', '%', '{', '}', '|', '\', '^', '~', '[', ']', '`') MUST always be encoded within a URL, regardless of the scheme.

http

normative-requirement §2.2 MUST

Characters reserved within a scheme (';', '/', '?', ':', '@', '=', '&') MUST be percent-encoded if they appear in a URL component where they are not being used for their reserved purpose; encoding a reserved character may change the semantics of a URL.

http

normative-requirement §3.2.1 MUST

If no user name or password is supplied for an FTP URL and the server requests credentials, anonymous FTP conventions MUST be used: supply user name 'anonymous' and the end user's Internet e-mail address as the password.

http

normative-requirement §2.2 MUST

Octets with no corresponding graphic US-ASCII character (00-1F hex, 7F hex, 80-FF hex) MUST be percent-encoded within a URL.

http

protocol-element §3.10

The file URL scheme (`file://<host>/<path>`) designates files on a specific host. The host may be 'localhost' or empty to mean the local machine. Unlike other schemes, file: does not specify an Internet protocol and has limited utility in network protocols.

protocol-element §3.2

The FTP URL scheme (`ftp://`) designates files and directories on FTP servers (RFC 959). Default port is 21. The url-path encodes a sequence of CWD commands and a final file name, with an optional `;type=<typecode>` suffix ('a' for ASCII, 'i' for image/binary, 'd' for directory listing).

http

protocol-element §3.4

The Gopher URL scheme (`gopher://`) encodes gophertype, selector, optional search string, and optional Gopher+ string in the path, with tab characters encoded as '%09'. Default port is 70. Gopher+ extensions use a second '%09'-delimited field.

protocol-element §3.3

The HTTP URL scheme (`http://`) takes the form `http://<host>:<port>/<path>?<searchpart>`. Default port is 80. No user name or password is allowed. The path and searchpart are both optional; '/', ';', and '?' are reserved within those components.

http

protocol-element §3.5

The mailto URL scheme takes the form `mailto:<rfc822-addr-spec>` and designates an Internet mailing address. It does not refer to a data object; there are no reserved characters, but '%' in RFC 822 addresses must be encoded.

email

protocol-element §3.6

The news URL scheme takes the form `news:<newsgroup-name>` or `news:<message-id>`. A message-id is distinguished by the presence of '@'. News URLs are location-independent and do not by themselves contain enough information to locate a single resource on a specific server.

email

protocol-element §3.7

The nntp URL scheme takes the form `nntp://<host>:<port>/<newsgroup-name>/<article-number>` with default port 119. Unlike news: URLs, it specifies a unique location, but most NNTP servers restrict access to local clients, so the news: form is preferred.

email

protocol-element §3.11

The Prospero URL scheme (`prospero://<host>:<port>/<hsoname>;<field>=<value>`) designates resources via the Prospero Directory Service. Default port is 1525. The hsoname is opaque to clients; semicolons within it must be encoded. Optional field/value pairs separated by ';' identify specific versions or attributes.

protocol-element §3.8

The telnet URL scheme (`telnet://<user>:<password>@<host>:<port>/`) designates an interactive Telnet service. Default port is 23. User and password are advisory only; clients merely suggest them to the user rather than transmitting them automatically.

protocol-element §3.9

The WAIS URL scheme has three forms: database (`wais://.../db`), search (`wais://.../db?query`), and document (`wais://.../db/wtype/wpath`). Default port is 210. The `<wtype>` field is included so that clients can retrieve documents without additional server queries for type information.

registry §4

IANA maintains a registry of URL schemes. New scheme submissions must include a resource-access algorithm, URL syntax definition, and demonstrable utility. Scheme names beginning with 'x-' are reserved for experimental use. Reserved-but-undefined scheme names include: afs, mid, cid, nfs, tn3270, mailserver, z39.50.

registry

security-consideration §6

A URL constructed with a non-default port number can cause a client to inadvertently contact a server running a different protocol. Instructions encoded in the URL may then trigger unexpected or damaging operations on that server (e.g., a Gopher URL causing a message to be sent via SMTP). Clients should treat non-default port URLs with caution.

security

security-consideration §6

Embedded encoded protocol delimiters (e.g., CR and LF for Telnet) MUST NOT be decoded before transmission. Premature decoding could allow an attacker to inject extra commands or parameters into a protocol session.

security

security-consideration §6

Including passwords directly in URLs is explicitly identified as unwise, because URLs may be logged, cached, transmitted in cleartext, or visible in browser history.

security, privacy

security-consideration §6

There is no general guarantee that a URL which at one time points to a given object will continue to do so; the same URL may later point to a different or non-existent resource due to server-side changes.

security

wire-format §2.1

A URL is written as `<scheme>:<scheme-specific-part>` where the scheme name consists of lowercase letters, digits, '+', '-', and '.'. Scheme names are case-insensitive; interpreters MUST treat uppercase as equivalent to lowercase.

http

wire-format §3.1

IP-based URL schemes use the common syntax `//<user>:<password>@<host>:<port>/<url-path>`. Parts `<user>:<password>@`, `:<password>`, `:<port>`, and `/<url-path>` are all optional. Any ':', '@', or '/' within the user or password fields must be encoded.

http

wire-format §2.2

Percent-encoding encodes an octet as the character '%' followed by exactly two uppercase or lowercase hexadecimal digits representing the octet's value (e.g., '%2F' for '/'). This is the sole mechanism for encoding arbitrary octets in a URL.

http

wire-format §5

The BNF in Section 5 formally defines the URL grammar. The `escape` production is `'%' hex hex`; `unreserved` characters are alphanumerics plus `$-_.+!*'(),`; `reserved` characters are `; / ? : @ & =`; `uchar` is unreserved or escape; `xchar` adds reserved to that set.

http