diff options
author | Lorry Tar Creator <lorry-tar-importer@lorry> | 2015-07-25 01:06:42 +0000 |
---|---|---|
committer | Lorry Tar Creator <lorry-tar-importer@lorry> | 2015-07-25 01:06:42 +0000 |
commit | 9165b237ad8fae18b36d4d40d6e2ccfde7b136c7 (patch) | |
tree | 06530ddd6baa7e251c58b6b6729ed458da61a681 /t/roytest2.html | |
download | URI-tarball-9165b237ad8fae18b36d4d40d6e2ccfde7b136c7.tar.gz |
Diffstat (limited to 't/roytest2.html')
-rw-r--r-- | t/roytest2.html | 100 |
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> |