On 24/4/07 8:39, "Gergely Santa" <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I'm using LDIF for client-server communication.. The server is accessing
> LDAP server, and returns the results to the requesting client.. (You
> maybe ask 'WHY?', but it's only a minor part of the application)
> This reply message is in LDIF.. When client requests only DN for fetched
> attributes, an entry-set containing only DNs is returned to client,
> which tries to make Net::LDAP::Entry objects from them..
> The problem is, that current implemetation of Net::LDAP::LDIF throws an
> error, when entry contains only 1 attribute.. In normal cases this is
> not problem, because if we request only one specified attribute, it's
> returned with DN, so minimum of 2 attributes are returned.. In case, we
> request only DN, there is only one, and error is thrown by Net::LDAP::LDIF
The returned DN is not an attribute of the entry, it just describes the
entry's location in the DIT.
> I'm now using my own patched copy of this module in my client
> application, but I think, it should be Net::LDAP module too..
> Here is the patch, if you think it's worth of using
The LDIF RFC 2849 defines that ldif-attrval-records (ie not change records)
contain a dn-spec followed by at least one attrval-spec.
Although it seems potentially useful to be able to represent entries without
attributes in an LDIF file, I'd be worried about this breaking other apps
which consume LDIF files.
>
> EdE
> --- LDIF_old.pm Tue Apr 24 09:22:05 2007
> +++ LDIF.pm Tue Apr 24 09:06:57 2007
> @@ -186,7 +186,7 @@
> unless @ldif;
> }
>
> - if (@ldif <= 1) {
> + if (@ldif < 1) {
> $self->_error("LDIF entry is not valid", @ldif);
> return;
> }
> @@ -211,7 +211,7 @@
> if (CHECK_UTF8 && $self->{raw} && ('dn' !~ /$self->{raw}/));
> $entry->dn($dn);
>
> - if ($ldif[0] =~ /^changetype:\s*/) {
> + if ((scalar @ldif) && ($ldif[0] =~ /^changetype:\s*/)) {
> my $changetype = $ldif[0] =~ s/^changetype:\s*//
> ? shift(@ldif) : $self->{'changetype'};
> $entry->changetype($changetype);
The patch looks OK though.
Cheers,
Chris
