Add the original source packages to maemo, source lenny
[dh-make-perl] / dev / i386 / liburi-perl / liburi-perl-1.35.dfsg.1 / t / roytest2.html
diff --git a/dev/i386/liburi-perl/liburi-perl-1.35.dfsg.1/t/roytest2.html b/dev/i386/liburi-perl/liburi-perl-1.35.dfsg.1/t/roytest2.html
new file mode 100644 (file)
index 0000000..3906f4e
--- /dev/null
@@ -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>