Uniform Resource Identifier (URI): Generic Syntax

Uniform ¶

• Uniformity provides several benefits: it allows different types of resource identifiers to be used in the same context, even when the mechanisms used to access those resources may differ; it allows uniform semantic interpretation of common syntactic conventions across different types of resource identifiers; it allows introduction of new types of resource identifiers without interfering with the way that existing identifiers are used; and, it allows the identifiers to be reused in many different contexts, thus permitting new applications or protocols to leverage a pre-existing, large, and widely-used set of resource identifiers.

Resource ¶

• Anything that can be named or described can be a resource. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. A resource is not necessarily accessible via the Internet; e.g., human beings, corporations, and bound books in a library can also be resources. Likewise, abstract concepts can be resources, such as the operators and operands of a mathematical equation or the types of a relationship (e.g., "parent" or "employee").

Identifier ¶

• An identifier embodies the information required to distinguish what is being identified from all other things within its scope of identification.

A URI is an identifier that consists of a sequence of characters matching the restricted syntax defined by this specification. A URI can be used to refer to a resource. This specification does not place any limits on the nature of a resource or the reasons why an application might wish to refer to a resource. URIs have a global scope and should be interpreted consistently regardless of context, but that interpretation may be defined in relation to the user's context (e.g., "http://localhost/" refers to a resource that is relative to the user's network interface and yet not specific to any one user).¶

This document uses the Augmented Backus-Naur Form (ABNF) notation of [RFC2234] to define the URI syntax. Although the ABNF defines syntax in terms of the US-ASCII character encoding [ASCII], the URI syntax should be interpreted in terms of the character that the ASCII-encoded octet represents, rather than the octet encoding itself. How a URI is represented in terms of bits and bytes on the wire is dependent upon the character encoding of the protocol used to transport it, or the charset of the document that contains it.¶

The following core ABNF productions are used by this specification as defined by Section 6.1 of [RFC2234]: ALPHA, CR, CTL, DIGIT, DQUOTE, HEXDIG, LF, OCTET, and SP. The complete URI syntax is collected in Appendix A.¶

As described above (Section 1.3), the URI syntax is defined in terms of characters by reference to the US-ASCII encoding of characters to octets. This specification does not mandate the use of any particular mapping between its character set and the octets used to store or transmit those characters.¶

URI characters representing strings of data within a component may, if allowed by the component production, represent an arbitrary sequence of octets. For example, portions of a given URI might correspond to a filename on a non-ASCII file system, a query on non-ASCII data, numeric coordinates on a map, etc. Some URI schemes define a specific encoding of raw data to US-ASCII characters as part of their scheme-specific requirements. Most URI schemes represent data octets by the US-ASCII character corresponding to that octet, either directly in the form of the character's glyph or by use of an escape triplet (Section 2.4).¶

When a URI scheme defines a component that represents textual data consisting of characters from the Unicode (ISO 10646) character set, we recommend that the data be encoded first as octets according to the UTF-8 [UTF-8] character encoding, and then escaping any octets that are not in the unreserved character set.¶

URIs include components and sub-components that are delimited by certain special characters. These characters are called "reserved", since their usage within a URI component is limited to their reserved purpose within that component. If data for a URI component would conflict with the reserved purpose, then the conflicting data must be escaped (Section 2.4) before forming the URI.

   reserved    = "/" / "?" / "#" / "[" / "]" / ";" /
                 ":" / "@" / "&" / "=" / "+" / "$" / ","

Reserved characters are used as delimiters of the generic URI components described in Section 3, as well as within those components for delimiting sub-components. A component's ABNF syntax rule will not use the "reserved" production directly; instead, each rule lists those reserved characters that are allowed within that component. Allowed reserved characters that are not assigned a sub-component delimiter role by this specification should be considered reserved for special use by whatever software generates the URI (i.e., they may be used to delimit or indicate information that is significant to interpretation of the identifier, but that significance is outside the scope of this specification). Outside of the URI's origin, a reserved character cannot be escaped without fear of changing how it will be interpreted; likewise, an escaped octet that corresponds to a reserved character cannot be unescaped outside the software that is responsible for interpreting it during URI resolution.¶

