Howard Chu writes:

...

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.

I think we can just replace strchr(,'/') with strpbrk(,"/?") or strcspn and take it from there. And require '?' in ldapi filenames to be URL-escaped, if they are not already.

Thank you, much easier to see now the rest of the mess is cleaned up:-)

...

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" -> ldapi://a/cn=d??base

I've left this alone for now.

We can make ldap_pvt_hex_unescape() return success/failure instead of void (and the output URL would be undefined). At the same time also reject bad %escapes - see that function's comment * FIXME: what if '%' is followed * by non-hexpair chars?

...

================

The RFCs 4516/2255 hostport part has grammar [host [":" port]], but ldap_url_desc2str() produces [host][":" port].

ldap:// -> host NULL, port 389 -> ldap://:389/??base

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.

Would it help to produce ldap://0:389/? Helps the syntax, but I don't know if host 0 or 0.0.0.0 for INADDR_ANY is OK or just another unportable hack.

Looks like RFC4516 should not have been approved in its current state.

I'd say RFCs2255 should not have been, but RFC4516 should since it was too late; it didn't introduce any new bugs.