1 |
Uniform Resource Identifiers Working Group R. T. Fielding |
2 |
INTERNET-DRAFT UC Irvine |
3 |
Expires July 18, 1995 January 18, 1995 |
4 |
|
5 |
|
6 |
Relative Uniform Resource Locators |
7 |
<draft-ietf-uri-relative-url-04.txt> |
8 |
|
9 |
|
10 |
Status of this Memo |
11 |
|
12 |
This document is an Internet-Draft. Internet-Drafts are working |
13 |
documents of the Internet Engineering Task Force (IETF), its areas, |
14 |
and its working groups. Note that other groups may also distribute |
15 |
working documents as Internet-Drafts. |
16 |
|
17 |
Internet-Drafts are draft documents valid for a maximum of six |
18 |
months and may be updated, replaced, or obsoleted by other |
19 |
documents at any time. It is inappropriate to use Internet- |
20 |
Drafts as reference material or to cite them other than as |
21 |
``work in progress.'' |
22 |
|
23 |
To learn the current status of any Internet-Draft, please check |
24 |
the ``1id-abstracts.txt'' listing contained in the Internet- |
25 |
Drafts Shadow Directories on ftp.is.co.za (Africa), |
26 |
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), |
27 |
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). |
28 |
|
29 |
Distribution of this document is unlimited. Please send comments |
30 |
to the author, Roy T. Fielding <fielding@ics.uci.edu>, or to the |
31 |
URI working group (URI-WG) of the Internet Engineering Task Force |
32 |
(IETF) at <uri@bunyip.com>. Discussions of the group are archived at |
33 |
<URL:http://www.acl.lanl.gov/URI/archive/uri-archive.index.html>. |
34 |
|
35 |
|
36 |
Abstract |
37 |
|
38 |
A Uniform Resource Locator (URL) is a compact representation of the |
39 |
location and access method for a resource available via the Internet. |
40 |
When embedded within a base document, a URL in its absolute form may |
41 |
contain a great deal of information which is already known from the |
42 |
context of that base document's retrieval, including the scheme, |
43 |
network location, and parts of the url-path. In situations where the |
44 |
base URL is well-defined and known to the parser (human or machine), |
45 |
it is useful to be able to embed URL references which inherit that |
46 |
context rather than re-specifying it in every instance. This |
47 |
document defines the syntax and semantics for such Relative Uniform |
48 |
Resource Locators. |
49 |
|
50 |
|
51 |
1. Introduction |
52 |
|
53 |
This document describes the syntax and semantics for "relative" |
54 |
Uniform Resource Locators (relative URLs): a compact representation |
55 |
of the location of a resource relative to an absolute base URL. |
56 |
It is a companion to RFC 1738, "Uniform Resource Locators (URL)" [2], |
57 |
which specifies the syntax and semantics of absolute URLs. |
58 |
|
59 |
A common use for Uniform Resource Locators is to embed them within |
60 |
a document (referred to as the "base" document) for the purpose of |
61 |
identifying other Internet-accessible resources. For example, in |
62 |
hypertext documents, URLs can be used as the identifiers for |
63 |
hypertext link destinations. |
64 |
|
65 |
Absolute URLs contain a great deal of information which may already |
66 |
be known from the context of the base document's retrieval, |
67 |
including the scheme, network location, and parts of the URL path. |
68 |
In situations where the base URL is well-defined and known, it is |
69 |
useful to be able to embed a URL reference which inherits that |
70 |
context rather than re-specifying it within each instance. |
71 |
Similarly, relative URLs can be used within data-entry dialogs to |
72 |
decrease the number of characters necessary to describe a location. |
73 |
|
74 |
It is often the case that a group or "tree" of documents has been |
75 |
constructed to serve a common purpose; the vast majority of URLs |
76 |
within these documents point to locations within the tree rather |
77 |
than outside of it. Similarly, documents located at a particular |
78 |
Internet site are much more likely to refer to other resources at |
79 |
that site than to resources at remote sites. |
80 |
|
81 |
Relative addressing of URLs allows document trees to be partially |
82 |
independent of their location and access scheme. For instance, |
83 |
if they refer to each other using relative URLs, it is possible for |
84 |
a single set of documents to be simultaneously accessible and, if |
85 |
hypertext, traversable via each of the "file", "http", and "ftp" |
86 |
schemes. Furthermore, document trees can be moved, as a whole, |
87 |
without changing any of the embedded URLs. Experience within the |
88 |
World-Wide Web has demonstrated that the ability to perform relative |
89 |
referencing is necessary for the long-term usability of embedded |
90 |
URLs. |
91 |
|
92 |
2. Relative URL Syntax |
93 |
|
94 |
The syntax for relative URLs is a shortened form of that for absolute |
95 |
URLs [2], where some prefix of the URL is missing and certain path |
96 |
components ("." and "..") have a special meaning when interpreting a |
97 |
relative path. Because a relative URL may appear in any context that |
98 |
could hold an absolute URL, systems that support relative URLs must |
99 |
be able to recognize them as part of the URL parsing process. |
100 |
|
101 |
Although this document does not seek to define the overall URL |
102 |
syntax, some discussion of it is necessary in order to describe the |
103 |
parsing of relative URLs. In particular, base documents can only |
104 |
make use of relative URLs when their base URL fits within the generic |
105 |
syntax described below. Although some URL schemes do not require |
106 |
this generic syntax, it is assumed that any document which contains |
107 |
a relative reference does have a base URL that obeys the syntax. |
108 |
In other words, relative URLs cannot be used within documents that |
109 |
have unsuitable base URLs. |
110 |
|
111 |
2.1. URL Syntactic Components |
112 |
|
113 |
The URL syntax is dependent upon the scheme. Some schemes use |
114 |
reserved characters like "?" and ";" to indicate special components, |
115 |
while others just consider them to be part of the path. However, |
116 |
there is enough uniformity in the use of URLs to allow a parser |
117 |
to resolve relative URLs based upon a single, generic syntax. |
118 |
This generic syntax consists of six components: |
119 |
|
120 |
<scheme>://<net_loc>/<path>;<params>?<query>#<fragment> |
121 |
|
122 |
each of which, except <scheme>, may be absent from a particular URL. |
123 |
These components are defined as follows (a complete BNF is provided |
124 |
in Section 2.2): |
125 |
|
126 |
scheme ":" ::= scheme name, as per Section 2.1 of [2]. |
127 |
|
128 |
"//" net_loc ::= network location and login information, as per |
129 |
Section 3.1 of [2]. |
130 |
|
131 |
"/" path ::= URL path, as per Section 3.1 of [2]. |
132 |
|
133 |
";" params ::= object parameters (e.g. ";type=a" as in |
134 |
Section 3.2.2 of [2]). |
135 |
|
136 |
"?" query ::= query information, as per Section 3.3 of [2]. |
137 |
|
138 |
"#" fragment ::= fragment identifier. |
139 |
|
140 |
Note that the fragment identifier (and the "#" that precedes it) is |
141 |
not considered part of the URL. However, since it is commonly used |
142 |
within the same string context as a URL, a parser must be able to |
143 |
recognize the fragment when it is present and set it aside as part |
144 |
of the parsing process. |
145 |
|
146 |
The order of the components is important. If both <params> and |
147 |
<query> are present, the <query> information must occur after the |
148 |
<params>. |
149 |
|
150 |
2.2. BNF for Relative URLs |
151 |
|
152 |
This is a BNF-like description of the Relative Uniform Resource |
153 |
Locator syntax, using the conventions of RFC 822 [5], except that |
154 |
"|" is used to designate alternatives. Briefly, literals are quoted |
155 |
with "", parentheses "(" and ")" are used to group elements, optional |
156 |
elements are enclosed in [brackets], and elements may be preceded |
157 |
with <n>* to designate n or more repetitions of the following |
158 |
element; n defaults to 0. |
159 |
|
160 |
URL = ( absoluteURL | relativeURL ) [ "#" fragment ] |
161 |
|
162 |
absoluteURL = scheme ":" *( uchar | reserved ) |
163 |
|
164 |
relativeURL = net_path | abs_path | rel_path |
165 |
|
166 |
net_path = "//" net_loc [ abs_path ] |
167 |
abs_path = "/" rel_path |
168 |
rel_path = [ path ] [ ";" params ] [ "?" query ] |
169 |
|
170 |
path = fsegment *( "/" segment ) |
171 |
fsegment = 1*pchar |
172 |
segment = *pchar |
173 |
|
174 |
params = param *( ";" param ) |
175 |
param = *( pchar | "/" ) |
176 |
|
177 |
scheme = 1*( alpha | digit | "+" | "-" | "." ) |
178 |
net_loc = *( pchar | ";" | "?" ) |
179 |
query = *( uchar | reserved ) |
180 |
fragment = *( uchar | reserved ) |
181 |
|
182 |
pchar = uchar | ":" | "@" | "&" | "=" |
183 |
uchar = unreserved | escape |
184 |
unreserved = alpha | digit | safe | extra | national |
185 |
|
186 |
escape = "%" hex hex |
187 |
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | |
188 |
"a" | "b" | "c" | "d" | "e" | "f" |
189 |
|
190 |
alpha = lowalpha | hialpha |
191 |
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | |
192 |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | |
193 |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" |
194 |
hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | |
195 |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | |
196 |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" |
197 |
|
198 |
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | |
199 |
"8" | "9" |
200 |
|
201 |
safe = "$" | "-" | "_" | "." | "+" |
202 |
extra = "!" | "*" | "'" | "(" | ")" | "," |
203 |
national = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`" |
204 |
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" |
205 |
punctuation = "<" | ">" | "#" | "%" | <"> |
206 |
|
207 |
|
208 |
2.3. Specific Schemes and their Syntactic Categories |
209 |
|
210 |
Each URL scheme has its own rules regarding the presence or absence |
211 |
of the syntactic components described in Section 2.1 and 2.2. |
212 |
In addition, some schemes are never appropriate for use with relative |
213 |
URLs. However, since relative URLs will only be used within contexts |
214 |
in which they are useful, these scheme-specific differences can be |
215 |
ignored by the resolution process. |
216 |
|
217 |
Within this section, we include as examples only those schemes that |
218 |
have a defined URL syntax in [2]. The following schemes are never |
219 |
used with relative URLs: |
220 |
|
221 |
mailto Electronic Mail |
222 |
telnet TELNET Protocol for Interactive Sessions |
223 |
|
224 |
Some URL schemes allow the use of reserved characters for purposes |
225 |
outside the generic grammar given above. However, such use is rare. |
226 |
Relative URLs can be used with these schemes whenever the applicable |
227 |
base URL follows the generic syntax. |
228 |
|
229 |
gopher Gopher and Gopher+ Protocols |
230 |
news USENET news |
231 |
nntp USENET news using NNTP access |
232 |
prospero Prospero Directory Service |
233 |
wais Wide Area Information Servers Protocol |
234 |
|
235 |
Finally, the following schemes can always be parsed using the generic |
236 |
syntax. |
237 |
|
238 |
file Host-specific Files |
239 |
ftp File Transfer Protocol |
240 |
http Hypertext Transfer Protocol |
241 |
|
242 |
It is recommended that new schemes be designed to be parsable via |
243 |
the generic syntax if they are intended to be used with relative |
244 |
URLs. A description of the allowed relative forms should be included |
245 |
when a new scheme is registered, as per Section 4 of [2]. |
246 |
|
247 |
2.4. Parsing a URL |
248 |
|
249 |
An accepted method for parsing URLs is necessary to disambiguate the |
250 |
generic URL syntax of Section 2.2 and to describe the algorithm for |
251 |
resolving relative URLs presented in Section 4. This section |
252 |
describes the parsing rules for breaking down a URL (relative or |
253 |
absolute) into the component parts described in Section 2.1. The |
254 |
rules assume that the URL has already been separated from any |
255 |
surrounding text and copied to a "parse string". The rules are |
256 |
listed in the order in which they would be applied by the parser. |
257 |
|
258 |
2.4.1. Parsing the Fragment Identifier |
259 |
|
260 |
If the parse string contains a crosshatch "#" character, then the |
261 |
substring after the first (left-most) crosshatch "#" and up to the |
262 |
end of the parse string is the <fragment> identifier. If the |
263 |
crosshatch is the last character, or no crosshatch is present, then |
264 |
the fragment identifier is empty. The matched substring, including |
265 |
the crosshatch character, is removed from the parse string before |
266 |
continuing. |
267 |
|
268 |
Note that the fragment identifier is not considered part of the URL. |
269 |
However, since it is often attached to the URL, parsers must be able |
270 |
to recognize and set aside fragment identifiers as part of the |
271 |
process. |
272 |
|
273 |
2.4.2. Parsing the Scheme |
274 |
|
275 |
If the parse string contains a colon ":" after the first character |
276 |
and before any characters not allowed as part of a scheme name |
277 |
(i.e. any not an alphanumeric, plus "+", period ".", or hyphen "-"), |
278 |
the <scheme> of the URL is the substring of characters up to but not |
279 |
including the first colon. These characters and the colon are then |
280 |
removed from the parse string before continuing. |
281 |
|
282 |
2.4.3. Parsing the Network Location/Login |
283 |
|
284 |
If the parse string begins with a double-slash "//", then the |
285 |
substring of characters after the double-slash and up to, but not |
286 |
including, the next slash "/" character is the network location/login |
287 |
(<net_loc>) of the URL. If no trailing slash "/" is present, the |
288 |
entire remaining parse string is assigned to <net_loc>. The |
289 |
double-slash and <net_loc> are removed from the parse string before |
290 |
continuing. |
291 |
|
292 |
2.4.4. Parsing the Query Information |
293 |
|
294 |
If the parse string contains a question mark "?" character, then the |
295 |
substring after the first (left-most) question mark "?" and up to the |
296 |
end of the parse string is the <query> information. If the question |
297 |
mark is the last character, or no question mark is present, then the |
298 |
query information is empty. The matched substring, including the |
299 |
question mark character, is removed from the parse string before |
300 |
continuing. |
301 |
|
302 |
2.4.5. Parsing the Parameters |
303 |
|
304 |
If the parse string contains a semicolon ";" character, then the |
305 |
substring after the first (left-most) semicolon ";" and up to the |
306 |
end of the parse string is the parameters (<params>). If the |
307 |
semicolon is the last character, or no semicolon is present, then |
308 |
<params> is empty. The matched substring, including the semicolon |
309 |
character, is removed from the parse string before continuing. |
310 |
|
311 |
2.4.6. Parsing the Path |
312 |
|
313 |
After the above steps, all that is left of the parse string is |
314 |
the URL <path> and the slash "/" that may precede it. Even though |
315 |
the initial slash is not part of the URL path, the parser must |
316 |
remember whether or not it was present so that later processes |
317 |
can differentiate between relative and absolute paths. Often this |
318 |
is done by simply storing the preceding slash along with the path. |
319 |
|
320 |
3. Establishing a Base URL |
321 |
|
322 |
In order for relative URLs to be usable within a base document, |
323 |
the absolute "base URL" of that document must be known to the |
324 |
parser. There are three methods for obtaining the base URL of |
325 |
a document, listed here in order of precedence. |
326 |
|
327 |
3.1. Base URL within Document Content |
328 |
|
329 |
Within certain document media types, the base URL of the document |
330 |
can be embedded within the content itself such that it can be |
331 |
readily obtained by a parser. This can be useful for descriptive |
332 |
documents, such as tables of content, which may be transmitted to |
333 |
others through protocols other than their usual retrieval context |
334 |
(e.g. E-Mail or USENET news). |
335 |
|
336 |
It is beyond the scope of this document to specify how, for each |
337 |
media type, the base URL can be embedded. However, an example of |
338 |
how this is done for the Hypertext Markup Language (HTML) [3] is |
339 |
provided in an Appendix (Section 10). |
340 |
|
341 |
3.2. Base URL within Message Headers |
342 |
|
343 |
For protocols that make use of message headers like those described |
344 |
in RFC 822 [5], a second method for identifying the base URL of a |
345 |
document is to include that URL in the message headers. It is |
346 |
recommended that the format of this header be: |
347 |
|
348 |
base = "Base" ":" "<URL:" absoluteURL ">" |
349 |
|
350 |
where "Base" is case-insensitive. For example, |
351 |
|
352 |
Base: <URL:http://www.ics.uci.edu/Test/a/b/c> |
353 |
|
354 |
would indicate that any relative URLs found within the document |
355 |
should be parsed relative to <URL:http://www.ics.uci.edu/Test/a/b/c>. |
356 |
Any whitespace (including that used for line folding) inside the |
357 |
angle brackets should be ignored. |
358 |
|
359 |
In situations where both an embedded base URL (as described in |
360 |
Section 3.1) and a "Base" message header are present, the embedded |
361 |
base URL takes precedence. |
362 |
|
363 |
3.3. Base URL from the Retrieval Context |
364 |
|
365 |
If neither an embedded base URL nor a "Base" message header |
366 |
is present, then, if a URL was used to retrieve the base document, |
367 |
that URL shall be considered the base URL. Note that if the |
368 |
retrieval was the result of a redirected request, the last URL used |
369 |
(i.e., that which resulted in the actual retrieval of the document) |
370 |
is the base URL. |
371 |
|
372 |
3.4. Default Base URL |
373 |
|
374 |
If none of the conditions described in Sections 3.1 -- 3.3 apply, |
375 |
then the base URL is considered to be the empty string and all |
376 |
embedded URLs within that document shall be interpreted as absolute. |
377 |
It is the responsibility of the distributor(s) of a document |
378 |
containing relative URLs to ensure that the base URL for that |
379 |
document can be established. It must be emphasized that relative |
380 |
URLs cannot be used reliably in situations where the object's base |
381 |
URL is not well-defined. |
382 |
|
383 |
3.5. Base URL for Composite Media Types |
384 |
|
385 |
Composite media types, such as the "multipart/*" and "message/*" |
386 |
media types defined by MIME (RFC 1521, [4]), require special |
387 |
processing in order to determine the base URL of a component part. |
388 |
For these types, the base URL of the composite entity should be |
389 |
determined first; this base is then considered the default for any |
390 |
component part that does not define its own base via one of the |
391 |
methods described in Sections 3.1 and 3.2. |
392 |
|
393 |
4. Resolving Relative URLs |
394 |
|
395 |
This section describes an example algorithm for resolving URLs |
396 |
within a context in which the URLs may be relative, such that the |
397 |
result is always a URL in absolute form. Although this algorithm |
398 |
cannot guarantee that the resulting URL will equal that intended |
399 |
by the original author, it does guarantee that any valid URL |
400 |
(relative or absolute) can be consistently transformed to an |
401 |
absolute form given a valid base URL. |
402 |
|
403 |
The following steps are performed in order: |
404 |
|
405 |
Step 1: The base URL is established according to the rules of |
406 |
Section 3. If the base URL is the empty string (unknown), |
407 |
the embedded URL is interpreted as an absolute URL and |
408 |
we are done. |
409 |
|
410 |
Step 2: Both the base and embedded URLs are parsed into their |
411 |
component parts as described in Section 2.4. |
412 |
|
413 |
a) If the embedded URL is entirely empty, it inherits the |
414 |
entire base URL (i.e. is set equal to the base URL) |
415 |
and we are done. |
416 |
|
417 |
b) If the embedded URL starts with a scheme name, it is |
418 |
interpreted as an absolute URL and we are done. |
419 |
|
420 |
c) Otherwise, the embedded URL inherits the scheme of |
421 |
the base URL. |
422 |
|
423 |
Step 3: If the embedded URL's <net_loc> is non-empty, we skip to |
424 |
Step 7. Otherwise, the embedded URL inherits the <net_loc> |
425 |
(if any) of the base URL. |
426 |
|
427 |
Step 4: If the embedded URL path is preceded by a slash "/", the |
428 |
path is not relative and we skip to Step 7. |
429 |
|
430 |
Step 5: If the embedded URL path is empty (and not preceded by a |
431 |
slash), then the embedded URL inherits the base URL path, |
432 |
and |
433 |
|
434 |
a) if the embedded URL's <params> is non-empty, we skip to |
435 |
step 7; otherwise, it inherits the <params> of the base |
436 |
URL (if any) and |
437 |
|
438 |
b) if the embedded URL's <query> is non-empty, we skip to |
439 |
step 7; otherwise, it inherits the <query> of the base |
440 |
URL (if any) and we skip to step 7. |
441 |
|
442 |
Step 6: The last segment of the base URL's path (anything |
443 |
following the rightmost slash "/", or the entire path if no |
444 |
slash is present) is removed and the embedded URL's path is |
445 |
appended in its place. The following operations are |
446 |
then applied, in order, to the new path: |
447 |
|
448 |
a) All occurrences of "./", where "." is a complete path |
449 |
segment, are removed. |
450 |
|
451 |
b) If the path ends with "." as a complete path segment, |
452 |
that "." is removed. |
453 |
|
454 |
c) All occurrences of "<segment>/../", where <segment> and |
455 |
".." are complete path segments, are removed. Removal of |
456 |
these path segments is performed iteratively, removing the |
457 |
leftmost matching pattern on each iteration, until no |
458 |
matching pattern remains. |
459 |
|
460 |
d) If the path ends with "<segment>/..", that "<segment>/.." |
461 |
is removed. |
462 |
|
463 |
Step 7: The resulting URL components, including any inherited from |
464 |
the base URL, are recombined to give the absolute form of |
465 |
the embedded URL. |
466 |
|
467 |
Parameters, regardless of their purpose, do not form a part of the |
468 |
URL path and thus have no effect on the resolving of relative paths. |
469 |
In particular, the presence or absence of the ";type=d" parameter |
470 |
on an ftp URL has no effect on the interpretation of paths relative |
471 |
to that URL. Fragment identifiers are only inherited from the base |
472 |
URL when the entire embedded URL is empty. |
473 |
|
474 |
5. Examples and Recommended Practice |
475 |
|
476 |
Within an object with a well-defined base URL of |
477 |
|
478 |
Base: <URL:http://a/b/c/d;p?q#f> |
479 |
|
480 |
the relative URLs would be resolved as follows: |
481 |
|
482 |
5.1. Normal Examples |
483 |
|
484 |
g:h = <URL:g:h> |
485 |
g = <URL:http://a/b/c/g> |
486 |
./g = <URL:http://a/b/c/g> |
487 |
g/ = <URL:http://a/b/c/g/> |
488 |
/g = <URL:http://a/g> |
489 |
//g = <URL:http://g> |
490 |
?y = <URL:http://a/b/c/d;p?y> |
491 |
g?y = <URL:http://a/b/c/g?y> |
492 |
g?y/./x = <URL:http://a/b/c/g?y/./x> |
493 |
#s = <URL:http://a/b/c/d;p?q#s> |
494 |
g#s = <URL:http://a/b/c/g#s> |
495 |
g#s/./x = <URL:http://a/b/c/g#s/./x> |
496 |
g?y#s = <URL:http://a/b/c/g?y#s> |
497 |
;x = <URL:http://a/b/c/d;x> |
498 |
g;x = <URL:http://a/b/c/g;x> |
499 |
g;x?y#s = <URL:http://a/b/c/g;x?y#s> |
500 |
. = <URL:http://a/b/c/> |
501 |
./ = <URL:http://a/b/c/> |
502 |
.. = <URL:http://a/b/> |
503 |
../ = <URL:http://a/b/> |
504 |
../g = <URL:http://a/b/g> |
505 |
../.. = <URL:http://a/> |
506 |
../../ = <URL:http://a/> |
507 |
../../g = <URL:http://a/g> |
508 |
|
509 |
5.2. Abnormal Examples |
510 |
|
511 |
Although the following abnormal examples are unlikely to occur |
512 |
in normal practice, all URL parsers should be capable of resolving |
513 |
them consistently. Each example uses the same base as above. |
514 |
|
515 |
An empty reference resolves to the complete base URL: |
516 |
|
517 |
<> = <URL:http://a/b/c/d;p?q#f> |
518 |
|
519 |
Parsers must be careful in handling the case where there are more |
520 |
relative path ".." segments than there are hierarchical levels in |
521 |
the base URL's path. Note that the ".." syntax cannot be used to |
522 |
change the <net_loc> of a URL. |
523 |
|
524 |
../../../g = <URL:http://a/../g> |
525 |
|
526 |
Similarly, parsers must avoid treating "." and ".." as special when |
527 |
they are not complete components of a relative path. |
528 |
|
529 |
/./g = <URL:http://a/./g> |
530 |
/../g = <URL:http://a/../g> |
531 |
g. = <URL:http://a/b/c/g.> |
532 |
.g = <URL:http://a/b/c/.g> |
533 |
g.. = <URL:http://a/b/c/g..> |
534 |
..g = <URL:http://a/b/c/..g> |
535 |
|
536 |
Less likely are cases where the relative URL uses unnecessary or |
537 |
nonsensical forms of the "." and ".." complete path segments. |
538 |
|
539 |
./../g = <URL:http://a/b/g> |
540 |
./g/. = <URL:http://a/b/c/g/> |
541 |
g/./h = <URL:http://a/b/c/g/h> |
542 |
g/../h = <URL:http://a/b/c/h> |
543 |
|
544 |
Finally, some older parsers allow the scheme name to be present in |
545 |
a relative URL if it is the same as the base URL scheme. This is |
546 |
considered to be a loophole in prior specifications of partial |
547 |
URLs [1] and should be avoided by future parsers. |
548 |
|
549 |
http:g = <URL:http:g> |
550 |
http: = <URL:http:> |
551 |
|
552 |
5.3. Recommended Practice |
553 |
|
554 |
Authors should be aware that path names which contain a colon |
555 |
":" character cannot be used as the first component of a relative |
556 |
URL path (e.g. "this:that") because they will likely be mistaken for |
557 |
a scheme name. It is therefore necessary to precede such cases with |
558 |
other components (e.g., "./this:that"), or to escape the colon |
559 |
character (e.g., "this%3Athat"), in order for them to be correctly |
560 |
parsed. The former solution is preferred because it has no effect |
561 |
on the absolute form of the URL. |
562 |
|
563 |
There is an ambiguity in the semantics for the ftp URL scheme |
564 |
regarding the use of a trailing slash ("/") character and/or a |
565 |
parameter ";type=d" to indicate a resource that is an ftp directory. |
566 |
If the result of retrieving that directory includes embedded |
567 |
relative URLs, it is necessary that the base URL path for that result |
568 |
include a trailing slash. For this reason, it is recommended that |
569 |
the ";type=d" parameter value not be used within contexts that allow |
570 |
relative URLs. |
571 |
|
572 |
6. Security Considerations |
573 |
|
574 |
There are no security considerations in the use or parsing of relative |
575 |
URLs. However, once a relative URL has been resolved to its absolute |
576 |
form, the same security considerations apply as those described in |
577 |
RFC 1738 [2]. |
578 |
|
579 |
7. Acknowledgements |
580 |
|
581 |
This work is derived from concepts introduced by Tim Berners-Lee and |
582 |
the World-Wide Web global information initiative. Relative URLs are |
583 |
described as "Partial URLs" in RFC 1630 [1]. That description was |
584 |
expanded for inclusion as an appendix for an early draft of RFC 1738, |
585 |
"Uniform Resource Locators (URL)" [2]. However, after further |
586 |
discussion, the URI-WG decided to specify Relative URLs separately |
587 |
from the primary URL draft. |
588 |
|
589 |
This document is intended to fulfill the requirements for Internet |
590 |
Resource Locators as stated in [6]. It has benefited greatly from |
591 |
the comments of all those participating in the URI-WG. Particular |
592 |
thanks go to Larry Masinter, Michael A. Dolan, Guido van Rossum, and |
593 |
Dave Kristol for identifying problems/deficiencies in earlier drafts. |
594 |
|
595 |
8. References |
596 |
|
597 |
[1] T. Berners-Lee, "Universal Resource Identifiers in WWW: |
598 |
A Unifying Syntax for the Expression of Names and Addresses of |
599 |
Objects on the Network as used in the World-Wide Web", RFC 1630, |
600 |
CERN, June 1994. <URL:ftp://ds.internic.net/rfc/rfc1630.txt> |
601 |
|
602 |
[2] T. Berners-Lee, L. Masinter, and M. McCahill, Editors, |
603 |
"Uniform Resource Locators (URL)", RFC 1738, CERN, |
604 |
Xerox Corporation, University of Minnesota, December 1994. |
605 |
<URL:ftp://ds.internic.net/rfc/rfc1738.txt> |
606 |
|
607 |
[3] T. Berners-Lee and D. Connolly, "HyperText Markup Language |
608 |
Specification -- 2.0", Work in Progress, MIT, HaL Computer |
609 |
Systems, November 1994. |
610 |
<URL:http://www.ics.uci.edu/pub/ietf/html/> |
611 |
|
612 |
[4] N. Borenstein and N. Freed, "MIME (Multipurpose Internet Mail |
613 |
Extensions): Mechanisms for Specifying and Describing the Format |
614 |
of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, |
615 |
September 1993. <URL:ftp://ds.internic.net/rfc/rfc1521.txt> |
616 |
|
617 |
[5] D. H. Crocker, "Standard for the Format of ARPA Internet |
618 |
Text Messages", STD 11, RFC 822, UDEL, August 1982. |
619 |
<URL:ftp://ds.internic.net/rfc/rfc822.txt> |
620 |
|
621 |
[6] J. Kunze, "Functional Requirements for Internet Resource |
622 |
Locators", Work in Progress, IS&T, UC Berkeley, November 1994. |
623 |
<URL:ftp://ds.internic.net/internet-drafts/ |
624 |
draft-ietf-uri-irl-fun-req-02.txt> |
625 |
|
626 |
9. Author's Address |
627 |
|
628 |
Roy T. Fielding |
629 |
Department of Information and Computer Science |
630 |
University of California |
631 |
Irvine, CA 92717-3425 |
632 |
U.S.A. |
633 |
|
634 |
Tel: +1 (714) 824-4049 |
635 |
Fax: +1 (714) 824-4056 |
636 |
Email: fielding@ics.uci.edu |
637 |
|
638 |
This Internet-Draft expires July 18, 1995. |
639 |
|
640 |
|
641 |
10. Appendix - Embedding the Base URL in HTML documents. |
642 |
|
643 |
It is useful to consider an example of how the base URL of a |
644 |
document can be embedded within the document's content. In this |
645 |
appendix, we describe how documents written in the Hypertext Markup |
646 |
Language (HTML) [3] can include an embedded base URL. This appendix |
647 |
does not form a part of the relative URL specification and should not |
648 |
be considered as anything more than a descriptive example. |
649 |
|
650 |
HTML defines a special element "BASE" which, when present in the |
651 |
"HEAD" portion of a document, signals that the parser should use |
652 |
the BASE element's "HREF" attribute as the base URL for resolving |
653 |
any relative URLs. The "HREF" attribute must be an absolute URL. |
654 |
Note that, in HTML, element and attribute names are case-insensitive. |
655 |
For example: |
656 |
|
657 |
<!doctype html public "-//IETF//DTD HTML//EN"> |
658 |
<HTML><HEAD> |
659 |
<TITLE>An example HTML document</TITLE> |
660 |
<BASE href="http://www.ics.uci.edu/Test/a/b/c"> |
661 |
</HEAD><BODY> |
662 |
... <A href="../x">a hypertext anchor</A> ... |
663 |
</BODY></HTML> |
664 |
|
665 |
A parser reading the example document should interpret the given |
666 |
relative URL "../x" as representing the absolute URL |
667 |
|
668 |
<URL:http://www.ics.uci.edu/Test/a/x> |
669 |
|
670 |
regardless of the context in which the example document was obtained. |
671 |
|