The slash ("/"), question-mark ("?"), and crosshatch ("#") characters are reserved in all URI for the purpose of delimiting components that are significant to the generic parser's hierarchical interpretation of an identifier. The hierarchical prefix of a URI, wherein the slash ("/") character signifies a hierarchy delimiter, extends from the scheme (Section 3.1) through to the first question-mark ("?"), crosshatch ("#"), or the end of the URI string. In other words, the slash ("/") character is not treated as a hierarchical separator within the query (Section 3.4) and fragment (Section 3.5) components of a URI, but is still considered reserved within those components for purposes outside the scope of this specification.¶

Data characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase letters, decimal digits, and a limited set of punctuation marks and symbols.

   unreserved  = ALPHA / DIGIT / mark

   mark        = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"

Unreserved characters can be escaped without changing the semantics of a URI, but this should not be done unless the URI is being used in a context that does not allow the unescaped character to appear. URI normalization processes may unescape sequences in the ranges of ALPHA (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), underscore (%5F), or tilde (%7E) without fear of creating a conflict, but unescaping the other mark characters is usually counterproductive.¶

Data must be escaped if it does not have a representation using an unreserved character; this includes data that does not correspond to a printable character of the US-ASCII coded character set or corresponds to a US-ASCII character that delimits the component from others, is reserved in that component for delimiting sub-components, or is excluded from any use within a URI (Section 2.5).¶

Although they are disallowed within the URI syntax, we include here a description of those characters that have been excluded and the reasons for their exclusion.

   excluded    = invisible / delims / unwise

The control characters (CTL) in the US-ASCII coded character set are not used within a URI, both because they are non-printable and because they are likely to be misinterpreted by some control mechanisms. The space character (SP) is excluded because significant spaces may disappear and insignificant spaces may be introduced when a URI is transcribed, typeset, or subjected to the treatment of word-processing programs. Whitespace is also used to delimit a URI in many contexts. Characters outside the US-ASCII set are excluded as well.

   invisible   = CTL / SP / %x80-FF

