/
roytest2.html
100 lines (75 loc) · 3.56 KB
/
roytest2.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
<HTML><HEAD>
<TITLE>Examples of Resolving Relative URLs, Part 2</TITLE>
<BASE href="http://a/b/c/d;p?q=1/2">
</HEAD><BODY>
<H1>Examples of Resolving Relative URLs, Part 2</H1>
This document has an embedded base URL of
<PRE>
Content-Base: http://a/b/c/d;p?q=1/2
</PRE>
the relative URLs should be resolved as shown below. In this test page,
I am particularly interested in testing whether "/" in query information
is or is not treated as part of the path hierarchy.
<P>
I will need your help testing the examples on multiple browsers.
What you need to do is point to the example anchor and compare it to the
resolved URL in your browser (most browsers have a feature by which you
can see the resolved URL at the bottom of the window/screen when the anchor
is active).
<H2>Tested Clients and Client Libraries</H2>
<DL COMPACT>
<DT>[R]
<DD>RFC 2396 (the right way to parse)
<DT>[X]
<DD>RFC 1808
<DT>[1]
<DD>Mozilla/4.03 [en] (X11; U; SunOS 5.5 sun4u; Nav)
<DT>[2]
<DD>Lynx/2.7.1 libwww-FM/2.14
<DT>[3]
<DD>MSIE 3.01; Windows 95
<DT>[4]
<DD>NCSA_Mosaic/2.6 (X11;SunOS 4.1.2 sun4m) libwww/2.12
</DL>
<H3>Synopsis</H3>
RFC 1808 specified that the "/" character within query information
does not affect the hierarchy within URL parsing. It would appear that
it does in current practice, but only within the relative path after
it is attached to the base path. In other words, the base URL's query
information is being stripped off before any relative resolution, but
some parsers fail to separate the query information from the relative
path.<P>
We have decided that this behavior is due to an oversight in the original
libwww implementation, and it is better to correct the oversight in future
parsers than it is to make a nonsensical standard. A note has been added
to the URI draft to account for the differences in implementations. This should
have no impact on current practice since unescaped "/" is rarely (if ever)
used within the query part of a URL, and query parts themselves are rarely
used with relative URLs.
<H2>Examples</H2>
<PRE>
RESULTS from
<a href="g">g</a> = http://a/b/c/g [R,X,1,2,3,4]
<a href="./g">./g</a> = http://a/b/c/g [R,X,1,2,3,4]
<a href="g/">g/</a> = http://a/b/c/g/ [R,X,1,2,3,4]
<a href="/g">/g</a> = http://a/g [R,X,1,2,3,4]
<a href="//g">//g</a> = http://g [R,X,1,2,3,4]
<a href="?y">?y</a> = http://a/b/c/?y [R,1,2,3,4]
http://a/b/c/d;p?y [X]
<a href="g?y">g?y</a> = http://a/b/c/g?y [R,X,1,2,3,4]
<a href="g?y/./x">g?y/./x</a> = http://a/b/c/g?y/./x [R,X]
http://a/b/c/g?y/x [1,2,3,4]
<a href="g?y/../x">g?y/../x</a> = http://a/b/c/g?y/../x [R,X]
http://a/b/c/x [1,2,3,4]
<a href="g#s">g#s</a> = http://a/b/c/g#s [R,X,1,2,3,4]
<a href="g#s/./x">g#s/./x</a> = http://a/b/c/g#s/./x [R,X,2,3,4]
http://a/b/c/g#s/x [1]
<a href="g#s/../x">g#s/../x</a> = http://a/b/c/g#s/../x [R,X,2,3,4]
http://a/b/c/x [1]
<a href="./">./</a> = http://a/b/c/ [R,X,1,2,3,4]
<a href="../">../</a> = http://a/b/ [R,X,1,2,3,4]
<a href="../g">../g</a> = http://a/b/g [R,X,1,2,3,4]
<a href="../../">../../</a> = http://a/ [R,X,1,2,3,4]
<a href="../../g">../../g</a> = http://a/g [R,X,1,2,3,4]
</PRE>
</BODY></HTML>