Re: (ITS#4879) URL parse/unparse troubles

[h.b.furuseth@usit.uio.no]

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.

-- 
Regards,
Hallvard