summaryrefslogtreecommitdiff
path: root/t/roytest2.html
diff options
context:
space:
mode:
Diffstat (limited to 't/roytest2.html')
-rw-r--r--t/roytest2.html100
1 files changed, 100 insertions, 0 deletions
diff --git a/t/roytest2.html b/t/roytest2.html
new file mode 100644
index 0000000..3906f4e
--- /dev/null
+++ b/t/roytest2.html
@@ -0,0 +1,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>