The angle-bracket ("<" and ">") and double-quote (") characters are excluded because they are often used as the delimiters around a URI in text documents and protocol fields. The percent character ("%") is excluded because it is used for the encoding of escaped (Section 2.4) characters.

   delims      = "<" / ">" / "%" / DQUOTE

Other characters are excluded because gateways and other transport agents are known to sometimes modify such characters.

   unwise      = "{" / "}" / "|" / "\" / "^" / "`"

Data octets corresponding to excluded characters must be escaped in order to be represented within a URI.¶

Each URI begins with a scheme name that refers to a specification for assigning identifiers within that scheme. As such, the URI syntax is a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme.¶

Scheme names consist of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-"). Although scheme is case-insensitive, the canonical form is lowercase and documents that specify schemes must do so using lowercase letters. An implementation should accept uppercase letters as equivalent to lowercase in scheme names (e.g., allow "HTTP" as well as "http"), for the sake of robustness, but should only generate lowercase scheme names, for consistency.

   scheme      = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

Individual schemes are not specified by this document. The process for registration of new URI schemes is defined separately by [RFC2717]. The scheme registry maintains the mapping between scheme names and their specifications.

Many URI schemes include a hierarchical element for a naming authority, such that governance of the name space defined by the remainder of the URI is delegated to that authority (which may, in turn, delegate it further). The generic syntax provides a common means for distinguishing an authority based on a registered domain name or server address, along with optional port and user information.¶

The authority component is preceded by a double slash ("//") and is terminated by the next slash ("/"), question-mark ("?"), or crosshatch ("#") character, or by the end of the URI.

   authority   = [ userinfo "@" ] host [ ":" port ]

The parts "<userinfo>@" and ":<port>" may be omitted.

Some schemes do not allow the userinfo and/or port sub-components. When presented with a URI that violates one or more scheme-specific restrictions, the scheme-specific URI resolution process should flag the reference as an error rather than ignore the unused parts; doing so reduces the number of equivalent URIs and helps detect abuses of the generic syntax that might indicate the URI has been constructed to mislead the user (Section 7.5).¶

The path component contains hierarchical data that, along with data in the optional query (Section 3.4) component, serves to identify a resource within the scope of that URI's scheme and naming authority (if any). There is no specific "path" syntax production in the generic URI syntax. Instead, what we refer to as the URI path is that part of the parsed URI string matching either the abs-path or the rel-path production, since they are mutually exclusive for any given URI and can be parsed as a single component. The path is terminated by the first question-mark ("?") or crosshatch ("#") character, or by the end of the URI.

   path-segments = segment *( "/" segment )
   segment       = *pchar

   pchar         = unreserved / escaped / ";" /
                   ":" / "@" / "&" / "=" / "+" / "$" / ","

The path consists of a sequence of path segments separated by a slash ("/") character. A path is always defined for a URI, though the defined path may be empty (zero length) or opaque (not containing any "/" delimiters). For example, the URI <mailto:fred@example.com> has a path of "fred@example.com".¶

Within a path segment, the semicolon (";") and equals ("=") reserved characters are often used for delimiting parameters and parameter values applicable to that segment. The comma (",") reserved character is often used for similar purposes. For example, one URI generator might use a segment like "name;v=1.1" to indicate a reference to version 1.1 of "name", whereas another might use a segment like "name,1.1" to indicate the same. Parameter types may be defined by scheme-specific semantics, but in most cases the meaning of a parameter is specific to the URI originator. Parameters are not significant to the parsing of relative references.¶

The path segments "." and ".." are defined for relative reference within the path name hierarchy. They are intended for use at the beginning of a relative path reference (Section 4.2) for indicating relative position within the hierarchical tree of names, with a similar effect to how they are used within some operating systems' file directory structure to indicate the current directory and parent directory, respectively. Unlike a file system, however, these dot-segments are only interpreted within the URI path hierarchy and must be removed as part of the URI normalization or resolution process, in accordance with the process described in Section 5.2.¶

The query component contains non-hierarchical data that, along with data in the path (Section 3.3) component, serves to identify a resource within the scope of that URI's scheme and naming authority (if any). The query component is indicated by the first question-mark ("?") character and terminated by a crosshatch ("#") character or by the end of the URI.

   query       = *( pchar / "/" / "?" )

The characters slash ("/") and question-mark ("?") are allowed to represent data within the query component, but such use is discouraged; incorrect implementations of relative URI resolution often fail to distinguish them from hierarchical separators, thus resulting in non-interoperable results while parsing relative references. However, since query components are often used to carry identifying information in the form of "key=value" pairs, and one frequently used value is a reference to another URI, it is sometimes better for usability to include those characters unescaped.¶

The fragment identifier component allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information that is selective within that resource. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource that is merely named within the primary resource. A fragment identifier component is indicated by the presence of a crosshatch ("#") character and terminated by the end of the URI string.

   fragment    = *( pchar / "/" / "?" )

The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. Therefore, the format and interpretation of a fragment identifier component is dependent on the media type [RFC2046] of a potential retrieval result. Individual media types may define their own restrictions on, or structure within, the fragment identifier syntax for specifying different types of subsets, views, or external references that are identifiable as fragments by that media type. If the primary resource is represented by multiple media types, as is often the case for resources whose representation is selected based on attributes of the retrieval request, then interpretation of the given fragment identifier must be consistent across all of those media types in order for it to be viable as an identifier.¶

As with any URI, use of a fragment identifier component does not imply that a retrieval action will take place. A URI with a fragment identifier may be used to refer to the secondary resource without any implication that the primary resource is accessible. However, if that URI is used in a context that does call for retrieval and is not a same-document reference (Section 4.4), the fragment identifier is only valid as a reference if a retrieval action on the primary resource succeeds and results in a representation that defines the fragment.¶

Fragment identifiers have a special role in information systems as the primary form of client-side indirect referencing, allowing an author to specifically identify those aspects of an existing resource that are only indirectly provided by the resource owner. As such, interpretation of the fragment identifier during a retrieval action is performed solely by the user agent; the fragment identifier is not passed to other systems during the process of retrieval. Although this is often perceived to be a loss of information, particularly in regards to accurate redirection of references as content moves over time, it also serves to prevent information providers from denying reference authors the right to selectively refer to information within a resource.¶

The characters slash ("/") and question-mark ("?") are allowed to represent data within the fragment identifier, but such use is discouraged for the same reasons as described above for query.¶

The ABNF rule URI-reference is used to denote the most common usage of a resource identifier.

   URI-reference = URI / relative-URI

A URI-reference may be absolute or relative: if the reference string's prefix matches the syntax of a scheme followed by its colon separator, then the reference is a URI rather than a relative-URI.

A URI-reference is typically parsed first into the five URI components, in order to determine what components are present and whether the reference is relative or absolute, and then each component is parsed for its subparts and their validation. The ABNF of URI-reference, along with the "first-match-wins" disambiguation rule, is sufficient to define a validating parser for the generic syntax. Readers familiar with regular expressions should see Appendix B for an example of a non-validating URI-reference parser that will take any given string and extract the URI components.¶

A relative URI reference takes advantage of the hier-part syntax (Section 3) in order to express a reference that is relative to the name space of another hierarchical URI.

   relative-URI  = hier-part [ "?" query ] [ "#" fragment ]

The URI referred to by a relative URI reference is obtained by applying the relative resolution algorithm of Section 5.

A relative reference that begins with two slash characters is termed a network-path reference; such references are rarely used. A relative reference that begins with a single slash character is termed an absolute-path reference. A relative reference that does not begin with a slash character is termed a relative-path reference.¶

A path segment that contains a colon character (e.g., "this:that") cannot be used as the first segment of a relative-path reference because it might be mistaken for a scheme name. Such a segment must be preceded by a dot-segment (e.g., "./this:that") to make a relative-path reference.¶

Some protocol elements allow only the absolute form of a URI without a fragment identifier. For example, defining the base URI for later use by relative references calls for an absolute-URI production that does not allow a fragment.

   absolute-URI  = scheme ":" hier-part [ "?" query ]

When a URI reference occurring within a document or message refers to a URI that is, aside from its fragment component (if any), identical to the base URI (Section 5), that reference is called a "same-document" reference. The most frequent examples of same-document references are relative references that are empty or include only the crosshatch ("#") separator followed by a fragment identifier.¶

When a same-document reference is dereferenced for the purpose of a retrieval action, the target of that reference is defined to be within that current document or message; the dereference should not result in a new retrieval.¶

The URI syntax is designed for unambiguous reference to resources and extensibility via the URI scheme. However, as URI identification and usage have become commonplace, traditional media (television, radio, newspapers, billboards, etc.) have increasingly used a suffix of the URI as a reference, consisting of only the authority and path portions of the URI, such as¶

or simply the DNS hostname on its own. Such references are primarily intended for human interpretation rather than machine, with the assumption that context-based heuristics are sufficient to complete the URI (e.g., most hostnames beginning with "www" are likely to have a URI prefix of "http://"). Although there is no standard set of heuristics for disambiguating a URI suffix, many client implementations allow them to be entered by the user and heuristically resolved. It should be noted that such heuristics may change over time, particularly when new URI schemes are introduced.¶

Since a URI suffix has the same syntax as a relative path reference, a suffix reference cannot be used in contexts where relative URIs are expected. This limits use of suffix references to those places where there is no defined base URI, such as dialog boxes and off-line advertisements.¶

The term "relative URI" implies that there exists some absolute "base URI" against which the relative reference is applied. Indeed, the base URI is necessary to define the semantics of any relative URI reference; without it, a relative reference is meaningless. In order for relative URI to be usable within a document, the base URI of that document must be known to the parser.¶

A document that contains relative references must have a base URI that contains a hierarchical path component. In other words, a relative-URI cannot be used within a document that has an unsuitable base URI. Some URI schemes do not allow a hierarchical path component and are thus restricted to full URI references.¶

An authority component is not required for a URI scheme to make use of relative references. A base URI without an authority component implies that any relative reference will also be without an authority component.¶

This section describes an example algorithm for resolving URI references that might be relative to a given base URI. The algorithm is intended to provide a definitive result that can be used to test the output of other implementations. Implementation of the algorithm itself is not required, but the result given by an implementation must match the result that would be given by this algorithm.¶

The base URI (Base) is established according to the rules of Section 5.1 and parsed into the five main components described in Section 3. Note that only the scheme component is required to be present in the base URI; the other components may be empty or undefined. A component is undefined if its preceding separator does not appear in the URI reference; the path component is never undefined, though it may be empty.¶

For each URI reference (R), the following pseudocode describes an algorithm for transforming R into its target URI (T):

   (R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R);
      -- The URI reference is parsed into the five URI components

   if ((not validating) and (R.scheme == Base.scheme)) then
      -- A non-validating parser may ignore a scheme in the
      -- reference if it is identical to the base URI's scheme.
      undefine(R.scheme);
   endif;

   if defined(R.scheme) then
      T.scheme    = R.scheme;
      T.authority = R.authority;
      T.path      = R.path;
      T.query     = R.query;
   else
      if defined(R.authority) then
         T.authority = R.authority;
         T.path      = R.path;
         T.query     = R.query;
      else
         if (R.path == "") then
            T.path = Base.path;
            if defined(R.query) then
               T.query = R.query;
            else
               T.query = Base.query;
            endif;
         else
            if (R.path starts-with "/") then
               T.path = R.path;
            else
               T.path = merge(Base.path, R.path);
            endif;
            T.query = R.query;
         endif;
         T.authority = Base.authority;
      endif;
      T.scheme = Base.scheme;
   endif;

   T.fragment = R.fragment;

The pseudocode above refers to a merge routine for merging a relative-path reference with the path of the base URI to obtain the target path. Although there are many ways to do this, we will describe a simple method using a separate string buffer: ¶

1. All but the last segment of the base URI's path component is copied to the buffer. In other words, any characters after the last (right-most) slash character, if any, are excluded. If the base URI's path component is the empty string, then a single slash character ("/") is copied to the buffer.
2. The reference's path component is appended to the buffer string.
3. All occurrences of "./", where "." is a complete path segment, are removed from the buffer string.
4. If the buffer string ends with "." as a complete path segment, that "." is removed.
5. All occurrences of "<segment>/../", where <segment> is a complete path segment not equal to "..", are removed from the buffer string. Removal of these path segments is performed iteratively, removing the leftmost matching pattern on each iteration, until no matching pattern remains.
6. If the buffer string ends with "<segment>/..", where <segment> is a complete path segment not equal to "..", that "<segment>/.." is removed.
7. If the resulting buffer string still begins with one or more complete path segments of "..", then the reference is considered to be in error. Implementations may handle this error by removing them from the resolved path (i.e., discarding relative levels above the root) or by avoiding traversal of the reference.
8. The remaining buffer string is the target URI's path component.

Some systems may find it more efficient to implement the merge algorithm as a pair of path segment stacks being merged, rather than as a series of string pattern replacements. ¶

• Note: Some WWW client applications will fail to separate the reference's query component from its path component before merging the base and reference paths. This may result in a loss of information if the query component contains the strings "/../" or "/./".

Parsed URI components can be recombined to obtain the referenced URI. Using pseudocode, this would be:

   result = ""

   if defined(T.scheme) then
      append T.scheme to result;
      append ":" to result;
   endif;

   if defined(T.authority) then
      append "//" to result;
      append T.authority to result;
   endif;

   append T.path to result;

   if defined(T.query) then
      append "?" to result;
      append T.query to result;
   endif;

   if defined(fragment) then
      append "#" to result;
      append fragment to result;
   endif;

   return result;

Note that we are careful to preserve the distinction between a component that is undefined, meaning that its separator was not present in the reference, and a component that is empty, meaning that the separator was present and was immediately followed by the next component separator or the end of the reference.

Within an object with a well-defined base URI of¶

Since URIs exist to identify resources, presumably they should be considered equivalent when they identify the same resource. However, such a definition of equivalence is not of much practical use, since there is no way for software to compare two resources without knowledge of their origin. For this reason, determination of equivalence or difference of URIs is based on string comparison, perhaps augmented by reference to additional rules provided by URI scheme definitions. We use the terms "different" and "equivalent" to describe the possible outcomes of such comparisons, but there are many application-dependent versions of equivalence.¶

Even though it is possible to determine that two URIs are equivalent, it is never possible to be sure that two URIs identify different resources. Therefore, comparison methods are designed to minimize false negatives while strictly avoiding false positives.¶

In testing for equivalence, it is generally unwise to directly compare relative URI references; they should be converted to their absolute forms before comparison. Furthermore, when URI references are being compared for the purpose of selecting (or avoiding) a network action, such as retrieval of a representation, it is often necessary to remove fragment identifiers from the URIs prior to comparison.¶

A variety of methods are used in practice to test URI equivalence. These methods fall into a range, distinguished by the amount of processing required and the degree to which the probability of false negatives is reduced. As noted above, false negatives cannot in principle be eliminated. In practice, their probability can be reduced, but this reduction requires more processing and is not cost-effective for all applications.¶

If this range of comparison practices is considered as a ladder, the following discussion will climb the ladder, starting with those that are cheap but have a relatively higher chance of producing false negatives, and proceeding to those that have higher computational cost and lower risk of false negatives.¶

It is in the best interests of everyone to avoid false-negatives in comparing URIs and to minimize the amount of software processing for such comparisons. Those who generate and make reference to URIs can reduce the cost of processing and the risk of false negatives by consistently providing them in a form that is reasonably canonical with respect to their scheme. Specifically: ¶

• Always provide the URI scheme in lowercase characters.
• Always provide the hostname, if any, in lowercase characters.
• Only perform percent-escaping where it is essential.
• Always use uppercase A-through-F characters when percent-escaping.
• Prevent /./ and /../ from appearing in non-relative URI paths.

The good practices listed above are motivated by observations that a high proportion of deployed software use these techniques for the purposes of normalization.¶

There is no guarantee that, having once used a given URI to retrieve some information, that the same information will be retrievable by that URI in the future. Nor is there any guarantee that the information retrievable via that URI in the future will be observably similar to that retrieved in the past. The URI syntax does not constrain how a given scheme or authority apportions its name space or maintains it over time. Such a guarantee can only be obtained from the person(s) controlling that name space and the resource in question. A specific URI scheme may define additional semantics, such as name persistence, if those semantics are required of all naming authorities for that scheme.¶

It is sometimes possible to construct a URI such that an attempt to perform a seemingly harmless, idempotent operation, such as the retrieval of a representation, will in fact cause a possibly damaging remote operation to occur. The unsafe URI is typically constructed by specifying a port number other than that reserved for the network protocol in question. The client unwittingly contacts a site that is running a different protocol service. The content of the URI contains instructions that, when interpreted according to this other protocol, cause an unexpected operation. An example has been the use of a gopher URI to cause an unintended or impersonating message to be sent via a SMTP server.¶

Caution should be used when dereferencing a URI that specifies a TCP port number other than the default for the scheme, especially when it is a number within the reserved space.¶

Care should be taken when a URI contains escaped delimiters for a given protocol (for example, CR and LF characters for telnet protocols) that these octets are not unescaped before transmission. This might violate the protocol, but avoids the potential for such characters to be used to simulate an extra operation or parameter in that protocol which might lead to an unexpected and possibly harmful remote operation being performed.¶

Although the URI syntax for IPv4address only allows the common, dotted-decimal form of IPv4 address literal, many implementations that process URIs make use of platform-dependent system routines, such as gethostbyname() and inet_aton(), to translate the string literal to an actual IP address. Unfortunately, such system routines often allow and process a much larger set of formats than those described in Section 3.2.2.¶

For example, many implementations allow dotted forms of three numbers, wherein the last part is interpreted as a 16-bit quantity and placed in the right-most two bytes of the network address (e.g., a Class B network). Likewise, a dotted form of two numbers means the last part is interpreted as a 24-bit quantity and placed in the right most three bytes of the network address (Class A), and a single number (without dots) is interpreted as a 32-bit quantity and stored directly in the network address. Adding further to the confusion, some implementations allow each dotted part to be interpreted as decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; otherwise, a leading 0 implies octal; otherwise, the number is interpreted as decimal).¶

These additional IP address formats are not allowed in the URI syntax due to differences between platform implementations. However, they can become a security concern if an application attempts to filter access to resources based on the IP address in string literal format. If such filtering is performed, it is recommended that literals be converted to numeric form and filtered based on the numeric value, rather than a prefix or suffix of the string form.¶

It is clearly unwise to use a URI that contains a password which is intended to be secret. In particular, the use of a password within the userinfo component of a URI is strongly discouraged except in those rare cases where the 'password' parameter is intended to be public.¶

Because the userinfo component is rarely used and appears before the hostname in the authority component, it can be used to construct a URI that is intended to mislead a human user by appearing to identify one (trusted) naming authority while actually identifying a different authority hidden behind the noise. For example

   http://www.example.com&story=breaking_news@10.0.0.1/top_story.htm

might lead a human user to assume that the host is 'www.example.com', whereas it is actually '10.0.0.1'. Note that the misleading userinfo could be much longer than the example above.

A misleading URI, such as the one above, is an attack on the user's preconceived notions about the meaning of a URI, rather than an attack on the software itself. User agents may be able to reduce the impact of such attacks by visually distinguishing the various components of the URI when rendered, such as by using a different color or tone to render userinfo if any is present, though there is no general panacea. More information on URI-based semantic attacks can be found in [Siedzik].¶

IPv6 literals have been added to the list of possible identifiers for the host portion of a authority component, as described by [RFC2732], with the addition of "[" and "]" to the reserved and uric sets. Square brackets are now specified as reserved within the authority component and not allowed outside their use as delimiters for an IPv6reference within host. In order to make this change without changing the technical definition of the path, query, and fragment components, those rules were redefined to directly specify the characters allowed rather than be defined in terms of uric.¶

Since [RFC2732] defers to [RFC3513] for definition of an IPv6 literal address, which unfortunately lacks an ABNF description of IPv6address, we created a new ABNF rule for IPv6address that matches the text representations defined by Section 2.2 of [RFC3513]. Likewise, the definition of IPv4address has been improved in order to limit each decimal octet to the range 0-255, and the definition of hostname has been improved to better specify length limitations and partially-qualified domain names.¶

Section 6 (Section 6) on URI normalization and comparison has been completely rewritten and extended using input from Tim Bray and discussion within the W3C Technical Architecture Group. Likewise, Section 2.1 on the encoding of characters has been replaced.¶

An ABNF production for URI has been introduced to correspond to the common usage of the term: an absolute URI with optional fragment.¶

The ad-hoc BNF syntax has been replaced with the ABNF of [RFC2234]. This change required all rule names that formerly included underscore characters to be renamed with a dash instead.¶

Section 2.2 on reserved characters has been rewritten to clearly explain what characters are reserved, when they are reserved, and why they are reserved even when not used as delimiters by the generic syntax. Likewise, the section on escaped characters has been rewritten, and URI normalizers are now given license to unescape any octets corresponding to unreserved characters. The crosshatch ("#") character has been moved back from the excluded delims to the reserved set.¶

The ABNF for URI and URI-reference has been redesigned to make them more friendly to LALR parsers and significantly reduce complexity. As a result, the layout form of syntax description has been removed, along with the uric-no-slash, opaque-part, and rel-segment productions. All references to "opaque" URIs have been replaced with a better description of how the path component may be opaque to hierarchy. The fragment identifier has been moved back into the section on generic syntax components and within the URI and relative-URI productions, though it remains excluded from absolute-URI. The ambiguity regarding the parsing of URI-reference as a URI or a relative-URI with a colon in the first segment is now explained and disambiguated in the section defining relative-URI.¶

The ABNF of hier-part and relative-URI has been corrected to allow a relative URI path to be empty. This also allows an absolute-URI to consist of nothing after the "scheme:", as is present in practice with the "DAV:" namespace [RFC2518] and the "about:" URI used by many browser implementations. The ambiguity regarding the parsing of net-path, abs-path, and rel-path is now explained and disambiguated in the same section.¶

Registry-based naming authorities that use the hierarchical authority syntax component are now limited to DNS hostnames, since those have been the only such URIs in deployment. This change was necessary to enable internationalized domain names to be processed in their native character encodings at the application layers above URI processing. The reg_name, server, and hostport productions have been removed to simplify parsing of the URI syntax.¶

The ABNF of qualified has been simplified to remove a parsing ambiguity without changing the allowed syntax. The toplabel production has been removed because it served no useful purpose. The ambiguity regarding the parsing of host as IPv4address or hostname is now explained and disambiguated in the same section.¶

The resolving relative references algorithm of [RFC2396] has been rewritten using pseudocode for this revision to improve clarity and fix the following issues: ¶

• [RFC2396] section 5.2, step 6a, failed to account for a base URI with no path.
• Restored the behavior of [RFC1808] where, if the reference contains an empty path and a defined query component, then the target URI inherits the base URI's path component.
• Removed the special-case treatment of same-document references in favor of a section that explains that a new retrieval action should not be made if the target URI and base URI, excluding fragments, match.