Any chance of ne_path_compare (ne_uri.c) of being modified to take account of URIs that contain percent-encoding ?
john.dite at compinia.de
Thu Jul 11 06:11:17 EDT 2013
I came across this interworking issue recently.
When trying access a WebDAV collection that contained a tilde sign eg. "/~davusr/webdav/" the response from the WebDAV server
contained a URI that used percent-encoding ie. "/%7edavusr/webdav/". The URI comparison fails in ne_path_compare and hence the
client fails "Did not find a collection resource".
RFC 3986 URI Generic Syntax January 2005
says the following:
2.3. Unreserved Characters
Characters that are allowed in a URI but do not have a reserved
purpose are called unreserved. These include uppercase and lowercase
letters, decimal digits, hyphen, period, underscore, and tilde.
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
URIs that differ in the replacement of an unreserved character with
its corresponding percent-encoded US-ASCII octet are equivalent: they
identify the same resource. However, URI comparison implementations
do not always perform normalization prior to comparison (see Section
6). For consistency, percent-encoded octets in the ranges of ALPHA
(%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E),
underscore (%5F), or tilde (%7E) should not be created by URI
producers and, when found in a URI, should be decoded to their
corresponding unreserved characters by URI normalizers.
So should ne_path_compare not call a URI normalizer before doing the comparison.
There seems to be an awareness as there is already a
/* TODO: implement properly */ comment before the function definition.
Wouldn't the ne_path_unescape function act as a URI normalizers ?
More information about the neon