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