idnits 2.17.00 (12 Aug 2021) /tmp/idnits34462/draft-fielding-uri-rfc2396bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 702: '... practice is NOT RECOMMENDED, because ...' -- The draft header indicates that this document obsoletes RFC2732, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2396, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC1808, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1738, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 23, 2003) is 6937 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2277' is defined on line 1722, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Obsolete informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 1808 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2518 (Obsoleted by RFC 4918) -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 2732 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 2110 (Obsoleted by RFC 2557) -- Obsolete informational reference (is this intentional?): RFC 2717 (Obsoleted by RFC 4395) -- Obsolete informational reference (is this intentional?): RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Berners-Lee 3 Internet-Draft MIT/LCS 4 Updates: 1738 (if approved) R. Fielding 5 Obsoletes: 2732, 2396, 1808 (if approved) Day Software 6 L. Masinter 7 Expires: November 21, 2003 Adobe 8 May 23, 2003 10 Uniform Resource Identifier (URI): Generic Syntax 11 draft-fielding-uri-rfc2396bis-02 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 . 30 The list of Internet-Draft Shadow Directories can be accessed at 31 . 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 A Uniform Resource Identifier (URI) is a compact string of characters 40 for identifying an abstract or physical resource. This document 41 defines the generic syntax of a URI, including both absolute and 42 relative forms, and guidelines for their use. 44 This document defines a grammar that is a superset of all valid URIs, 45 such that an implementation can parse the common components of a URI 46 reference without knowing the scheme-specific requirements of every 47 possible identifier type. This document does not define a generative 48 grammar for all URIs; that task will be performed by the individual 49 specifications of each URI scheme. 51 Editorial Note 53 Discussion of this draft and comments to the editors should be sent 54 to the uri@w3.org mailing list. An issues list and version history 55 is available at . 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1 Overview of URIs . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1.1 Generic Syntax . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.1.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1.1.3 URI, URL, and URN . . . . . . . . . . . . . . . . . . . . . 6 65 1.2 Design Considerations . . . . . . . . . . . . . . . . . . . 6 66 1.2.1 Transcription . . . . . . . . . . . . . . . . . . . . . . . 6 67 1.2.2 Separating Identification from Interaction . . . . . . . . . 7 68 1.2.3 Hierarchical Identifiers . . . . . . . . . . . . . . . . . . 9 69 1.3 Syntax Notation . . . . . . . . . . . . . . . . . . . . . . 9 70 2. Characters . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 2.1 Encoding of Characters . . . . . . . . . . . . . . . . . . . 10 72 2.2 Reserved Characters . . . . . . . . . . . . . . . . . . . . 10 73 2.3 Unreserved Characters . . . . . . . . . . . . . . . . . . . 11 74 2.4 Escaped Characters . . . . . . . . . . . . . . . . . . . . . 12 75 2.4.1 Escaped Encoding . . . . . . . . . . . . . . . . . . . . . . 12 76 2.4.2 When to Escape and Unescape . . . . . . . . . . . . . . . . 12 77 2.5 Excluded Characters . . . . . . . . . . . . . . . . . . . . 13 78 3. Syntax Components . . . . . . . . . . . . . . . . . . . . . 15 79 3.1 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 3.2 Authority . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 3.2.1 User Information . . . . . . . . . . . . . . . . . . . . . . 16 82 3.2.2 Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 3.2.3 Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 3.4 Query . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 3.5 Fragment . . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 4.1 URI Reference . . . . . . . . . . . . . . . . . . . . . . . 22 89 4.2 Relative URI . . . . . . . . . . . . . . . . . . . . . . . . 22 90 4.3 Absolute URI . . . . . . . . . . . . . . . . . . . . . . . . 23 91 4.4 Same-document Reference . . . . . . . . . . . . . . . . . . 23 92 4.5 Suffix Reference . . . . . . . . . . . . . . . . . . . . . . 23 93 5. Relative Resolution . . . . . . . . . . . . . . . . . . . . 25 94 5.1 Establishing a Base URI . . . . . . . . . . . . . . . . . . 25 95 5.1.1 Base URI within Document Content . . . . . . . . . . . . . . 26 96 5.1.2 Base URI from the Encapsulating Entity . . . . . . . . . . . 26 97 5.1.3 Base URI from the Retrieval URI . . . . . . . . . . . . . . 27 98 5.1.4 Default Base URI . . . . . . . . . . . . . . . . . . . . . . 27 99 5.2 Obtaining the Referenced URI . . . . . . . . . . . . . . . . 27 100 5.3 Recomposition of a Parsed URI . . . . . . . . . . . . . . . 29 101 5.4 Examples of Relative Resolution . . . . . . . . . . . . . . 30 102 5.4.1 Normal Examples . . . . . . . . . . . . . . . . . . . . . . 30 103 5.4.2 Abnormal Examples . . . . . . . . . . . . . . . . . . . . . 31 104 6. Normalization and Comparison . . . . . . . . . . . . . . . . 33 105 6.1 Equivalence . . . . . . . . . . . . . . . . . . . . . . . . 33 106 6.2 Comparison Ladder . . . . . . . . . . . . . . . . . . . . . 33 107 6.2.1 Simple String Comparison . . . . . . . . . . . . . . . . . . 34 108 6.2.2 Syntax-based Normalization . . . . . . . . . . . . . . . . . 35 109 6.2.3 Scheme-based Normalization . . . . . . . . . . . . . . . . . 36 110 6.2.4 Protocol-based Normalization . . . . . . . . . . . . . . . . 36 111 6.3 Canonical Form . . . . . . . . . . . . . . . . . . . . . . . 36 112 7. Security Considerations . . . . . . . . . . . . . . . . . . 38 113 7.1 Reliability and Consistency . . . . . . . . . . . . . . . . 38 114 7.2 Malicious Construction . . . . . . . . . . . . . . . . . . . 38 115 7.3 Rare IP Address Formats . . . . . . . . . . . . . . . . . . 39 116 7.4 Sensitive Information . . . . . . . . . . . . . . . . . . . 39 117 7.5 Semantic Attacks . . . . . . . . . . . . . . . . . . . . . . 39 118 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 41 119 Normative References . . . . . . . . . . . . . . . . . . . . 42 120 Informative References . . . . . . . . . . . . . . . . . . . 43 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 122 A. Collected ABNF for URI . . . . . . . . . . . . . . . . . . . 46 123 B. Parsing a URI Reference with a Regular Expression . . . . . 47 124 C. Embedding the Base URI in HTML documents . . . . . . . . . . 48 125 D. Delimiting a URI in Context . . . . . . . . . . . . . . . . 49 126 E. Summary of Non-editorial Changes . . . . . . . . . . . . . . 51 127 E.1 Additions . . . . . . . . . . . . . . . . . . . . . . . . . 51 128 E.2 Modifications from RFC 2396 . . . . . . . . . . . . . . . . 51 129 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 130 Intellectual Property and Copyright Statements . . . . . . . 57 132 1. Introduction 134 A Uniform Resource Identifier (URI) provides a simple and extensible 135 means for identifying a resource. This specification of URI syntax 136 and semantics is derived from concepts introduced by the World Wide 137 Web global information initiative, whose use of such identifiers 138 dates from 1990 and is described in "Universal Resource Identifiers 139 in WWW" [RFC1630], and is designed to meet the recommendations laid 140 out in "Functional Recommendations for Internet Resource Locators" 141 [RFC1736] and "Functional Requirements for Uniform Resource Names" 142 [RFC1737]. 144 This document obsoletes [RFC2396], which merged "Uniform Resource 145 Locators" [RFC1738] and "Relative Uniform Resource Locators" 146 [RFC1808] in order to define a single, generic syntax for all URIs. 147 It excludes those portions of RFC 1738 that defined the specific 148 syntax of individual URI schemes; those portions will be updated as 149 separate documents. The process for registration of new URI schemes 150 is defined separately by [RFC2717]. 152 All significant changes from RFC 2396 are noted in Appendix G. 154 1.1 Overview of URIs 156 URIs are characterized as follows: 158 Uniform 160 Uniformity provides several benefits: it allows different types of 161 resource identifiers to be used in the same context, even when the 162 mechanisms used to access those resources may differ; it allows 163 uniform semantic interpretation of common syntactic conventions 164 across different types of resource identifiers; it allows 165 introduction of new types of resource identifiers without 166 interfering with the way that existing identifiers are used; and, 167 it allows the identifiers to be reused in many different contexts, 168 thus permitting new applications or protocols to leverage a 169 pre-existing, large, and widely-used set of resource identifiers. 171 Resource 173 Anything that can be named or described can be a resource. 174 Familiar examples include an electronic document, an image, a 175 service (e.g., "today's weather report for Los Angeles"), and a 176 collection of other resources. A resource is not necessarily 177 accessible via the Internet; e.g., human beings, corporations, and 178 bound books in a library can also be resources. Likewise, abstract 179 concepts can be resources, such as the operators and operands of a 180 mathematical equation or the types of a relationship (e.g., 181 "parent" or "employee"). 183 Identifier 185 An identifier embodies the information required to distinguish 186 what is being identified from all other things within its scope of 187 identification. 189 A URI is an identifier that consists of a sequence of characters 190 matching the restricted syntax defined by this specification. A URI 191 can be used to refer to a resource. This specification does not 192 place any limits on the nature of a resource or the reasons why an 193 application might wish to refer to a resource. URIs have a global 194 scope and should be interpreted consistently regardless of context, 195 but that interpretation may be defined in relation to the user's 196 context (e.g., "http://localhost/" refers to a resource that is 197 relative to the user's network interface and yet not specific to any 198 one user). 200 1.1.1 Generic Syntax 202 Each URI begins with a scheme name, as defined in Section 3.1, that 203 refers to a specification for assigning identifiers within that 204 scheme. As such, the URI syntax is a federated and extensible naming 205 system wherein each scheme's specification may further restrict the 206 syntax and semantics of identifiers using that scheme. 208 This specification defines those elements of the URI syntax that are 209 required of all URI schemes or are common to many URI schemes. It 210 thus defines the syntax and semantics that are needed to implement a 211 scheme-independent parsing mechanism for URI references, such that 212 the scheme-dependent handling of a URI can be postponed until the 213 scheme-dependent semantics are needed. Likewise, protocols and data 214 formats that make use of URI references can refer to this 215 specification as defining the range of syntax allowed for all URIs, 216 including those schemes that have yet to be defined. 218 A parser of the generic URI syntax is capable of parsing any URI 219 reference into its major components; once the scheme is determined, 220 further scheme-specific parsing can be performed on the components. 221 In other words, the URI generic syntax is a superset of the syntax of 222 all URI schemes. 224 1.1.2 Examples 226 The following examples illustrate URIs that are in common use. 228 ftp://ftp.is.co.za/rfc/rfc1808.txt 229 -- ftp scheme for File Transfer Protocol services 231 gopher://gopher.tc.umn.edu:70/11/Mailing%20Lists/ 232 -- gopher scheme for Gopher and Gopher+ Protocol services 234 http://www.ietf.org/rfc/rfc2396.txt 235 -- http scheme for Hypertext Transfer Protocol services 237 mailto:John.Doe@example.com 238 -- mailto scheme for electronic mail addresses 240 news:comp.infosystems.www.servers.unix 241 -- news scheme for USENET news groups and articles 243 telnet://melvyl.ucop.edu/ 244 -- telnet scheme for interactive TELNET services 246 1.1.3 URI, URL, and URN 248 A URI can be further classified as a locator, a name, or both. The 249 term "Uniform Resource Locator" (URL) refers to the subset of URIs 250 that, in addition to identifying the resource, provide a means of 251 locating the resource by describing its primary access mechanism 252 (e.g., its network "location"). The term "Uniform Resource Name" 253 (URN) refers to the subset of URIs that are required to remain 254 globally unique and persistent even when the resource ceases to exist 255 or becomes unavailable. 257 An individual scheme does not need to be classified as being just one 258 of "name" or "locator". Instances of URIs from any given scheme may 259 have the characteristics of names or locators or both, often 260 depending on the persistence and care in the assignment of 261 identifiers by the naming authority, rather than any quality of the 262 scheme. This specification deprecates use of the term "URN" for 263 anything but URIs in the "urn" scheme [RFC2141]. This specification 264 also deprecates the term "URL". 266 1.2 Design Considerations 268 1.2.1 Transcription 270 The URI syntax has been designed with global transcription as one of 271 its main considerations. A URI is a sequence of characters from a 272 very limited set: the letters of the basic Latin alphabet, digits, 273 and a few special characters. A URI may be represented in a variety 274 of ways: e.g., ink on paper, pixels on a screen, or a sequence of 275 octets in a coded character set. The interpretation of a URI depends 276 only on the characters used and not how those characters are 277 represented in a network protocol. 279 The goal of transcription can be described by a simple scenario. 280 Imagine two colleagues, Sam and Kim, sitting in a pub at an 281 international conference and exchanging research ideas. Sam asks Kim 282 for a location to get more information, so Kim writes the URI for the 283 research site on a napkin. Upon returning home, Sam takes out the 284 napkin and types the URI into a computer, which then retrieves the 285 information to which Kim referred. 287 There are several design considerations revealed by the scenario: 289 o A URI is a sequence of characters that is not always represented 290 as a sequence of octets. 292 o A URI might be transcribed from a non-network source, and thus 293 should consist of characters that are most likely to be able to be 294 entered into a computer, within the constraints imposed by 295 keyboards (and related input devices) across languages and 296 locales. 298 o A URI often needs to be remembered by people, and it is easier for 299 people to remember a URI when it consists of meaningful or 300 familiar components. 302 These design considerations are not always in alignment. For 303 example, it is often the case that the most meaningful name for a URI 304 component would require characters that cannot be typed into some 305 systems. The ability to transcribe a resource identifier from one 306 medium to another has been considered more important than having a 307 URI consist of the most meaningful of components. In local or 308 regional contexts and with improving technology, users might benefit 309 from being able to use a wider range of characters; such use is not 310 defined in this document. 312 1.2.2 Separating Identification from Interaction 314 A common misunderstanding of URIs is that they are only used to refer 315 to accessible resources. In fact, the URI alone only provides 316 identification; access to the resource is neither guaranteed nor 317 implied by the presence of a URI. Instead, an operation (if any) 318 associated with a URI reference is defined by the protocol element, 319 data format attribute, or natural language text in which it appears. 321 Given a URI, a system may attempt to perform a variety of operations 322 on the resource, as might be characterized by such words as "denote", 323 "access", "update", "replace", or "find attributes". Such operations 324 are defined by the protocols that make use of URIs, not by this 325 specification. However, we do use a few general terms for describing 326 common operations on URIs. URI "resolution" is the process of 327 determining an access mechanism and the appropriate parameters 328 necessary to dereference a URI; such resolution may require several 329 iterations. Using that access mechanism to perform some action on 330 the URI's resource is termed a "dereference" of the URI. 332 When URIs are used within information systems to identify sources of 333 information, the most common form of URI dereference is "retrieval": 334 making use of a URI in order to retrieve a representation of its 335 associated resource. A "representation" is a sequence of octets, 336 along with metadata describing those octets, that constitutes a 337 record of the state of the resource at the time that the 338 representation is generated. Retrieval is achieved by a process that 339 might include using the URI as a cache key to check for a locally 340 cached representation, resolution of the URI to determine an 341 appropriate access mechanism (if any), and dereference of the URI for 342 the sake of applying a retrieval operation. 344 URI references in information systems are designed to be 345 late-binding: the result of an access is generally determined at the 346 time it is accessed and may vary over time or due to other aspects of 347 the interaction. When an author creates a reference to such a 348 resource, they do so with the intention that the reference be used in 349 the future; what is being identified is not some specific result that 350 was obtained in the past, but rather some characteristic that is 351 expected to be true for future results. In such cases, the resource 352 referred to by the URI is actually a sameness of characteristics as 353 observed over time, perhaps elucidated by additional comments or 354 assertions made by the resource provider. 356 Although many URI schemes are named after protocols, this does not 357 imply that use of such a URI will result in access to the resource 358 via the named protocol. URIs are often used simply for the sake of 359 identification. Even when a URI is used to retrieve a representation 360 of a resource, that access might be through gateways, proxies, 361 caches, and name resolution services that are independent of the 362 protocol associated with the scheme name, and the resolution of some 363 URIs may require the use of more than one protocol (e.g., both DNS 364 and HTTP are typically used to access an "http" URI's origin server 365 when a representation isn't found in a local cache). 367 1.2.3 Hierarchical Identifiers 369 The URI syntax is organized hierarchically, with components listed in 370 decreasing order from left to right. For some URI schemes, the 371 visible hierarchy is limited to the scheme itself: everything after 372 the scheme component delimiter is considered opaque to URI 373 processing. Other URI schemes make the hierarchy explicit and visible 374 to generic parsing algorithms. 376 The URI syntax reserves the slash ("/"), question-mark ("?"), and 377 crosshatch ("#") characters for the purpose of delimiting components 378 that are significant to the generic parser's hierarchical 379 interpretation of an identifier. In addition to aiding the 380 readability of such identifiers through the consistent use of 381 familiar syntax, this uniform representation of hierarchy across 382 naming schemes allows scheme-independent references to be made 383 relative to that hierarchy. 385 An "absolute" URI refers to a resource independent of the naming 386 hierarchy in which the identifier is used. In contrast, a "relative" 387 URI refers to a resource by describing the difference within a 388 hierarchical name space between the current context and an absolute 389 URI of the resource. Section 4.2 defines a scheme-independent form 390 of relative URI reference that can be used in conjunction with a base 391 URI of a hierarchical scheme to produce the absolute URI form of that 392 reference. 394 1.3 Syntax Notation 396 This document uses the Augmented Backus-Naur Form (ABNF) notation of 397 [RFC2234] to define the URI syntax. Although the ABNF defines syntax 398 in terms of the US-ASCII character encoding [ASCII], the URI syntax 399 should be interpreted in terms of the character that the 400 ASCII-encoded octet represents, rather than the octet encoding 401 itself. How a URI is represented in terms of bits and bytes on the 402 wire is dependent upon the character encoding of the protocol used to 403 transport it, or the charset of the document that contains it. 405 The following core ABNF productions are used by this specification as 406 defined by Section 6.1 of [RFC2234]: ALPHA, CR, CTL, DIGIT, DQUOTE, 407 HEXDIG, LF, OCTET, and SP. The complete URI syntax is collected in 408 Appendix A. 410 2. Characters 412 A URI consists of a restricted set of characters, primarily chosen 413 to aid transcription and usability both in computer systems and in 414 non-computer communications. Characters used conventionally as 415 delimiters around a URI are excluded. The set of URI characters 416 consists of digits, letters, and a few graphic symbols chosen from 417 those common to most of the character encodings and input facilities 418 available to Internet users. 420 uric = reserved / unreserved / escaped 422 Within a URI, reserved characters are used to delimit syntax 423 components, unreserved characters are used to describe registered 424 names, and unreserved, non-delimiting reserved, and escaped 425 characters are used to represent strings of data (1*OCTET) within the 426 components. 428 2.1 Encoding of Characters 430 As described above (Section 1.3), the URI syntax is defined in terms 431 of characters by reference to the US-ASCII encoding of characters to 432 octets. This specification does not mandate the use of any 433 particular mapping between its character set and the octets used to 434 store or transmit those characters. 436 URI characters representing strings of data within a component may, 437 if allowed by the component production, represent an arbitrary 438 sequence of octets. For example, portions of a given URI might 439 correspond to a filename on a non-ASCII file system, a query on 440 non-ASCII data, numeric coordinates on a map, etc. Some URI schemes 441 define a specific encoding of raw data to US-ASCII characters as part 442 of their scheme-specific requirements. Most URI schemes represent 443 data octets by the US-ASCII character corresponding to that octet, 444 either directly in the form of the character's glyph or by use of an 445 escape triplet (Section 2.4). 447 When a URI scheme defines a component that represents textual data 448 consisting of characters from the Unicode (ISO 10646) character set, 449 we recommend that the data be encoded first as octets according to 450 the UTF-8 [UTF-8] character encoding, and then escaping any octets 451 that are not in the unreserved character set. 453 2.2 Reserved Characters 455 URIs include components and sub-components that are delimited by 456 certain special characters. These characters are called "reserved", 457 since their usage within a URI component is limited to their reserved 458 purpose within that component. If data for a URI component would 459 conflict with the reserved purpose, then the conflicting data must be 460 escaped (Section 2.4) before forming the URI. 462 reserved = "/" / "?" / "#" / "[" / "]" / ";" / 463 ":" / "@" / "&" / "=" / "+" / "$" / "," 465 Reserved characters are used as delimiters of the generic URI 466 components described in Section 3, as well as within those components 467 for delimiting sub-components. A component's ABNF syntax rule will 468 not use the "reserved" production directly; instead, each rule lists 469 those reserved characters that are allowed within that component. 470 Allowed reserved characters that are not assigned a sub-component 471 delimiter role by this specification should be considered reserved 472 for special use by whatever software generates the URI (i.e., they 473 may be used to delimit or indicate information that is significant to 474 interpretation of the identifier, but that significance is outside 475 the scope of this specification). Outside of the URI's origin, a 476 reserved character cannot be escaped without fear of changing how it 477 will be interpreted; likewise, an escaped octet that corresponds to a 478 reserved character cannot be unescaped outside the software that is 479 responsible for interpreting it during URI resolution. 481 The slash ("/"), question-mark ("?"), and crosshatch ("#") characters 482 are reserved in all URI for the purpose of delimiting components that 483 are significant to the generic parser's hierarchical interpretation 484 of an identifier. The hierarchical prefix of a URI, wherein the 485 slash ("/") character signifies a hierarchy delimiter, extends from 486 the scheme (Section 3.1) through to the first question-mark ("?"), 487 crosshatch ("#"), or the end of the URI string. In other words, the 488 slash ("/") character is not treated as a hierarchical separator 489 within the query (Section 3.4) and fragment (Section 3.5) components 490 of a URI, but is still considered reserved within those components 491 for purposes outside the scope of this specification. 493 2.3 Unreserved Characters 495 Data characters that are allowed in a URI but do not have a reserved 496 purpose are called unreserved. These include uppercase and lowercase 497 letters, decimal digits, and a limited set of punctuation marks and 498 symbols. 500 unreserved = ALPHA / DIGIT / mark 502 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" 504 Unreserved characters can be escaped without changing the semantics 505 of a URI, but this should not be done unless the URI is being used in 506 a context that does not allow the unescaped character to appear. URI 507 normalization processes may unescape sequences in the ranges of ALPHA 508 (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), underscore 509 (%5F), or tilde (%7E) without fear of creating a conflict, but 510 unescaping the other mark characters is usually counterproductive. 512 2.4 Escaped Characters 514 Data must be escaped if it does not have a representation using an 515 unreserved character; this includes data that does not correspond to 516 a printable character of the US-ASCII coded character set or 517 corresponds to a US-ASCII character that delimits the component from 518 others, is reserved in that component for delimiting sub-components, 519 or is excluded from any use within a URI (Section 2.5). 521 2.4.1 Escaped Encoding 523 An escaped octet is encoded as a character triplet, consisting of 524 the percent character "%" followed by the two hexadecimal digits 525 representing that octet's numeric value. For example, "%20" is the 526 escaped encoding for the US-ASCII space character (SP). This is 527 sometimes referred to as "percent-encoding" the octet. 529 escaped = "%" HEXDIG HEXDIG 531 The uppercase hexadecimal digits 'A' through 'F' are equivalent to 532 the lowercase digits 'a' through 'f', respectively. Two URIs that 533 differ only in the case of hexadecimal digits used in escaped octets 534 are equivalent. For consistency, we recommend that uppercase digits 535 be used by URI generators and normalizers. 537 2.4.2 When to Escape and Unescape 539 Under normal circumstances, the only time that characters within a 540 URI string are escaped is during the process of generating the URI 541 from its component parts. Each component may have its own set of 542 characters that are reserved, so only the mechanism responsible for 543 generating or interpreting that component can determine whether or 544 not escaping a character will change its semantics. The exception is 545 when a URI is being used within a context where the unreserved "mark" 546 characters might need to be escaped, such as when used for a 547 command-line argument or within a single-quoted attribute. 549 Once generated, a URI is always in an escaped form. When a URI is 550 resolved, the components significant to that scheme-specific 551 resolution process (if any) must be parsed and separated before the 552 escaped characters within those components can be safely unescaped. 554 In some cases, data that could be represented by an unreserved 555 character may appear escaped; for example, some of the unreserved 556 "mark" characters are automatically escaped by some systems. A URI 557 normalizer may unescape escaped octets that are represented by 558 characters in the unreserved set. For example, "%7E" is sometimes 559 used instead of tilde ("~") in an "http" URI path and can be 560 converted to "~" without changing the interpretation of the URI. 562 Because the percent ("%") character serves as the escape indicator, 563 it must be escaped as "%25" in order for that octet to be used as 564 data within a URI. Implementers should be careful not to escape or 565 unescape the same string more than once, since unescaping an already 566 unescaped string might lead to misinterpreting a percent data 567 character as another escaped character, or vice versa in the case of 568 escaping an already escaped string. 570 2.5 Excluded Characters 572 Although they are disallowed within the URI syntax, we include here 573 a description of those characters that have been excluded and the 574 reasons for their exclusion. 576 excluded = invisible / delims / unwise 578 The control characters (CTL) in the US-ASCII coded character set are 579 not used within a URI, both because they are non-printable and 580 because they are likely to be misinterpreted by some control 581 mechanisms. The space character (SP) is excluded because significant 582 spaces may disappear and insignificant spaces may be introduced when 583 a URI is transcribed, typeset, or subjected to the treatment of 584 word-processing programs. Whitespace is also used to delimit a URI 585 in many contexts. Characters outside the US-ASCII set are excluded as 586 well. 588 invisible = CTL / SP / %x80-FF 590 The angle-bracket ("<" and ">") and double-quote (") characters are 591 excluded because they are often used as the delimiters around a URI 592 in text documents and protocol fields. The percent character ("%") 593 is excluded because it is used for the encoding of escaped (Section 594 2.4) characters. 596 delims = "<" / ">" / "%" / DQUOTE 598 Other characters are excluded because gateways and other transport 599 agents are known to sometimes modify such characters. 601 unwise = "{" / "}" / "|" / "\" / "^" / "`" 603 Data octets corresponding to excluded characters must be escaped in 604 order to be represented within a URI. 606 3. Syntax Components 608 The generic URI syntax consists of a hierarchical sequence of 609 components referred to as the scheme, authority, path, query, and 610 fragment. 612 URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] 614 hier-part = net-path / abs-path / rel-path 616 net-path = "//" authority [ abs-path ] 617 abs-path = "/" path-segments 618 rel-path = path-segments 620 The scheme and path components are required, though path may be empty 621 (no characters). An ABNF-driven parser of hier-part will find that 622 the three productions in the rule are ambiguous: they are 623 disambiguated by the "first-match-wins" (a.k.a. "greedy") algorithm. 624 In other words, if the string begins with two slash characters ("// 625 "), then it is a net-path; if it begins with only one slash 626 character, then it is an abs-path; otherwise, it is a rel-path. Note 627 that rel-path does not necessarily contain any slash ("/") 628 characters; a non-hierarchical path will be treated as opaque data by 629 a generic URI parser. 631 The authority component is only present when a string matches the 632 net-path production. Since the presence of an authority component 633 restricts the remaining syntax for path, we have not included a 634 specific "path" rule in the syntax. Instead, what we refer to as the 635 URI path is that part of the parsed URI string matching the abs-path 636 or rel-path production in the syntax above, since they are mutually 637 exclusive for any given URI and can be parsed as a single component. 639 3.1 Scheme 641 Each URI begins with a scheme name that refers to a specification for 642 assigning identifiers within that scheme. As such, the URI syntax is 643 a federated and extensible naming system wherein each scheme's 644 specification may further restrict the syntax and semantics of 645 identifiers using that scheme. 647 Scheme names consist of a sequence of characters beginning with a 648 letter and followed by any combination of letters, digits, plus 649 ("+"), period ("."), or hyphen ("-"). Although scheme is 650 case-insensitive, the canonical form is lowercase and documents that 651 specify schemes must do so using lowercase letters. An 652 implementation should accept uppercase letters as equivalent to 653 lowercase in scheme names (e.g., allow "HTTP" as well as "http"), for 654 the sake of robustness, but should only generate lowercase scheme 655 names, for consistency. 657 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) 659 Individual schemes are not specified by this document. The process 660 for registration of new URI schemes is defined separately by 661 [RFC2717]. The scheme registry maintains the mapping between scheme 662 names and their specifications. 664 3.2 Authority 666 Many URI schemes include a hierarchical element for a naming 667 authority, such that governance of the name space defined by the 668 remainder of the URI is delegated to that authority (which may, in 669 turn, delegate it further). The generic syntax provides a common 670 means for distinguishing an authority based on a registered domain 671 name or server address, along with optional port and user 672 information. 674 The authority component is preceded by a double slash ("//") and is 675 terminated by the next slash ("/"), question-mark ("?"), or 676 crosshatch ("#") character, or by the end of the URI. 678 authority = [ userinfo "@" ] host [ ":" port ] 680 The parts "@" and ":" may be omitted. 682 Some schemes do not allow the userinfo and/or port sub-components. 683 When presented with a URI that violates one or more scheme-specific 684 restrictions, the scheme-specific URI resolution process should flag 685 the reference as an error rather than ignore the unused parts; doing 686 so reduces the number of equivalent URIs and helps detect abuses of 687 the generic syntax that might indicate the URI has been constructed 688 to mislead the user (Section 7.5). 690 3.2.1 User Information 692 The userinfo sub-component may consist of a user name and, 693 optionally, scheme-specific information about how to gain 694 authorization to access the server. The user information, if 695 present, is followed by a commercial at-sign ("@") that delimits it 696 from the host. 698 userinfo = *( unreserved / escaped / ";" / 699 ":" / "&" / "=" / "+" / "$" / "," ) 701 Some URI schemes use the format "user:password" in the userinfo 702 field. This practice is NOT RECOMMENDED, because the passing of 703 authentication information in clear text has proven to be a security 704 risk in almost every case where it has been used. Note also that 705 userinfo might be crafted to look like a trusted domain name in order 706 to mislead users, as described in Section 7.5. 708 3.2.2 Host 710 The host sub-component of authority is identified by an IPv6 literal 711 encapsulated within square brackets, an IPv4 address in 712 dotted-decimal form, or a domain name. 714 host = [ IPv6reference / IPv4address / hostname ] 716 If host is omitted, a default may be defined by the scheme-specific 717 semantics of the URI. For example, the "file" URI scheme defaults to 718 "localhost", whereas the "http" URI scheme does not allow host to be 719 omitted. 721 The production for host is ambiguous because it does not completely 722 distinguish between an IPv4address and a hostname. Again, the 723 "first-match-wins" algorithm applies: If host matches the production 724 for IPv4address, then it should be considered an IPv4 address literal 725 and not a hostname. 727 A hostname takes the form described in Section 3 of [RFC1034] and 728 Section 2.1 of [RFC1123]: a sequence of domain labels separated by 729 ".", each domain label starting and ending with an alphanumeric 730 character and possibly also containing "-" characters. The rightmost 731 domain label of a fully qualified domain name may be followed by a 732 single "." if it is necessary to distinguish between the complete 733 domain name and some local domain. 735 hostname = domainlabel qualified 736 qualified = *( "." domainlabel ) [ "." ] 737 domainlabel = alphanum [ 0*61( alphanum / "-" ) alphanum ] 738 alphanum = ALPHA / DIGIT 740 A host identified by an IPv4 literal address is represented in 741 dotted-decimal notation (a sequence of four decimal numbers in the 742 range 0 to 255, separated by "."), as described in [RFC1123] by 743 reference to [RFC0952]. Note that other forms of dotted notation may 744 be interpreted on some platforms, as described in Section 7.3, but 745 only the dotted-decimal form of four octets is allowed by this 746 grammar. 748 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet 749 dec-octet = DIGIT ; 0-9 750 / %x31-39 DIGIT ; 10-99 751 / "1" 2DIGIT ; 100-199 752 / "2" %x30-34 DIGIT ; 200-249 753 / "25" %x30-35 ; 250-255 755 A host identified by an IPv6 literal address [RFC3513] is 756 distinguished by enclosing the IPv6 literal within square-brackets 757 ("[" and "]"). This is the only place where square-bracket 758 characters are allowed in the URI syntax. 760 IPv6reference = "[" IPv6address "]" 762 IPv6address = 6( h4 ":" ) ls32 763 / "::" 5( h4 ":" ) ls32 764 / [ h4 ] "::" 4( h4 ":" ) ls32 765 / [ *1( h4 ":" ) h4 ] "::" 3( h4 ":" ) ls32 766 / [ *2( h4 ":" ) h4 ] "::" 2( h4 ":" ) ls32 767 / [ *3( h4 ":" ) h4 ] "::" h4 ":" ls32 768 / [ *4( h4 ":" ) h4 ] "::" ls32 769 / [ *5( h4 ":" ) h4 ] "::" h4 770 / [ *6( h4 ":" ) h4 ] "::" 772 ls32 = ( h4 ":" h4 ) / IPv4address 773 ; least-significant 32 bits of address 775 h4 = 1*4HEXDIG 777 The presence of host within a URI does not imply that the scheme 778 requires access to the given host on the Internet. In many cases, 779 the host syntax is used only for the sake of reusing the existing 780 registration process created and deployed for DNS, thus obtaining a 781 globally unique name without the cost of deploying another registry. 782 However, such use comes with its own costs: domain name ownership may 783 change over time for reasons not anticipated by the URI creator. 785 3.2.3 Port 787 The port sub-component of authority is designated by an optional 788 port number in decimal following the host and delimited from it by a 789 single colon (":") character. 791 port = *DIGIT 793 If port is omitted, a default may be defined by the scheme-specific 794 semantics of the URI. Likewise, the type of network port designated 795 by the port number (e.g., TCP, UDP, SCTP, etc.) is defined by the URI 796 scheme. For example, the "http" URI scheme defines a default of TCP 797 port 80. 799 3.3 Path 801 The path component contains hierarchical data that, along with data 802 in the optional query (Section 3.4) component, serves to identify a 803 resource within the scope of that URI's scheme and naming authority 804 (if any). There is no specific "path" syntax production in the 805 generic URI syntax. Instead, what we refer to as the URI path is 806 that part of the parsed URI string matching either the abs-path or 807 the rel-path production, since they are mutually exclusive for any 808 given URI and can be parsed as a single component. The path is 809 terminated by the first question-mark ("?") or crosshatch ("#") 810 character, or by the end of the URI. 812 path-segments = segment *( "/" segment ) 813 segment = *pchar 815 pchar = unreserved / escaped / ";" / 816 ":" / "@" / "&" / "=" / "+" / "$" / "," 818 The path consists of a sequence of path segments separated by a slash 819 ("/") character. A path is always defined for a URI, though the 820 defined path may be empty (zero length) or opaque (not containing any 821 "/" delimiters). For example, the URI has 822 a path of "fred@example.com". 824 Within a path segment, the semicolon (";") and equals ("=") reserved 825 characters are often used for delimiting parameters and parameter 826 values applicable to that segment. The comma (",") reserved 827 character is often used for similar purposes. For example, one URI 828 generator might use a segment like "name;v=1.1" to indicate a 829 reference to version 1.1 of "name", whereas another might use a 830 segment like "name,1.1" to indicate the same. Parameter types may be 831 defined by scheme-specific semantics, but in most cases the meaning 832 of a parameter is specific to the URI originator. Parameters are not 833 significant to the parsing of relative references. 835 The path segments "." and ".." are defined for relative reference 836 within the path name hierarchy. They are intended for use at the 837 beginning of a relative path reference (Section 4.2) for indicating 838 relative position within the hierarchical tree of names, with a 839 similar effect to how they are used within some operating systems' 840 file directory structure to indicate the current directory and parent 841 directory, respectively. Unlike a file system, however, these 842 dot-segments are only interpreted within the URI path hierarchy and 843 must be removed as part of the URI normalization or resolution 844 process, in accordance with the process described in Section 5.2. 846 3.4 Query 848 The query component contains non-hierarchical data that, along with 849 data in the path (Section 3.3) component, serves to identify a 850 resource within the scope of that URI's scheme and naming authority 851 (if any). The query component is indicated by the first question-mark 852 ("?") character and terminated by a crosshatch ("#") character or by 853 the end of the URI. 855 query = *( pchar / "/" / "?" ) 857 The characters slash ("/") and question-mark ("?") are allowed to 858 represent data within the query component, but such use is 859 discouraged; incorrect implementations of relative URI resolution 860 often fail to distinguish them from hierarchical separators, thus 861 resulting in non-interoperable results while parsing relative 862 references. However, since query components are often used to carry 863 identifying information in the form of "key=value" pairs, and one 864 frequently used value is a reference to another URI, it is sometimes 865 better for usability to include those characters unescaped. 867 3.5 Fragment 869 The fragment identifier component allows indirect identification of 870 a secondary resource by reference to a primary resource and 871 additional identifying information that is selective within that 872 resource. The identified secondary resource may be some portion or 873 subset of the primary resource, some view on representations of the 874 primary resource, or some other resource that is merely named within 875 the primary resource. A fragment identifier component is indicated 876 by the presence of a crosshatch ("#") character and terminated by the 877 end of the URI string. 879 fragment = *( pchar / "/" / "?" ) 881 The semantics of a fragment identifier are defined by the set of 882 representations that might result from a retrieval action on the 883 primary resource. Therefore, the format and interpretation of a 884 fragment identifier component is dependent on the media type 885 [RFC2046] of a potential retrieval result. Individual media types 886 may define their own restrictions on, or structure within, the 887 fragment identifier syntax for specifying different types of subsets, 888 views, or external references that are identifiable as fragments by 889 that media type. If the primary resource is represented by multiple 890 media types, as is often the case for resources whose representation 891 is selected based on attributes of the retrieval request, then 892 interpretation of the given fragment identifier must be consistent 893 across all of those media types in order for it to be viable as an 894 identifier. 896 As with any URI, use of a fragment identifier component does not 897 imply that a retrieval action will take place. A URI with a fragment 898 identifier may be used to refer to the secondary resource without any 899 implication that the primary resource is accessible. However, if 900 that URI is used in a context that does call for retrieval and is not 901 a same-document reference (Section 4.4), the fragment identifier is 902 only valid as a reference if a retrieval action on the primary 903 resource succeeds and results in a representation that defines the 904 fragment. 906 Fragment identifiers have a special role in information systems as 907 the primary form of client-side indirect referencing, allowing an 908 author to specifically identify those aspects of an existing resource 909 that are only indirectly provided by the resource owner. As such, 910 interpretation of the fragment identifier during a retrieval action 911 is performed solely by the user agent; the fragment identifier is not 912 passed to other systems during the process of retrieval. Although 913 this is often perceived to be a loss of information, particularly in 914 regards to accurate redirection of references as content moves over 915 time, it also serves to prevent information providers from denying 916 reference authors the right to selectively refer to information 917 within a resource. 919 The characters slash ("/") and question-mark ("?") are allowed to 920 represent data within the fragment identifier, but such use is 921 discouraged for the same reasons as described above for query. 923 4. Usage 925 When applications make reference to a URI, they do not always use the 926 full form of reference defined by the "URI" syntax production. In 927 order to save space and take advantage of hierarchical locality, many 928 Internet protocol elements and media type formats allow an 929 abbreviation of a URI, while others restrict the syntax to a 930 particular form of URI. We define the most common forms of reference 931 syntax in this specification because they impact and depend upon the 932 design of the generic syntax, requiring a uniform parsing algorithm 933 in order to be interpreted consistently. 935 4.1 URI Reference 937 The ABNF rule URI-reference is used to denote the most common usage 938 of a resource identifier. 940 URI-reference = URI / relative-URI 942 A URI-reference may be absolute or relative: if the reference 943 string's prefix matches the syntax of a scheme followed by its colon 944 separator, then the reference is a URI rather than a relative-URI. 946 A URI-reference is typically parsed first into the five URI 947 components, in order to determine what components are present and 948 whether the reference is relative or absolute, and then each 949 component is parsed for its subparts and their validation. The ABNF 950 of URI-reference, along with the "first-match-wins" disambiguation 951 rule, is sufficient to define a validating parser for the generic 952 syntax. Readers familiar with regular expressions should see 953 Appendix B for an example of a non-validating URI-reference parser 954 that will take any given string and extract the URI components. 956 4.2 Relative URI 958 A relative URI reference takes advantage of the hier-part syntax 959 (Section 3) in order to express a reference that is relative to the 960 name space of another hierarchical URI. 962 relative-URI = hier-part [ "?" query ] [ "#" fragment ] 964 The URI referred to by a relative URI reference is obtained by 965 applying the relative resolution algorithm of Section 5. 967 A relative reference that begins with two slash characters is termed 968 a network-path reference; such references are rarely used. A relative 969 reference that begins with a single slash character is termed an 970 absolute-path reference. A relative reference that does not begin 971 with a slash character is termed a relative-path reference. 973 A path segment that contains a colon character (e.g., "this:that") 974 cannot be used as the first segment of a relative-path reference 975 because it might be mistaken for a scheme name. Such a segment must 976 be preceded by a dot-segment (e.g., "./this:that") to make a 977 relative-path reference. 979 4.3 Absolute URI 981 Some protocol elements allow only the absolute form of a URI without 982 a fragment identifier. For example, defining the base URI for later 983 use by relative references calls for an absolute-URI production that 984 does not allow a fragment. 986 absolute-URI = scheme ":" hier-part [ "?" query ] 988 4.4 Same-document Reference 990 When a URI reference occurring within a document or message refers to 991 a URI that is, aside from its fragment component (if any), identical 992 to the base URI (Section 5), that reference is called a 993 "same-document" reference. The most frequent examples of 994 same-document references are relative references that are empty or 995 include only the crosshatch ("#") separator followed by a fragment 996 identifier. 998 When a same-document reference is dereferenced for the purpose of a 999 retrieval action, the target of that reference is defined to be 1000 within that current document or message; the dereference should not 1001 result in a new retrieval. 1003 4.5 Suffix Reference 1005 The URI syntax is designed for unambiguous reference to resources and 1006 extensibility via the URI scheme. However, as URI identification and 1007 usage have become commonplace, traditional media (television, radio, 1008 newspapers, billboards, etc.) have increasingly used a suffix of the 1009 URI as a reference, consisting of only the authority and path 1010 portions of the URI, such as 1012 www.w3.org/Addressing/ 1014 or simply the DNS hostname on its own. Such references are primarily 1015 intended for human interpretation rather than machine, with the 1016 assumption that context-based heuristics are sufficient to complete 1017 the URI (e.g., most hostnames beginning with "www" are likely to have 1018 a URI prefix of "http://"). Although there is no standard set of 1019 heuristics for disambiguating a URI suffix, many client 1020 implementations allow them to be entered by the user and 1021 heuristically resolved. It should be noted that such heuristics may 1022 change over time, particularly when new URI schemes are introduced. 1024 Since a URI suffix has the same syntax as a relative path reference, 1025 a suffix reference cannot be used in contexts where relative URIs are 1026 expected. This limits use of suffix references to those places where 1027 there is no defined base URI, such as dialog boxes and off-line 1028 advertisements. 1030 5. Relative Resolution 1032 It is often the case that a group or "tree" of documents has been 1033 constructed to serve a common purpose; the vast majority of URIs in 1034 these documents point to resources within the tree rather than 1035 outside of it. Similarly, documents located at a particular site are 1036 much more likely to refer to other resources at that site than to 1037 resources at remote sites. 1039 Relative referencing of URIs allows document trees to be partially 1040 independent of their location and access scheme. For instance, it is 1041 possible for a single set of hypertext documents to be simultaneously 1042 accessible and traversable via each of the "file", "http", and "ftp" 1043 schemes if the documents refer to each other using relative URIs. 1044 Furthermore, such document trees can be moved, as a whole, without 1045 changing any of the relative references. Experience within the WWW 1046 has demonstrated that the ability to perform relative referencing is 1047 necessary for the long-term usability of embedded URIs. 1049 5.1 Establishing a Base URI 1051 The term "relative URI" implies that there exists some absolute "base 1052 URI" against which the relative reference is applied. Indeed, the 1053 base URI is necessary to define the semantics of any relative URI 1054 reference; without it, a relative reference is meaningless. In order 1055 for relative URI to be usable within a document, the base URI of that 1056 document must be known to the parser. 1058 A document that contains relative references must have a base URI 1059 that contains a hierarchical path component. In other words, a 1060 relative-URI cannot be used within a document that has an unsuitable 1061 base URI. Some URI schemes do not allow a hierarchical path component 1062 and are thus restricted to full URI references. 1064 An authority component is not required for a URI scheme to make use 1065 of relative references. A base URI without an authority component 1066 implies that any relative reference will also be without an authority 1067 component. 1069 The base URI of a document can be established in one of four ways, 1070 listed below in order of precedence. The order of precedence can be 1071 thought of in terms of layers, where the innermost defined base URI 1072 has the highest precedence. This can be visualized graphically as: 1074 .----------------------------------------------------------. 1075 | .----------------------------------------------------. | 1076 | | .----------------------------------------------. | | 1077 | | | .----------------------------------------. | | | 1078 | | | | .----------------------------------. | | | | 1079 | | | | | | | | | | 1080 | | | | `----------------------------------' | | | | 1081 | | | | (5.1.1) Base URI embedded in the | | | | 1082 | | | | document's content | | | | 1083 | | | `----------------------------------------' | | | 1084 | | | (5.1.2) Base URI of the encapsulating entity | | | 1085 | | | (message, document, or none). | | | 1086 | | `----------------------------------------------' | | 1087 | | (5.1.3) URI used to retrieve the entity | | 1088 | `----------------------------------------------------' | 1089 | (5.1.4) Default Base URI is application-dependent | 1090 `----------------------------------------------------------' 1092 5.1.1 Base URI within Document Content 1094 Within certain document media types, the base URI of the document can 1095 be embedded within the content itself such that it can be readily 1096 obtained by a parser. This can be useful for descriptive documents, 1097 such as tables of content, which may be transmitted to others through 1098 protocols other than their usual retrieval context (e.g., E-Mail or 1099 USENET news). 1101 It is beyond the scope of this document to specify how, for each 1102 media type, the base URI can be embedded. It is assumed that user 1103 agents manipulating such media types will be able to obtain the 1104 appropriate syntax from that media type's specification. An example 1105 of how the base URI can be embedded in the Hypertext Markup Language 1106 (HTML) [HTML] is provided in Appendix D. 1108 A mechanism for embedding the base URI within MIME container types 1109 (e.g., the message and multipart types) is defined by MHTML 1110 [RFC2110]. Protocols that do not use the MIME message header syntax, 1111 but do allow some form of tagged metadata to be included within 1112 messages, may define their own syntax for defining the base URI as 1113 part of a message. 1115 5.1.2 Base URI from the Encapsulating Entity 1117 If no base URI is embedded, the base URI of a document is defined by 1118 the document's retrieval context. For a document that is enclosed 1119 within another entity (such as a message or another document), the 1120 retrieval context is that entity; thus, the default base URI of the 1121 document is the base URI of the entity in which the document is 1122 encapsulated. 1124 5.1.3 Base URI from the Retrieval URI 1126 If no base URI is embedded and the document is not encapsulated 1127 within some other entity (e.g., the top level of a composite entity), 1128 then, if a URI was used to retrieve the base document, that URI shall 1129 be considered the base URI. Note that if the retrieval was the 1130 result of a redirected request, the last URI used (i.e., that which 1131 resulted in the actual retrieval of the document) is the base URI. 1133 5.1.4 Default Base URI 1135 If none of the conditions described in above apply, then the base URI 1136 is defined by the context of the application. Since this definition 1137 is necessarily application-dependent, failing to define the base URI 1138 using one of the other methods may result in the same content being 1139 interpreted differently by different types of application. 1141 It is the responsibility of the distributor(s) of a document 1142 containing a relative URI to ensure that the base URI for that 1143 document can be established. It must be emphasized that a relative 1144 URI cannot be used reliably in situations where the document's base 1145 URI is not well-defined. 1147 5.2 Obtaining the Referenced URI 1149 This section describes an example algorithm for resolving URI 1150 references that might be relative to a given base URI. The algorithm 1151 is intended to provide a definitive result that can be used to test 1152 the output of other implementations. Implementation of the algorithm 1153 itself is not required, but the result given by an implementation 1154 must match the result that would be given by this algorithm. 1156 The base URI (Base) is established according to the rules of Section 1157 5.1 and parsed into the five main components described in Section 3. 1158 Note that only the scheme component is required to be present in the 1159 base URI; the other components may be empty or undefined. A 1160 component is undefined if its preceding separator does not appear in 1161 the URI reference; the path component is never undefined, though it 1162 may be empty. 1164 For each URI reference (R), the following pseudocode describes an 1165 algorithm for transforming R into its target URI (T): 1167 (R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R); 1168 -- The URI reference is parsed into the five URI components 1170 if ((not validating) and (R.scheme == Base.scheme)) then 1171 -- A non-validating parser may ignore a scheme in the 1172 -- reference if it is identical to the base URI's scheme. 1173 undefine(R.scheme); 1174 endif; 1176 if defined(R.scheme) then 1177 T.scheme = R.scheme; 1178 T.authority = R.authority; 1179 T.path = R.path; 1180 T.query = R.query; 1181 else 1182 if defined(R.authority) then 1183 T.authority = R.authority; 1184 T.path = R.path; 1185 T.query = R.query; 1186 else 1187 if (R.path == "") then 1188 T.path = Base.path; 1189 if defined(R.query) then 1190 T.query = R.query; 1191 else 1192 T.query = Base.query; 1193 endif; 1194 else 1195 if (R.path starts-with "/") then 1196 T.path = R.path; 1197 else 1198 T.path = merge(Base.path, R.path); 1199 endif; 1200 T.query = R.query; 1201 endif; 1202 T.authority = Base.authority; 1203 endif; 1204 T.scheme = Base.scheme; 1205 endif; 1207 T.fragment = R.fragment; 1209 The pseudocode above refers to a merge routine for merging a 1210 relative-path reference with the path of the base URI to obtain the 1211 target path. Although there are many ways to do this, we will 1212 describe a simple method using a separate string buffer: 1214 1. All but the last segment of the base URI's path component is 1215 copied to the buffer. In other words, any characters after the 1216 last (right-most) slash character, if any, are excluded. If the 1217 base URI's path component is the empty string, then a single 1218 slash character ("/") is copied to the buffer. 1220 2. The reference's path component is appended to the buffer string. 1222 3. All occurrences of "./", where "." is a complete path segment, 1223 are removed from the buffer string. 1225 4. If the buffer string ends with "." as a complete path segment, 1226 that "." is removed. 1228 5. All occurrences of "/../", where is a complete 1229 path segment not equal to "..", are removed from the buffer 1230 string. Removal of these path segments is performed iteratively, 1231 removing the leftmost matching pattern on each iteration, until 1232 no matching pattern remains. 1234 6. If the buffer string ends with "/..", where is 1235 a complete path segment not equal to "..", that "/.." is 1236 removed. 1238 7. If the resulting buffer string still begins with one or more 1239 complete path segments of "..", then the reference is considered 1240 to be in error. Implementations may handle this error by 1241 removing them from the resolved path (i.e., discarding relative 1242 levels above the root) or by avoiding traversal of the reference. 1244 8. The remaining buffer string is the target URI's path component. 1246 Some systems may find it more efficient to implement the merge 1247 algorithm as a pair of path segment stacks being merged, rather than 1248 as a series of string pattern replacements. 1250 Note: Some WWW client applications will fail to separate the 1251 reference's query component from its path component before merging 1252 the base and reference paths. This may result in a loss of 1253 information if the query component contains the strings "/../" or 1254 "/./". 1256 5.3 Recomposition of a Parsed URI 1258 Parsed URI components can be recombined to obtain the referenced URI. 1259 Using pseudocode, this would be: 1261 result = "" 1263 if defined(T.scheme) then 1264 append T.scheme to result; 1265 append ":" to result; 1266 endif; 1267 if defined(T.authority) then 1268 append "//" to result; 1269 append T.authority to result; 1270 endif; 1272 append T.path to result; 1274 if defined(T.query) then 1275 append "?" to result; 1276 append T.query to result; 1277 endif; 1279 if defined(fragment) then 1280 append "#" to result; 1281 append fragment to result; 1282 endif; 1284 return result; 1286 Note that we are careful to preserve the distinction between a 1287 component that is undefined, meaning that its separator was not 1288 present in the reference, and a component that is empty, meaning that 1289 the separator was present and was immediately followed by the next 1290 component separator or the end of the reference. 1292 5.4 Examples of Relative Resolution 1294 Within an object with a well-defined base URI of 1296 http://a/b/c/d;p?q 1298 a relative URI reference would be resolved as follows: 1300 5.4.1 Normal Examples 1302 "g:h" = "g:h" 1303 "g" = "http://a/b/c/g" 1304 "./g" = "http://a/b/c/g" 1305 "g/" = "http://a/b/c/g/" 1306 "/g" = "http://a/g" 1307 "//g" = "http://g" 1308 "?y" = "http://a/b/c/d;p?y" 1309 "g?y" = "http://a/b/c/g?y" 1310 "#s" = "http://a/b/c/d;p?q#s" 1311 "g#s" = "http://a/b/c/g#s" 1312 "g?y#s" = "http://a/b/c/g?y#s" 1313 ";x" = "http://a/b/c/;x" 1314 "g;x" = "http://a/b/c/g;x" 1315 "g;x?y#s" = "http://a/b/c/g;x?y#s" 1316 "." = "http://a/b/c/" 1317 "./" = "http://a/b/c/" 1318 ".." = "http://a/b/" 1319 "../" = "http://a/b/" 1320 "../g" = "http://a/b/g" 1321 "../.." = "http://a/" 1322 "../../" = "http://a/" 1323 "../../g" = "http://a/g" 1325 5.4.2 Abnormal Examples 1327 Although the following abnormal examples are unlikely to occur in 1328 normal practice, all URI parsers should be capable of resolving them 1329 consistently. Each example uses the same base as above. 1331 An empty reference refers to the current base URI. 1333 "" = "http://a/b/c/d;p?q" 1335 Parsers must be careful in handling the case where there are more 1336 relative path ".." segments than there are hierarchical levels in the 1337 base URI's path. Note that the ".." syntax cannot be used to change 1338 the authority component of a URI. 1340 "../../../g" = "http://a/g" 1341 "../../../../g" = "http://a/g" 1343 Similarly, parsers should remove the dot-segments "." and ".." when 1344 they are complete components of a path, but not when they are only 1345 part of a segment. 1347 "/./g" = "http://a/g" 1348 "/../g" = "http://a/g" 1349 "g." = "http://a/b/c/g." 1350 ".g" = "http://a/b/c/.g" 1351 "g.." = "http://a/b/c/g.." 1352 "..g" = "http://a/b/c/..g" 1354 Less likely are cases where the relative URI uses unnecessary or 1355 nonsensical forms of the "." and ".." complete path segments. 1357 "./../g" = "http://a/b/g" 1358 "./g/." = "http://a/b/c/g/" 1359 "g/./h" = "http://a/b/c/g/h" 1360 "g/../h" = "http://a/b/c/h" 1361 "g;x=1/./y" = "http://a/b/c/g;x=1/y" 1362 "g;x=1/../y" = "http://a/b/c/y" 1364 Some applications fail to separate the reference's query and/or 1365 fragment components from a relative path before merging it with the 1366 base path. This error is rarely noticed, since typical usage of a 1367 fragment never includes the hierarchy ("/") character, and the query 1368 component is not normally used within relative references. 1370 "g?y/./x" = "http://a/b/c/g?y/./x" 1371 "g?y/../x" = "http://a/b/c/g?y/../x" 1372 "g#s/./x" = "http://a/b/c/g#s/./x" 1373 "g#s/../x" = "http://a/b/c/g#s/../x" 1375 Some parsers allow the scheme name to be present in a relative URI if 1376 it is the same as the base URI scheme. This is considered to be a 1377 loophole in prior specifications of partial URI [RFC1630]. Its use 1378 should be avoided, but is allowed for backward compatibility. 1380 "http:g" = "http:g" ; for validating parsers 1381 / "http://a/b/c/g" ; for backward compatibility 1383 6. Normalization and Comparison 1385 One of the most common operations on URIs is simple comparison: 1386 determining if two URIs are equivalent without using the URIs to 1387 access their respective resource(s). A comparison is performed every 1388 time a response cache is accessed, a browser checks its history to 1389 color a link, or an XML parser processes tags within a namespace. 1390 Extensive normalization prior to comparison of URIs is often used by 1391 spiders and indexing engines to prune a search space or reduce 1392 duplication of request actions and response storage. 1394 URI comparison is performed in respect to some particular purpose, 1395 and software with differing purposes will often be subject to 1396 differing design trade-offs in regards to how much effort should be 1397 spent in reducing duplicate identifiers. This section describes a 1398 variety of methods that may be used to compare URIs, the trade-offs 1399 between them, and the types of applications that might use them. 1401 6.1 Equivalence 1403 Since URIs exist to identify resources, presumably they should be 1404 considered equivalent when they identify the same resource. However, 1405 such a definition of equivalence is not of much practical use, since 1406 there is no way for software to compare two resources without 1407 knowledge of their origin. For this reason, determination of 1408 equivalence or difference of URIs is based on string comparison, 1409 perhaps augmented by reference to additional rules provided by URI 1410 scheme definitions. We use the terms "different" and "equivalent" to 1411 describe the possible outcomes of such comparisons, but there are 1412 many application-dependent versions of equivalence. 1414 Even though it is possible to determine that two URIs are equivalent, 1415 it is never possible to be sure that two URIs identify different 1416 resources. Therefore, comparison methods are designed to minimize 1417 false negatives while strictly avoiding false positives. 1419 In testing for equivalence, it is generally unwise to directly 1420 compare relative URI references; they should be converted to their 1421 absolute forms before comparison. Furthermore, when URI references 1422 are being compared for the purpose of selecting (or avoiding) a 1423 network action, such as retrieval of a representation, it is often 1424 necessary to remove fragment identifiers from the URIs prior to 1425 comparison. 1427 6.2 Comparison Ladder 1429 A variety of methods are used in practice to test URI equivalence. 1430 These methods fall into a range, distinguished by the amount of 1431 processing required and the degree to which the probability of false 1432 negatives is reduced. As noted above, false negatives cannot in 1433 principle be eliminated. In practice, their probability can be 1434 reduced, but this reduction requires more processing and is not 1435 cost-effective for all applications. 1437 If this range of comparison practices is considered as a ladder, the 1438 following discussion will climb the ladder, starting with those that 1439 are cheap but have a relatively higher chance of producing false 1440 negatives, and proceeding to those that have higher computational 1441 cost and lower risk of false negatives. 1443 6.2.1 Simple String Comparison 1445 If two URIs, considered as character strings, are identical, then it 1446 is safe to conclude that they are equivalent. This type of 1447 equivalence test has very low computational cost and is in wide use 1448 in a variety of applications, particularly in the domain of parsing. 1450 Testing strings for equivalence requires some basic precautions. This 1451 procedure is often referred to as "bit-for-bit" or "byte-for-byte" 1452 comparison, which is potentially misleading. Testing of strings for 1453 equality is normally based on pairwise comparison of the characters 1454 that make up the strings, starting from the first and proceeding 1455 until both strings are exhausted and all characters found to be 1456 equal, a pair of characters compares unequal, or one of the strings 1457 is exhausted before the other. 1459 Such character comparisons require that each pair of characters be 1460 put in comparable form. For example, should one URI be stored in a 1461 byte array in EBCDIC encoding, and the second be in a Java String 1462 object, bit-for-bit comparisons applied naively will produce both 1463 false-positive and false-negative errors. Thus, in principle, it is 1464 better to speak of equality on a character-for-character rather than 1465 byte-for-byte or bit-for-bit basis. 1467 Unicode defines a character as being identified by number 1468 ("codepoint") with an associated bundle of visual and other 1469 semantics. At the software level, it is not practical to compare 1470 semantic bundles, so in practical terms, character-by-character 1471 comparisons are done codepoint-by-codepoint. 1473 6.2.2 Syntax-based Normalization 1475 Software may use logic based on the definitions provided by this 1476 specification to reduce the probability of false negatives. Such 1477 processing is moderately higher in cost than character-for-character 1478 string comparison. For example, an application using this approach 1479 could reasonably consider the following two URIs equivalent: 1481 example://a/b/c/%7A 1482 eXAMPLE://a/./b/../b/c/%7a 1484 Web user agents, such as browsers, typically apply this type of URI 1485 normalization when determining whether a cached response is 1486 available. Syntax-based normalization includes such techniques as 1487 case normalization, escape normalization, and removal of leftover 1488 relative path segments. 1490 6.2.2.1 Case Normalization 1492 When a URI scheme uses components of the generic syntax, it will also 1493 use the common syntax equivalence rules, namely that the scheme and 1494 hostname are case insensitive and therefore can be normalized to 1495 lowercase. For example, the URI is 1496 equivalent to . 1498 6.2.2.2 Escape Normalization 1500 The percent-escape mechanism described in Section 2.4 is a frequent 1501 source of variance among otherwise identical URIs. One cause is the 1502 choice of uppercase or lowercase letters for the hexadecimal digits 1503 within the escape sequence (e.g., "%3a" versus "%3A"). Such sequences 1504 are always equivalent; for the sake of uniformity, URI generators and 1505 normalizers are strongly encouraged to use uppercase letters for the 1506 hex digits A-F. 1508 Only characters that are excluded from or reserved within the URI 1509 syntax must be escaped when used as data. However, some URI 1510 generators go beyond that and escape characters that do not require 1511 escaping, resulting in URIs that are equivalent to their unescaped 1512 counterparts. Such URIs can be normalized by unescaping sequences 1513 that represent the unreserved characters, as described in Section 1514 2.3. 1516 6.2.2.3 Path Segment Normalization 1518 The complete path segments "." and ".." have a special meaning within 1519 hierarchical URI schemes. As such, they should not appear in 1520 absolute URI paths; if they are found, they can be removed by 1521 splitting the URI just after the "/" that starts the path, using the 1522 left half as the base URI and the right as a relative reference, and 1523 normalizing the URI by merging the two in in accordance with the 1524 relative URI processing algorithm (Section 5). 1526 6.2.3 Scheme-based Normalization 1528 The syntax and semantics of URIs vary from scheme to scheme, as 1529 described by the defining specification for each scheme. Software 1530 may use scheme-specific rules, at further processing cost, to reduce 1531 the probability of false negatives. For example, Web spiders that 1532 populate most large search engines would consider the following two 1533 URIs to be equivalent: 1535 http://example.com/ 1536 http://example.com:80/ 1538 This behavior is based on the rules provided by the syntax and 1539 semantics of the "http" URI scheme, which defines an empty port 1540 component as being equivalent to the default TCP port for HTTP (port 1541 80). In general, a URI scheme that uses the generic syntax for 1542 authority is defined such that a URI with an explicit ":port", where 1543 the port is the default for the scheme, is equivalent to one where 1544 the port is elided. 1546 6.2.4 Protocol-based Normalization 1548 Web spiders, for which substantial effort to reduce the incidence of 1549 false negatives is often cost-effective, are observed to implement 1550 even more aggressive techniques in URI comparison. For example, if 1551 they observe that a URI such as 1553 http://example.com/data 1555 redirects to 1557 http://example.com/data/ 1559 they will likely regard the two as equivalent in the future. 1560 Obviously, this kind of technique is only appropriate in special 1561 situations. 1563 6.3 Canonical Form 1565 It is in the best interests of everyone to avoid false-negatives in 1566 comparing URIs and to minimize the amount of software processing for 1567 such comparisons. Those who generate and make reference to URIs can 1568 reduce the cost of processing and the risk of false negatives by 1569 consistently providing them in a form that is reasonably canonical 1570 with respect to their scheme. Specifically: 1572 Always provide the URI scheme in lowercase characters. 1574 Always provide the hostname, if any, in lowercase characters. 1576 Only perform percent-escaping where it is essential. 1578 Always use uppercase A-through-F characters when percent-escaping. 1580 Prevent /./ and /../ from appearing in non-relative URI paths. 1582 The good practices listed above are motivated by observations that a 1583 high proportion of deployed software use these techniques for the 1584 purposes of normalization. 1586 7. Security Considerations 1588 A URI does not in itself pose a security threat. However, since URIs 1589 are often used to provide a compact set of instructions for access to 1590 network resources, care must be taken to properly interpret the data 1591 within a URI, to prevent that data from causing unintended access, 1592 and to avoid including data that should not be revealed in plain 1593 text. 1595 7.1 Reliability and Consistency 1597 There is no guarantee that, having once used a given URI to retrieve 1598 some information, that the same information will be retrievable by 1599 that URI in the future. Nor is there any guarantee that the 1600 information retrievable via that URI in the future will be observably 1601 similar to that retrieved in the past. The URI syntax does not 1602 constrain how a given scheme or authority apportions its name space 1603 or maintains it over time. Such a guarantee can only be obtained 1604 from the person(s) controlling that name space and the resource in 1605 question. A specific URI scheme may define additional semantics, 1606 such as name persistence, if those semantics are required of all 1607 naming authorities for that scheme. 1609 7.2 Malicious Construction 1611 It is sometimes possible to construct a URI such that an attempt to 1612 perform a seemingly harmless, idempotent operation, such as the 1613 retrieval of a representation, will in fact cause a possibly damaging 1614 remote operation to occur. The unsafe URI is typically constructed 1615 by specifying a port number other than that reserved for the network 1616 protocol in question. The client unwittingly contacts a site that is 1617 running a different protocol service. The content of the URI 1618 contains instructions that, when interpreted according to this other 1619 protocol, cause an unexpected operation. An example has been the use 1620 of a gopher URI to cause an unintended or impersonating message to be 1621 sent via a SMTP server. 1623 Caution should be used when dereferencing a URI that specifies a TCP 1624 port number other than the default for the scheme, especially when it 1625 is a number within the reserved space. 1627 Care should be taken when a URI contains escaped delimiters for a 1628 given protocol (for example, CR and LF characters for telnet 1629 protocols) that these octets are not unescaped before transmission. 1630 This might violate the protocol, but avoids the potential for such 1631 characters to be used to simulate an extra operation or parameter in 1632 that protocol which might lead to an unexpected and possibly harmful 1633 remote operation being performed. 1635 7.3 Rare IP Address Formats 1637 Although the URI syntax for IPv4address only allows the common, 1638 dotted-decimal form of IPv4 address literal, many implementations 1639 that process URIs make use of platform-dependent system routines, 1640 such as gethostbyname() and inet_aton(), to translate the string 1641 literal to an actual IP address. Unfortunately, such system routines 1642 often allow and process a much larger set of formats than those 1643 described in Section 3.2.2. 1645 For example, many implementations allow dotted forms of three 1646 numbers, wherein the last part is interpreted as a 16-bit quantity 1647 and placed in the right-most two bytes of the network address (e.g., 1648 a Class B network). Likewise, a dotted form of two numbers means the 1649 last part is interpreted as a 24-bit quantity and placed in the right 1650 most three bytes of the network address (Class A), and a single 1651 number (without dots) is interpreted as a 32-bit quantity and stored 1652 directly in the network address. Adding further to the confusion, 1653 some implementations allow each dotted part to be interpreted as 1654 decimal, octal, or hexadecimal, as specified in the C language (i.e., 1655 a leading 0x or 0X implies hexadecimal; otherwise, a leading 0 1656 implies octal; otherwise, the number is interpreted as decimal). 1658 These additional IP address formats are not allowed in the URI syntax 1659 due to differences between platform implementations. However, they 1660 can become a security concern if an application attempts to filter 1661 access to resources based on the IP address in string literal format. 1662 If such filtering is performed, it is recommended that literals be 1663 converted to numeric form and filtered based on the numeric value, 1664 rather than a prefix or suffix of the string form. 1666 7.4 Sensitive Information 1668 It is clearly unwise to use a URI that contains a password which is 1669 intended to be secret. In particular, the use of a password within 1670 the userinfo component of a URI is strongly discouraged except in 1671 those rare cases where the 'password' parameter is intended to be 1672 public. 1674 7.5 Semantic Attacks 1676 Because the userinfo component is rarely used and appears before the 1677 hostname in the authority component, it can be used to construct a 1678 URI that is intended to mislead a human user by appearing to identify 1679 one (trusted) naming authority while actually identifying a different 1680 authority hidden behind the noise. For example 1682 http://www.example.com&story=breaking_news@10.0.0.1/top_story.htm 1684 might lead a human user to assume that the host is 'www.example.com', 1685 whereas it is actually '10.0.0.1'. Note that the misleading userinfo 1686 could be much longer than the example above. 1688 A misleading URI, such as the one above, is an attack on the user's 1689 preconceived notions about the meaning of a URI, rather than an 1690 attack on the software itself. User agents may be able to reduce the 1691 impact of such attacks by visually distinguishing the various 1692 components of the URI when rendered, such as by using a different 1693 color or tone to render userinfo if any is present, though there is 1694 no general panacea. More information on URI-based semantic attacks 1695 can be found in [Siedzik]. 1697 8. Acknowledgments 1699 This document is derived from RFC 2396 [RFC2396], RFC 1808 [RFC1808], 1700 and RFC 1738 [RFC1738]; the acknowledgments in those specifications 1701 still apply. It also incorporates the update (with corrections) for 1702 IPv6 literals in the host syntax, as defined by Robert M. Hinden, 1703 Brian E. Carpenter, and Larry Masinter in [RFC2732]. In addition, 1704 contributions by Reese Anschultz, Tim Bray, Rob Cameron, Dan 1705 Connolly, Adam M. Costello, Jason Diamond, Martin Duerst, Stefan 1706 Eissing, Clive D.W. Feather, Pat Hayes, Henry Holtzman, Graham Klyne, 1707 Dan Kohn, Bruce Lilly, Andrew Main, Michael Mealling, Julian Reschke, 1708 Tomas Rokicki, Miles Sabin, Ronald Tschalaer, Marc Warne, Stuart 1709 Williams, and Henry Zongaro are gratefully acknowledged. 1711 Normative References 1713 [ASCII] American National Standards Institute, "Coded Character 1714 Set -- 7-bit American Standard Code for Information 1715 Interchange", ANSI X3.4, 1986. 1717 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1718 Specifications: ABNF", RFC 2234, November 1997. 1720 Informative References 1722 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1723 Languages", BCP 18, RFC 2277, January 1998. 1725 [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A 1726 Unifying Syntax for the Expression of Names and Addresses 1727 of Objects on the Network as used in the World-Wide Web", 1728 RFC 1630, June 1994. 1730 [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform 1731 Resource Locators (URL)", RFC 1738, December 1994. 1733 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1734 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1735 August 1998. 1737 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1738 and Support", STD 3, RFC 1123, October 1989. 1740 [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC 1741 1808, June 1995. 1743 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1744 Extensions (MIME) Part Two: Media Types", RFC 2046, 1745 November 1996. 1747 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 1748 Jensen, "HTTP Extensions for Distributed Authoring -- 1749 WEBDAV", RFC 2518, February 1999. 1751 [RFC0952] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet 1752 host table specification", RFC 952, October 1985. 1754 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1755 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1757 [RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for 1758 Literal IPv6 Addresses in URL's", RFC 2732, December 1999. 1760 [RFC1736] Kunze, J., "Functional Recommendations for Internet 1761 Resource Locators", RFC 1736, February 1995. 1763 [RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for 1764 Uniform Resource Names", RFC 1737, December 1994. 1766 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1768 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1769 STD 13, RFC 1034, November 1987. 1771 [RFC2110] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of 1772 Aggregate Documents, such as HTML (MHTML)", RFC 2110, 1773 March 1997. 1775 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL 1776 Scheme Names", BCP 35, RFC 2717, November 1999. 1778 [HTML] Raggett, D., Le Hors, A. and I. Jacobs, "Hypertext Markup 1779 Language (HTML 4.01) Specification", December 1999. 1781 [Siedzik] Siedzik, R., "Semantic Attacks: What's in a URL?", April 1782 2001. 1784 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 1785 10646", RFC 2279, January 1998. 1787 Authors' Addresses 1789 Tim Berners-Lee 1790 World Wide Web Consortium 1791 MIT/LCS, Room NE43-356 1792 200 Technology Square 1793 Cambridge, MA 02139 1794 USA 1796 Phone: +1-617-253-5702 1797 Fax: +1-617-258-5999 1798 EMail: timbl@w3.org 1799 URI: http://www.w3.org/People/Berners-Lee/ 1801 Roy T. Fielding 1802 Day Software 1803 2 Corporate Plaza, Suite 150 1804 Newport Beach, CA 92660 1805 USA 1807 Phone: +1-949-999-2523 1808 Fax: +1-949-644-5064 1809 EMail: roy.fielding@day.com 1810 URI: http://www.apache.org/~fielding/ 1812 Larry Masinter 1813 Adobe Systems Incorporated 1814 345 Park Ave 1815 San Jose, CA 95110 1816 USA 1818 Phone: +1-408-536-3024 1819 EMail: LMM@acm.org 1820 URI: http://larry.masinter.net/ 1822 Appendix A. Collected ABNF for URI 1824 To be filled-in later. 1826 Appendix B. Parsing a URI Reference with a Regular Expression 1828 Since the "first-match-wins" algorithm is identical to the "greedy" 1829 disambiguation method used by POSIX regular expressions, it is 1830 natural and commonplace to use a regular expression for parsing the 1831 potential five components of a URI reference. 1833 The following line is the regular expression for breaking-down a 1834 well-formed URI reference into its components. 1836 ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))? 1837 12 3 4 5 6 7 8 9 1839 The numbers in the second line above are only to assist readability; 1840 they indicate the reference points for each subexpression (i.e., each 1841 paired parenthesis). We refer to the value matched for subexpression 1842 as $. For example, matching the above expression to 1844 http://www.ics.uci.edu/pub/ietf/uri/#Related 1846 results in the following subexpression matches: 1848 $1 = http: 1849 $2 = http 1850 $3 = //www.ics.uci.edu 1851 $4 = www.ics.uci.edu 1852 $5 = /pub/ietf/uri/ 1853 $6 = 1854 $7 = 1855 $8 = #Related 1856 $9 = Related 1858 where indicates that the component is not present, as is 1859 the case for the query component in the above example. Therefore, we 1860 can determine the value of the four components and fragment as 1862 scheme = $2 1863 authority = $4 1864 path = $5 1865 query = $7 1866 fragment = $9 1868 and, going in the opposite direction, we can recreate a URI reference 1869 from its components using the algorithm of Section 5.3. 1871 Appendix C. Embedding the Base URI in HTML documents 1873 It is useful to consider an example of how the base URI of a document 1874 can be embedded within the document's content. In this appendix, we 1875 describe how documents written in the Hypertext Markup Language 1876 (HTML) [HTML] can include an embedded base URI. This appendix does 1877 not form a part of the URI specification and should not be considered 1878 as anything more than a descriptive example. 1880 HTML defines a special element "BASE" which, when present in the 1881 "HEAD" portion of a document, signals that the parser should use the 1882 BASE element's "HREF" attribute as the base URI for resolving any 1883 relative URI. The "HREF" attribute must be an absolute URI. Note 1884 that, in HTML, element and attribute names are case-insensitive. For 1885 example: 1887 1888 1889 An example HTML document 1890 1891 1892 ... a hypertext anchor ... 1893 1895 A parser reading the example document should interpret the given 1896 relative URI "../x" as representing the absolute URI 1898 1900 regardless of the context in which the example document was obtained. 1902 Appendix D. Delimiting a URI in Context 1904 URIs are often transmitted through formats that do not provide a 1905 clear context for their interpretation. For example, there are many 1906 occasions when a URI is included in plain text; examples include text 1907 sent in electronic mail, USENET news messages, and, most importantly, 1908 printed on paper. In such cases, it is important to be able to 1909 delimit the URI from the rest of the text, and in particular from 1910 punctuation marks that might be mistaken for part of the URI. 1912 In practice, URI are delimited in a variety of ways, but usually 1913 within double-quotes "http://example.com/", angle brackets , or just using whitespace 1916 http://example.com/ 1918 These wrappers do not form part of the URI. 1920 In the case where a fragment identifier is associated with a URI 1921 reference, the fragment would be placed within the brackets as well 1922 (separated from the URI with a "#" character). 1924 In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may 1925 need to be added to break a long URI across lines. The whitespace 1926 should be ignored when extracting the URI. 1928 No whitespace should be introduced after a hyphen ("-") character. 1929 Because some typesetters and printers may (erroneously) introduce a 1930 hyphen at the end of line when breaking a line, the interpreter of a 1931 URI containing a line break immediately after a hyphen should ignore 1932 all unescaped whitespace around the line break, and should be aware 1933 that the hyphen may or may not actually be part of the URI. 1935 Using <> angle brackets around each URI is especially recommended as 1936 a delimiting style for a URI that contains whitespace. 1938 The prefix "URL:" (with or without a trailing space) was formerly 1939 recommended as a way to help distinguish a URI from other bracketed 1940 designators, though it is not commonly used in practice and is no 1941 longer recommended. 1943 For robustness, software that accepts user-typed URI should attempt 1944 to recognize and strip both delimiters and embedded whitespace. 1946 For example, the text: 1948 Yes, Jim, I found it under "http://www.w3.org/Addressing/", 1949 but you can probably pick it up from . Note the warning in . 1954 contains the URI references 1956 http://www.w3.org/Addressing/ 1957 ftp://ds.internic.net/rfc/ 1958 http://www.ics.uci.edu/pub/ietf/uri/historical.html#WARNING 1960 Appendix E. Summary of Non-editorial Changes 1962 E.1 Additions 1964 IPv6 literals have been added to the list of possible identifiers for 1965 the host portion of a authority component, as described by [RFC2732], 1966 with the addition of "[" and "]" to the reserved and uric sets. 1967 Square brackets are now specified as reserved within the authority 1968 component and not allowed outside their use as delimiters for an 1969 IPv6reference within host. In order to make this change without 1970 changing the technical definition of the path, query, and fragment 1971 components, those rules were redefined to directly specify the 1972 characters allowed rather than be defined in terms of uric. 1974 Since [RFC2732] defers to [RFC3513] for definition of an IPv6 literal 1975 address, which unfortunately lacks an ABNF description of 1976 IPv6address, we created a new ABNF rule for IPv6address that matches 1977 the text representations defined by Section 2.2 of [RFC3513]. 1978 Likewise, the definition of IPv4address has been improved in order to 1979 limit each decimal octet to the range 0-255, and the definition of 1980 hostname has been improved to better specify length limitations and 1981 partially-qualified domain names. 1983 Section 6 (Section 6) on URI normalization and comparison has been 1984 completely rewritten and extended using input from Tim Bray and 1985 discussion within the W3C Technical Architecture Group. Likewise, 1986 Section 2.1 on the encoding of characters has been replaced. 1988 An ABNF production for URI has been introduced to correspond to the 1989 common usage of the term: an absolute URI with optional fragment. 1991 E.2 Modifications from RFC 2396 1993 The ad-hoc BNF syntax has been replaced with the ABNF of [RFC2234]. 1994 This change required all rule names that formerly included underscore 1995 characters to be renamed with a dash instead. 1997 Section 2.2 on reserved characters has been rewritten to clearly 1998 explain what characters are reserved, when they are reserved, and why 1999 they are reserved even when not used as delimiters by the generic 2000 syntax. Likewise, the section on escaped characters has been 2001 rewritten, and URI normalizers are now given license to unescape any 2002 octets corresponding to unreserved characters. The crosshatch ("#") 2003 character has been moved back from the excluded delims to the 2004 reserved set. 2006 The ABNF for URI and URI-reference has been redesigned to make them 2007 more friendly to LALR parsers and significantly reduce complexity. As 2008 a result, the layout form of syntax description has been removed, 2009 along with the uric-no-slash, opaque-part, and rel-segment 2010 productions. All references to "opaque" URIs have been replaced with 2011 a better description of how the path component may be opaque to 2012 hierarchy. The fragment identifier has been moved back into the 2013 section on generic syntax components and within the URI and 2014 relative-URI productions, though it remains excluded from 2015 absolute-URI. The ambiguity regarding the parsing of URI-reference as 2016 a URI or a relative-URI with a colon in the first segment is now 2017 explained and disambiguated in the section defining relative-URI. 2019 The ABNF of hier-part and relative-URI has been corrected to allow a 2020 relative URI path to be empty. This also allows an absolute-URI to 2021 consist of nothing after the "scheme:", as is present in practice 2022 with the "DAV:" namespace [RFC2518] and the "about:" URI used by many 2023 browser implementations. The ambiguity regarding the parsing of 2024 net-path, abs-path, and rel-path is now explained and disambiguated 2025 in the same section. 2027 Registry-based naming authorities that use the hierarchical authority 2028 syntax component are now limited to DNS hostnames, since those have 2029 been the only such URIs in deployment. This change was necessary to 2030 enable internationalized domain names to be processed in their native 2031 character encodings at the application layers above URI processing. 2032 The reg_name, server, and hostport productions have been removed to 2033 simplify parsing of the URI syntax. 2035 The ABNF of qualified has been simplified to remove a parsing 2036 ambiguity without changing the allowed syntax. The toplabel 2037 production has been removed because it served no useful purpose. The 2038 ambiguity regarding the parsing of host as IPv4address or hostname is 2039 now explained and disambiguated in the same section. 2041 The resolving relative references algorithm of [RFC2396] has been 2042 rewritten using pseudocode for this revision to improve clarity and 2043 fix the following issues: 2045 o [RFC2396] section 5.2, step 6a, failed to account for a base URI 2046 with no path. 2048 o Restored the behavior of [RFC1808] where, if the reference 2049 contains an empty path and a defined query component, then the 2050 target URI inherits the base URI's path component. 2052 o Removed the special-case treatment of same-document references in 2053 favor of a section that explains that a new retrieval action 2054 should not be made if the target URI and base URI, excluding 2055 fragments, match. 2057 Index 2059 A 2060 ABNF 9 2061 abs-path 15 2062 absolute 9 2063 absolute-path 22 2064 absolute-URI 23 2065 access 7 2066 alphanum 17 2067 authority 15, 16 2069 D 2070 dec-octet 17 2071 delims 13 2072 dereference 8 2073 domainlabel 17 2074 dot-segments 19 2076 E 2077 escaped 12 2078 excluded 13 2080 F 2081 fragment 20 2083 G 2084 generic syntax 5 2086 H 2087 h4 18 2088 hier-part 15 2089 hierarchical 9 2090 host 17 2091 hostname 17 2093 I 2094 identifier 5 2095 invisible 13 2096 IPv4 17 2097 IPv4address 17 2098 IPv6 18 2099 IPv6address 18 2100 IPv6reference 18 2102 L 2103 locator 6 2104 ls32 18 2106 M 2107 mark 11 2109 N 2110 name 6 2111 net-path 15 2112 network-path 22 2114 P 2115 path 15, 19 2116 path-segments 19 2117 pchar 19 2118 port 18 2120 Q 2121 qualified 17 2122 query 20 2124 R 2125 rel-path 15 2126 relative 9 2127 relative-path 22 2128 relative-URI 22 2129 representation 8 2130 reserved 10 2131 resolution 8 2132 resource 4 2133 retrieval 8 2135 S 2136 same-document 23 2137 sameness 8 2138 scheme 15 2139 segment 19 2140 suffix 23 2142 T 2143 transcription 6 2145 U 2146 uniform 4 2147 unreserved 11 2148 unwise 13 2149 URI grammar 2150 abs-path 15 2151 absolute-URI 23 2152 ALPHA 9 2153 alphanum 17 2154 authority 15, 16 2155 CR 9 2156 CTL 9 2157 dec-octet 17 2158 DIGIT 9 2159 domainlabel 17 2160 DQUOTE 9 2161 escaped 12 2162 fragment 15, 20, 22 2163 h4 18 2164 HEXDIG 9 2165 hier-part 15, 22, 23 2166 host 16, 17 2167 hostname 17 2168 IPv4address 17 2169 IPv6address 18 2170 IPv6reference 18 2171 LF 9 2172 ls32 18 2173 mark 11 2174 net-path 15 2175 OCTET 9 2176 path-segments 15, 19 2177 pchar 19, 20, 20 2178 port 16, 18 2179 qualified 17 2180 query 15, 20, 22, 23 2181 rel-path 15 2182 relative-URI 22, 22 2183 reserved 11 2184 scheme 15, 16, 23 2185 segment 19 2186 SP 9 2187 unreserved 11 2188 URI 15, 22 2189 URI-reference 22 2190 uric 10 2191 userinfo 16, 16 2192 URI 15 2193 URI-reference 22 2194 uric 10 2195 URL 6 2196 URN 6 2197 userinfo 16 2199 Intellectual Property Statement 2201 The IETF takes no position regarding the validity or scope of any 2202 intellectual property or other rights that might be claimed to 2203 pertain to the implementation or use of the technology described in 2204 this document or the extent to which any license under such rights 2205 might or might not be available; neither does it represent that it 2206 has made any effort to identify any such rights. Information on the 2207 IETF's procedures with respect to rights in standards-track and 2208 standards-related documentation can be found in BCP-11. Copies of 2209 claims of rights made available for publication and any assurances of 2210 licenses to be made available, or the result of an attempt made to 2211 obtain a general license or permission for the use of such 2212 proprietary rights by implementors or users of this specification can 2213 be obtained from the IETF Secretariat. 2215 The IETF invites any interested party to bring to its attention any 2216 copyrights, patents or patent applications, or other proprietary 2217 rights which may cover technology that may be required to practice 2218 this standard. Please address the information to the IETF Executive 2219 Director. 2221 Full Copyright Statement 2223 Copyright (C) The Internet Society (2003). All Rights Reserved. 2225 This document and translations of it may be copied and furnished to 2226 others, and derivative works that comment on or otherwise explain it 2227 or assist in its implementation may be prepared, copied, published 2228 and distributed, in whole or in part, without restriction of any 2229 kind, provided that the above copyright notice and this paragraph are 2230 included on all such copies and derivative works. However, this 2231 document itself may not be modified in any way, such as by removing 2232 the copyright notice or references to the Internet Society or other 2233 Internet organizations, except as needed for the purpose of 2234 developing Internet standards in which case the procedures for 2235 copyrights defined in the Internet Standards process must be 2236 followed, or as required to translate it into languages other than 2237 English. 2239 The limited permissions granted above are perpetual and will not be 2240 revoked by the Internet Society or its successors or assignees. 2242 This document and the information contained herein is provided on an 2243 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2244 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2245 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2246 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2247 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2249 Acknowledgement 2251 Funding for the RFC Editor function is currently provided by the 2252 Internet Society.