Menu
▾
▴
#197 uri::resolve not conform to rfc2396
In the documentation of the uri package I miss a note
about according to which specification the uri:resolve
command works.
The documentation claims, that this package provide
"URI utilities". From this, I suspect, this package,
especially the 'uri::resolve' command works according
to rfc 2396 "Uniform Resource Identifiers (URI):
Generic Syntax" http://www.ietf.org/rfc/rfc2396.txt
If the uri procs do not work according to rfc2396, then
I would say, the name of the package is misleading and
should eventually changed (for example to "url", to let
the name "uri" for a package, that works according to
rfc2396). But even then it would be desirable, to know,
which specification(s) are implemented - without knowing
If the uri package claims to work according to rfc2396,
then the resolve proc has a major problem with
resolving relative paths.
Example:
uri::resolve http://a/b/c ..
gives
but should return "http://a/"
The detailed rules for resolving relative URIs are
described in section 5 of rfc2396.
The current results of uri::resolve are only
acceptable, if someone uses the result URIs as URLs.
But URIs are for "*identifying* an abstract or physical
resource" (rfc2396, emphases added by me). If someone
tries to use the URI "http://a/b/.." to map that to a
resource of his local resource pool, he will normaly
fail, because the string "http://a/b/.." ist different
from "http://a/", for which his entitiy mapper may know
the according local resource.
In short, if an URI is used as an abstract identifier,
it's often "byte-compared" with some catalog entries,
to find the actual resource. Therefor it's important,
that relative URIs like "..", "../b" "../.." etc ppp.
are actually resolved and not only appended to the
'dirname part' of the base URI.
I'll add a file with some tests, written along the
examples out of rfc2396 Appendix C. "Examples of
Resolving Relative URI References"
A second (really small) problem is, that rfc2396 has
changed the general syntax of an URI "to require that
all schemes begin with an alpha character"
See rfc2396, 3.1
scheme = alpha *( alpha | digit | "+" | "-" | "." )
The consequence would be, to change
regexp -- {^([a-z0-9+-.][a-z0-9+-.]*):} $url dummy scheme
in proc uri::split accordingly (to something like
regexp -- {^([a-zA-Z][a-zA-Z0-9+-.]*):} $url dummy scheme
)
rolf
Logged In: YES
user_id=13222
Withdraw the older test file, use this one instead.
Logged In: YES
user_id=75003
Deleted older test file now.
Logged In: YES
user_id=75003
The new test cases are now part of the module, as a
reminder of non-conformance. Renamed them to prevent
conflicts with the existing tests.
Added a note to the documentation that the package is
currently not conforming to RFC 2396.