Uniform Resource Locator: Encyclopedia II - Uniform Resource Locator - Definition

Uniform Resource Locator - Definition

Uniform Resource Locator - URIs and URLs

Every URL is a type of Uniform Resource Identifier (URI), or, more precisely, the set of URLs is a proper subset of the set of URIs. A URI identifies a particular resource while a URL both identifies a resource and indicates how to locate it. To illustrate the distinction consider the URI urn:ietf:rfc:1738 which identifies IETF RFC 1738 without indicating where to find the text of this RFC. Now consider three URLs for three separate documents containing the text of this RFC:

• http://www.ietf.org/rfc/rfc1738.txt
• http://www.w3.org/Addressing/rfc1738.txt
• http://rfc.sunsite.dk/rfc/rfc1738.html

Each URL uniquely identifies each document and thus is a URI itself, but URL syntax is such that the identifier allows one to also locate each of these documents. Thus, a URL functions as the document's address.

Historically, the terms have been almost synonymous as almost all URIs have also been URLs. For this reason, many definitions in this article mention URIs instead of URLs; the discussion applies to both URIs and URLs.

Uniform Resource Locator - URL scheme

A URL is classified by its scheme, which typically indicates the network protocol used to retrieve a representation of the identified resource over a computer network. A URL begins with the name of its scheme, followed by a colon, followed by a scheme-specific part.

Some examples of URL schemes:

• http - HTTP resources
• https - HTTP over SSL
• ftp - File Transfer Protocol
• mailto - E-mail address
• ldap - Lightweight Directory Access Protocol lookups
• file - resources available on the local computer or over a local file sharing network
• news - Usenet newsgroups
• gopher - the Gopher protocol
• telnet - the telnet protocol
• data - the Data: URL scheme for inserting small pieces of content in place

Some of the first URL schemes, such as the still-popular "mailto", "http", "ftp", and "file" schemes, along with the general syntax of URLs, were first detailed in 1994 in Request for Comments RFC 1630, superseded within a year by the more refined RFC 1738 and RFC 1808. Some of the schemes defined in that document are still in effect, while others have fallen into disuse or have been redefined by later standards. Meanwhile, the definition of the general syntax of URLs has forked into a separate line of URI specifications: RFC 2396 (1998) and RFC 2732 (1999), both of which are obsolete but still widely referenced by URL scheme definitions; and the current standard, STD 66 / RFC 3986 (2005).

Uniform Resource Locator - Generic URL syntax

All URLs, regardless of scheme, must conform to a generic syntax. Each scheme can impart its own requirements for the syntax of the scheme-specific part, but the URL must still conform to the generic syntax.

Using a limited subset of characters compatible with the printable subset of the ASCII repertoire, the generic syntax allows a URL to represent a resource's address, regardless of the original format of the components of the address.

Schemes using typical connection-based protocols use a common "generic URI" syntax, defined below:

scheme://authority/path?query

The authority typically consists of the name or IP address of a server, optionally followed by a colon and a TCP port number. It may also contain a username and password for authenticating to the server.

The path is a specification of a location in some hierarchical structure, using a slash ("/") as delimiter between components.

The query typically expresses parameters of a dynamic query to some database residing on the server.

Uniform Resource Locator - Example: HTTP URLs

The URLs employed by HTTP, the protocol used to transmit web pages, are the most popular kind of URI and can be used as an example to demonstrate the concept of the URI. The HTTP URL syntax is:

scheme://host:port/path?parameter=value#anchor

• scheme, in the case of HTTP, is most of the time http, but https can also be used for signifying HTTP over a TLS connection (to make the connection more secure).
• Many web browsers allow the use of scheme://username:password@host:port/... for HTTP authentication. This format has been used as an exploit to make it difficult to correctly identify the server involved. Consequently, support for this format has been dropped from some browsers. Section 3.2.1 of RFC 3986 recommends that browsers should display the username / password not in the address bar, but in a different way because of the security problems mentioned and because passwords should never be displayed in clear-text.
• host, which is probably the most prominent part of a URL, is in almost all cases the domain name of a server, e.g. www.wikipedia.org, google.com, www.imv.au.dk, etc.
• The :port portion specifies a TCP port number. It is usually omitted (defaults to 80 in that case) and in the entire URL probably has the least relevance for the user.
• The path portion is used by the server (specified by host) in whatever way the server's software is set up, but in many cases it specifies a filename, possibly prepended with directory names. In the path /wiki/Cow for example, wiki would be a (pseudo-)directory and Cow would be a (pseudo-)filename.
• The part given above as ?parameter=value is referred to as query portion (sometimes search portion). It can either be omitted, have one parameter-value pair as in the example, or have many of them, which is expressed as ?para=value&anotherpara=value&.... The parameter-value pairs are only relevant if the file specified by the path is not a simple, static webpage, but some sort of automatically generated page. The generator software uses the parameter-value pairs in any way it is set up; mostly they carry information specific to one user and one moment in the use of the site, like concrete search terms, usernames, etc. (Watch, for example, how the URL in your browser's address bar behaves during a Google search: your search term is passed to some sophisticated program on google.com as a parameter, and Google's program returns a page with the search results to you.)
• The #anchor part, lastly, is called fragment identifier and refers to certain significant places inside a page; for example, this Wikipedia page has anchors at each section heading which can be referred to via the fragment ID. They are relevant if a URL should be given which, when loaded in a browser, directly jumps to a certain point in a long page. An example would be this link, which leads to this page and to the beginning of this section. (Watch how the URL in your browser's address bar changes when clicking the link.)

For another example of an HTTP URL, see below.

Uniform Resource Locator - URI references

The term URI reference means a particular instance of a URI, or portion thereof, as used in, for instance, an HTML document, in order to refer to a particular resource. A URI reference often looks just like a URL or the tail end of a URL. URI references introduce two new concepts: the distinction between absolute and relative references, and the concept of a fragment identifier.

An absolute URL is a URI reference that is just like a URL defined above; it starts with a scheme followed by a colon and then a scheme-specific part. A relative URL is a URI reference that comprises just the scheme-specific part of a URL, or some trailing component thereof. The scheme and leading components are inferred from the context in which the URL reference appears: the base URI (or base URL) of the document containing the reference.

A URI reference can also be followed by a hash sign ("#") and a pointer to within the resource referenced by the URI as a whole. This is not a part of the URI as such, but is intended for the "user agent" (browser) to interpret after a representation of the resource has been retrieved. Therefore, it is not supposed to be sent to the server in HTTP requests.

Examples of absolute URLs:

Examples of relative URLs:

• /wiki/Train
• Train#Passenger_trains

Uniform Resource Locator - Case-sensitivity

According to the current standard, the scheme and host components are case-insensitive, and when normalized during processing, should be lowercase. Other components should be assumed to be case-sensitive. However, in practice case-sensitivity of the components other than the protocol and hostname are up to the webserver and operating system of the system hosting the website.

Adapted from the Wikipedia article "Definition", under the G.N U Free Docmentation License. Please also see http://en.wikipedia.org/wiki