[Date Prev][Date Next]
Re: (ITS#4879) URL parse/unparse troubles
> Full_Name: Hallvard B Furuseth
> Version: HEAD
> OS: Linux
> Submission from: (NULL) (188.8.131.52)
> Submitted by: hallvard
> Here are some URLs parsing/building bugs in libldap/url.c.
> Some may be design bugs. Possibly some fixes will need backwards
> I show URLs converted from string to LDAPURLDesc format with
> ldap_url_parse(), back to string format with ldap_url_desc2str()
> when the result differs from the original, back to LDAPURLDesc...
> The url.c Novell kludge does not work (for the example URL).
> If the bug is old and nobody has complained, maybe it should be
> removed. If it's fixed instead, note that the code looks like
> it'll handle Novell URLs with '/' in components after hostport:
> ldap_url_parse_ext() does strchr( url, '/' ) very early to find
> the end of the hostport.
Hm, I think I see what you mean, but I don't see what to do about that.
> ldap://111.222.333.444:389??cn=abc,o=company ->
> error 5 (LDAP_URL_ERR_BADURL)
This now works.
> Example URL without port number:
> ldap://111.222.333.444??cn=abc,o=company ->
> host "111.222.333.444??cn=abc,o=company", DN NULL ->
This now works.
> ldap_url_desc2str() outputs IPv6 host addresses as "addr" rather
> than "[addr]". (LDAPURLDesc does not contain the ''s in
> .lud_host, nor any flag which says it's an IPv6 host address).
> I don't know the syntax of such addresses, but I seem to remember
> they contains ':'s. If so the parser could fail if an IPv6
> address does not contains ':', and the URL builder could test for
> ':' to determine if there should be  around the host part.
This now works.
> Also, what does stuff between the ']' and ':port' mean?
> Should anything be allowed there?
> ldap://[::1]what's this:222/ -> host "::1", port 222 ->
This is now correctly rejected.
> ldap://::1:222/??base -> error 5 (LDAP_URL_ERR_BADURL)
> Converting "%00" to char* should return an error, since the char*
> will not match the source URL:
> ldapi://a%00b/cn=d%00e -> host "a", DN "cn=d" ->
I've left this alone for now.
> The RFCs 4516/2255 hostport part has grammar [host [":" port]],
> but ldap_url_desc2str() produces [host][":" port].
> ldap:// -> host NULL, port 389 ->
> That's OK as an ldap_url_parse() OpenLDAP extension, but not as
> ldap_url_desc2str() output given to non-OpenLDAP applications.
This is a mess. The ldap: scheme definition has always been broken, and
it certainly does not conform to the basic URI syntax in RFC3986 section
3. In particular, RFC3986 forbids a URI from containing "//" when the
authority component is absent. Looks like RFC4516 should not have been
approved in its current state.
> While I'm writing, I wonder if OpenLDAP 2.4 could omit defaults
> and final "?"s from the ldap_url_desc2str() output. E.g. ldap://
> would become ldap:// and not ldap://:389/??base. But maybe we get
> into trouble if ldap.conf has another port or something.
I thought about changing this, but left it alone for now. Agreed, the
interaction with ldap.conf isn't clear.
> ldapi URL (un)parsing has several problems:
> ldap_url_parse() always treats ':' as a host:port separator.
> Thus one can produce an ldapi LDAPURLDesc with a meaningless port.
> However ldap_url_desc2str() does not URL-escape ':', and it also
> takes port!=0 to mean it is not an ldapi URL and needs no
> '/'-escaping. Similarly filenames with initial '[' do not work.
> ldapi://%2Ftmp%2Ffoo%3A222/ -> host "/tmp/foo:222" (correct) ->
> ldapi://%2Ftmp%2Ffoo:222/??base -> host "/tmp/foo", port 222 ->
> ldapi:///tmp/foo:222/??base -> host NULL, DN "tmp/foo:222/"
> ldapi://%2Ftmp%2Ffoo:000/ -> host "/tmp/foo" ->
> ldapi://%2Ftmp%2Ffoo:bar/ -> error 5 (LDAP_URL_ERR_BADURL)
These are all fixed. Note that the "ldapi:///tmp/foo:222/" case simply
means an ldapi:// URL with a DN of "tmp/foo:222/" which is legal in a
URL parsing sense, even though DN validation would reject it.
> The current implementation would handle some non-Unix ldapi
> filenames wrong. (They'll need well-defined URL-escaping rules
> if they get implemented, so it might as well be fixed now.) Of
> course these can also be strange Unix relative filenames...
> Windows-like filenames:
> ldapi://C%3A%2Fldapi/ -> host "C:/ldapi" ->
> ldapi://C:%2Fldapi/??base -> error 5 (LDAP_URL_ERR_BADURL)
> Tops-20-like filenames resemble IPv6 addresses (not that I expect
> to port OpenLDAP to Tops-20:-)
> ldapi://[ldap.var.run]ldapi/ -> host "ldap.var.run" ->
> URL-escaping the '[' and ']' does not help; the '[' is lost:
> ldapi://%5Bldap.var.run%5Dldapi/ -> host "ldap.var.run]ldapi" ->
These are all fixed.
-- 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/