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
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. p. SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
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
> > Actually, that's not true... <mailto:user@example.com> > is a valid URL, as is <news:comp.databases>. ... or "about:"; I was speaking about the "file:" only; as far as I could go with standard track docs the only valid form should start with "file://", but I might be missing something. Note that as RFC1738 is being obsoleted, the current <draft-hoffman-file-uri> (although IMHO adding a bit of confusion about what should be tolerated because someone implements it and so) doesn't appear to consider relative paths. > 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. ... in clients that parse ldif, as a replacement for providing the value directly in the ldif file? or in general? (I note that libcurl, for instance, provides, among the others, ldap fetching capabilities, with the potential to create circular dependencies...). p. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
At 03:28 AM 4/7/2005, ando@sys-net.it wrote: >... in clients that parse ldif, as a replacement for providing the value >directly in the ldif file? or in general? (I note that libcurl, for >instance, provides, among the others, ldap fetching capabilities, with the >potential to create circular dependencies...). The former... as an alternative to fetch(3) (as used currently). Kurt
changed notes moved from Incoming to Software Enhancements
changed notes
changed state Open to Feedback
Some notes... Most of the forms in the original request have been supported in 2.3/2.4/HEAD for a long time, I just didn't remember this ITS existed. It has some bearing on #5117 as well. Specifically file:/absolute/path file:relative/path file:simple.name are allowed (but deprecated) by RFC 3986 and are supported. (RFC1808 and 3986 expect relative URLs to have no scheme specifier at all. We don't handle that case. We also don't handle file://localhost/absolute/path and probably should.) file://simple.name violates RFC3986 and is rejected. The latest draft spec for FILE URIs has died, and it looks like it was plagued with too many strange behaviors to formulate a coherent spec. http://tools.ietf.org/html/draft-hoffman-file-uri-03 http://offset.skew.org/wiki/URI/File_scheme/Plan_of_action In the meantime, the libcurl API is a lot more complicated than libfetch. Might be nice to have, but it will not be as straightforward... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Feedback to Closed
support libcurl? patch welcome closing. support for libcurl can be requested in a new ITS.