Any chance of ne_path_compare (ne_uri.c) of being modified to take account of URIs that contain percent-encoding ?

john dite john.dite at
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 mailing list