Re: (ITS#3636) more flexible file: URLs in LDIFs

[Kurt@OpenLDAP.org]

At 01:45 AM 4/7/2005, ando@sys-net.it wrote:
>peter@adpm.de wrote:
>
>>Full_Name: Peter Marschall
>>Version: 2.2, 2.3, HEAD
>>OS: Linux
>>URL: ftp://ftp.openldap.org/incoming/peter-marschall-050406.patch
>>Submission from: (NULL) (84.56.99.111)
>>
>>
>>Hi,
>>
>>without the libfetch library OpenLDAP's ability to interpret file: URLs is
>>quite
>>limited. E.g. it does only allow file: URLs with absolute paths.
>>
>>True to the old sendmail motto "be liberal what you accept, be strict in what
>>you send", the attached patch adds a bit more flexibility to the parsing of
>>file: URLs in LDIFs.
>>
>>It allows the following 4 forms of URLs:
>>- file:/absolute/path/to.ldif      (absolute path without a host)
>>- file:relative/path/to.ldif       (relative path without a host)
>>- file:to.ldif                     (without host and path)
>>- file://to.ldif                   (without host and path)
>>While none of these may comply 100% to the standard, they are accepted in other
>>programs (e.g. KDE, perl-ldap, ...).
>>
>>The patch was made against 2.2.24, but should also apply cleanly to HEAD since
>>the interesting parts in the source in HEAD look identical to those in 2.2.24
>>  
>>
>Personally, I find this of limited usefulness and potentially prone to 
>errors (typically, people tend to forget the third "/" that indicates 
>that the path is absolute; in this case I prefer to get an error rather 
>than a path being used as relative); moreover, in many cases it may not 
>be intuitive what the path is intended to be relative to.  In any case, 
>I wouldn't use anything that is lacking the first two "//", because what 
>makes the prefix an URL is the "<proto>://" structure.

Actually, that's not true...  <mailto:user@example.com>
is a valid URL, as is <news:comp.databases>.  But, beyond
that, I generally concur.  Personally, I rather not add more URL
smarts to OpenLDAP Software.   However, I would not object to
adding support for additional URL libraries (libcurl?)  And if,
by doing so, that added support for goofy file:// URLs, so be it.

Kurt