Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This specification defines the handling of Web addresses for Hypertext Markup Language (HTML) 5, the fifth major revision of the core language of the World Wide Web. In this version, special attention has been given to defining clear conformance criteria for user agents in an effort to improve interoperability.
This is a start at factoring out the URL material in the HTML 5 draft as a separate draft for consideration by the W3C HTML Working Group (See ACTION-68.)
See also a URI desk calculator.
This specification defines the term Web address, and defines various algorithms for dealing with Web addresses, because for historical reasons the rules defined by the URI and IRI specifications are not a complete description of what HTML user agents need to implement to be compatible with Web content.
A Web address is a string used to identify a resource.
The term "Web address" in this specification is used to include not only Uniform Resource Identifiers (URIs) as they are defined by RFC 3986 and Internationalized Resource Identifiers (IRIs) as they are defined by RFC 3987, but also other strings of characters which can be used to identify Web resources when processed appropriately.
A Web address is a valid Web address if at least one of the following conditions holds:
The Web address is a valid URI reference (i.e. it matches the grammar for <URI-reference&ft; given in RFC 3986).
The Web address is a valid IRI reference (i.e. it matches the grammar for <IRI-reference&ft; given in RFC 3987), and it has no query component.
The Web address is a valid IRI reference and its query component contains no unescaped non-ASCII characters [RFC3987].
The Web address is a valid IRI
reference and the character encoding of the
Web address's Document
is UTF-8 or UTF-16 [RFC3987].
A Web address has an associated URL character encoding, determined as follows:
Document
, and the URL character
encoding is the document's character encoding.To parse a Web address w into its component parts, the user agent must use the following steps:
N.B. the rules given here will parse not only valid Web addresses but a variety of invalid ones as well. The point of making the algorithm have a scope different from that of the definition of valid Web address is not clear and needs to be discussed in the WG.
The parsing process described here should be more closely aligned with the rules given in RFC 3987.
Strip leading and trailing space characters from w.
Percent-encode all non-URI characters in w.
This probably needs to be laid out in more detail.
Note: this step will replace all of the following characters with a percent-encoded equivalent:
As a result of percent-encoding the percent sign, any occurrences of percent-encoding in the Web address will be double-encoded at this step.
If w begins with either of:
://
"then percent-encode any left or right square brackets
(U+005B, U+005D, "[
" and "]
")
following the first occurrence of "/
",
"?
", or
"#
" which follows the
first occurrence of "//
".
Otherwise, percent-encode all left and right square brackets.
Percent-encode all occurrences of U+0023 (Number sign, "#
")
after the first.
Parse w using the grammar in RFC 3986.
If w doesn't match the <URI-reference> production, even after the above changes are made to it, then parsing the Web address fails with an error. [RFC3986]
Otherwise, parsing w was successful; the components of the Web address are substrings of w defined as follows. First, the substring of the modified w which matched a particular production in RFC 3986 is identified; then any percent-encoded characters in that substring are decoded. The resulting string (called here the "decoded substring) is one of the named components of w.
The decoded substring matched by the <scheme> production, if any.
The decoded substring matched by the <host> production, if any.
The decoded substring matched by the <port> production, if any.
If there is a <scheme> component and a <port> component and the port given by the <port> component is different than the default port defined for the protocol given by the <scheme> component, then <hostport> is the decoded substring that starts with the decoded substring matched by the <host> production and ends with the decoded substring matched by the <port> production, and includes the colon in between the two. Otherwise, it is the same as the <host> component.
The decoded substring matched by one of the following productions, if one of them was matched:
The decoded substring matched by the <query> production, if any.
The decoded substring matched by the <fragment> production, if any.
The decoded substring that follows the decoded substring matched by the <authority> production, or the whole string if the <authority> production wasn't matched.
How does this compare to just parsing using the IRI grammar of RFC 3987?
To resolve a Web address to an absolute Web adddress relative to either another absolute Web address or an element, the user agent must use the following steps. Resolving a Web address can result in an error, in which case the Web address is not resolvable.
Let w be the Web address being resolved.
Let encoding be the character encoding of the Web address.
If encoding is UTF-16, then change it to UTF-8.
If the algorithm was invoked with an absolute Web address to use as the base Web address, let base be that absolute Web address.
Otherwise, let base be the base URI of
the element, as defined by the XML Base specification, with
the base URI of the document entity being defined as the
document base Web address of the Document
that
owns the element. [XMLBASE]
For the purposes of the XML Base specification, user agents
must act as if all Document
objects represented XML
documents.
It is possible for xml:base
attributes to be present
even in HTML fragments, as such attributes can be added
dynamically using script. (Such scripts would not be conforming,
however, as xml:base
attributes
are not allowed in HTML documents.)
The document base Web address of a Document
is
the absolute Web address obtained by running these
substeps:
Let fallback base url be the document's address.
If fallback base url is
about:blank
, and the Document
's
browsing context has a creator browsing
context, then let fallback base url
be the document base Web address of the creator
Document
instead.
If there is no base
element that is both a
child of the head
element and has an
href
attribute, then the
document base Web address is fallback base
url.
Otherwise, let w be the value of the
href
attribute of the first
such element.
Resolve w relative to fallback base
url (thus, the base
href
attribute isn't affected by
xml:base
attributes).
The document base Web address is the result of the previous step if it was successful; otherwise it is fallback base url.
Parse w into its component parts.
If parsing w resulted in a <host> component, then replace the matching subtring of w with the string that results from expanding any sequences of percent-encoded octets in that component that are valid UTF-8 sequences into Unicode characters as defined by UTF-8.
If any percent-encoded octets in that component are not valid UTF-8 sequences, then return an error and abort these steps.
Apply the IDNA ToASCII algorithm to the matching substring, with both the AllowUnassigned and UseSTD3ASCIIRules flags set. Replace the matching substring with the result of the ToASCII algorithm.
If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then return an error and abort these steps [RFC3490].
If parsing w resulted in a <path> component, then replace the matching substring of w with the string that results from applying the following steps to each character other than U+0025 PERCENT SIGN (%) that doesn't match the original <path> production defined in RFC 3986:
For instance if w was "//example.com/a^b☺c%FFd%z/?e
", then the
<path> component's substring
would be "/a^b☺c%FFd%z/
" and the two
characters that would have to be escaped would be "^
" and "☺
". The
result after this step was applied would therefore be that w now had the value "//example.com/a%5Eb%E2%98%BAc%FFd%z/?e
".
If parsing w resulted in a <query> component, then replace the matching substring of w with the string that results from applying the following steps to each character other than U+0025 PERCENT SIGN (%) that doesn't match the original <query> production defined in RFC 3986:
Apply the algorithm described in RFC 3986 section 5.2 Relative Resolution, using w as the potentially relative URI reference (R), and base as the base URI (Base). [RFC3986]
Apply any relevant conformance criteria of RFC 3986 and RFC 3987, returning an error and aborting these steps if appropriate. [RFC3986] [RFC3987]
For instance, if an absolute URI that would be
returned by the above algorithm violates the restrictions specific
to its scheme, e.g. a data:
URI using the
"//
" server-based naming authority syntax,
then user agents are to treat this as an error instead.
Let result be the target URI (T) returned by the Relative Resolution algorithm.
If result uses a scheme with a server-based naming authority, replace all U+005C REVERSE SOLIDUS (\) characters in result with U+002F SOLIDUS (/) characters.
Return result.
A Web address is an absolute Web address if resolving it results in the same Web address without an error.
[Note: the version cited was current at the time this draft was prepared. If later editions of the XML Base specification are issued, software conforming to this specification MAY support either the version cited or a later normative version.]
For the convenience of those who wish to compare in detail the draft text of section 2 with the rules in previous drafts of HTML 5, this appendix reproduces the latter. The intention is that the new formulation above and the formulation reproduced here should produce identical results (with the possible exception of edge cases), but that the new formulation should be better aligned with existing specifications.
Known discrepancies:
To parse a Web address w into its component parts, the user agent must use the following steps:
N.B. the rules given here will parse not only valid Web addresses but a variety of invalid ones as well. The point of making the algorithm have a scope different from that of the definition of valid Web address is not clear and needs to be discussed in the WG.
The parsing process described here should be more closely aligned with the rules given in RFC 3987.
Strip leading and trailing space characters from w.
Parse w in the manner defined by RFC 3986, with the following exceptions:
Working note: U+005B and U+005D are defined in RFC 3986 as reserved characters (general delimiters). Adding them to <unreserved> makes the grammar more complex (either by requiring more lookahead or by making the grammar ambiguous) if and only if either of them is present as a delimiter in the follow set of any occurrence of <unreserved> in the grammar.
Those occurrences and their follow sets are:
@
"}]
"}:
", "/
",
"?
", "#
"}/
",
"?
", "#
"}/
,
"#
", "?
", end-of-URI}Conclusion: this change renders the grammar more complex when IPvFuture is used.
It appears not to become ambiguous, since the "]
" character which follows
the <IPvFuture> construct can be distinguished from any
"]
" characters within <IBvFuture> because it
can be followed only by ":
" (for an explicit port number),
"/
" (for a path), "?
" (for a query),
"#
" (for a fragment identifier), or the end of the
Web address.
Of these, only ":
" can appear within <IPvFuture>,
and any sequence of characters consisting of colon followed by
zero or more decimal digits can be unambiguously parsed either
as part of the <IPvFuture> construct or as a port number,
depending on whether it is followed by a "]
" or not.
The string “x://[v42.3]:2323]:2323:2323]:2323
”
illustrates the lookahead issue, but it has only one parse.
In contexts where (as suggested in RFC 3986 Appendix C) angle brackets or quotation marks are used to delimit URIs, it may lead to confusion if these characters are allowed within Web addresses in literal form.
This renders the grammar ambiguous, but the simple greedy rule
of always preferring to recognize the three-character sequence
"%" HEXDIG HEXDIG
rather than the one-character
sequence "%"
adequately disambiguates it.
If w doesn't match the <URI-reference> production, even after the above changes are made to the ABNF definitions, then parsing the Web address fails with an error. [RFC3986]
Otherwise, parsing w was successful; the components of the Web address are substrings of w defined as follows:
The substring matched by the <scheme> production, if any.
The substring matched by the <host> production, if any.
The substring matched by the <port> production, if any.
If there is a <scheme> component and a <port> component and the port given by the <port> component is different than the default port defined for the protocol given by the <scheme> component, then <hostport> is the substring that starts with the substring matched by the <host> production and ends with the substring matched by the <port> production, and includes the colon in between the two. Otherwise, it is the same as the <host> component.
The substring matched by one of the following productions, if one of them was matched:
The substring matched by the <query> production, if any.
The substring matched by the <fragment> production, if any.
The substring that follows the substring matched by the <authority> production, or the whole string if the <authority> production wasn't matched.