[Date Prev][Date Next]
Re: (ITS#3636) more flexible file: URLs in LDIFs
At 01:45 AM 4/7/2005, email@example.com wrote:
>>Full_Name: Peter Marschall
>>Version: 2.2, 2.3, HEAD
>>Submission from: (NULL) (18.104.22.168)
>>without the libfetch library OpenLDAP's ability to interpret file: URLs is
>>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:firstname.lastname@example.org>
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.