[Date Prev][Date Next]
Re: (ITS#8618) ldapsearch - unexpected behavior with
I was referring to best practice/RFC regarding what is a valid hostname.
My example was intentionally provocative. I think rejecting hostname containing
the '://' construct is actually a good idea. Those would be problematic for
parsing and such broken hostname are unlikely to ever be use.
Been reading a bit more (1) and I think internationalized domain are also not an
issue as they have a ASCII representation. So the only real concern I can think
of at this point is underscore. But I could be missing something...
I am still not convinced about having addition verification beside:
- What the DNS standard says (RFC2181)
- Prohibiting hostname that would cause cause an issue with parsing ('://')
Why do the 'host' and 'dig' command does not seem to place any restriction when
querying for A records ? (would be interested to see how other software handle
Andew: Did you manage to find out why the behavior with '-h' option and both '
--h' and '-p' option was different ?
PS: Andrew: In my client (evolution) your previous plain text email did show up
as base64 encoded. (had to use 'base64 -d' to read them). I did not remember
outlook making it so hard to send plain text email (!)
On Sat, 2018-03-03 at 10:29 +0000, firstname.lastname@example.org wrote:
> Alexandre Rosenberg wrote:
> > Micheal, you are *right* about the man page saying _hostname_. Indeed
> > OpenLDAP
> > only accepting hostname as per best practice/RFC might be the most correct
> > behavior.
> There is no relevant RFC or best practice, only the man-page. And the -h
> and -p arguments come from the old UMich LDAP times.
> > However we can not change this behavior without breakable. consider:
> AFAICS backward compability has only be provided to those ancient Umich
> or Netscape Directory tools. So IMO LDAP URI does not have to be accepted.
> > - Underscore are not that uncommon with Active Directory
> > - What about
> > - ... (probably more)
> If you want to fix something for 2.4.x to match what the man-page says
> you could effectively reject LDAP URI by simply rejecting colons and
> slashes. Those chars are never in even seriously broken hostnames. If
> they were they would cause more interop issues anyway.
> > Therefore I believe such change could only be done in a major release. And
> > at
> > that point we might just remove the depreciated '-h' option altogether.
> Agreed. 2.5 release chould IMO simply remove options -h and -p.
> Ciao, Michael.