[Date Prev][Date Next]
Re: ldapadd rejects zero-length attribute value in ldif (ITS#3363)
You're likely mislead by the example you gave. The attribute "seeAlso"
can have zero-length value because its syntax (distinguishedName) allows
it. The attribute "description" can't because its syntax
LDIF can represent zero-length values, of course, because LDIF doesn't
know about syntax. The LDAP protocol itself can carry around zero-length
values as well, because at the transport level it doesn't know anything
about syntax. However the DSA, which knows about syntax, can (and must)
reject illegal values, despite they were correctly transported, and
represented in LDIF format.
> Ok, I made a test with the ldapadd from a 2.2.17 but with an openldap
> 2.2.11 as
> a directory. The same behavior.
> This is what looks strange :
> the ldif rfc says you can have a zero-length value in an ldif file
> the ldap rfc says you can have a zero-length value in a search response
> the ldap rfc says you can't have a zero-length value in a directory
> So if you say that the ldapadd tool must send zero-length values to the
> directory, there is a strange situation :
> you export a search which return a zero-length value to a ldif file
> => ok
> you import this ldif in the directory
> => problem
> You must pre-process the ldif to remove zero-length values if you want to
> import it.
> Do you think this is normal ?
> Well, of course if you say "yes", there is no problem at all :-)))
> Victor CHEVALIER
> Selon "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>:
>>>> At 12:35 AM 10/11/2004, email@example.com wrote:
>>>> >Full_Name: Victor CHEVALIER
>>>> >Version: 2.2.11
>>>> You should consider upgrading to (at least) the latest
>>>> stable release. Reports with prior versions will not
>>>> generally be investigated.
>>>> >So, I think that ldapadd should only ignore these zero-length values,
>>>> shouldn't it ?
>>>> No. ldapadd should pass a zero-length value to the server
>>>> (as it apparently did here). The server will verify the value
>>>> conforms to the required syntax and, if it doesn't, return an
>>>> appropriate error such as invalidSyntax (as it apparently
>>>> did here). That is, the behavior you describe appears to
>>>> be correct and intended.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497