Note that few (if anyone) really implements LDAPv2 as specified in
its IETF technical specification (RFC 1777, etc.). When version 2
is selected, you really get generally get something which I call
LDAPv2+ (LDAPv2 with U-Mich extensions) or LDAPv2++ (LDAPv2+ with
other extensions). This is why the IETF choose to move the
LDAPv2 TS to historic AND recommend that LDAPv3 be used instead
(of LDAPv2, LDAPv2+, LDAPv2++, ...).
Anyways, LDAP_PARTIAL_RESULTS comes from LDAPv2+, was described
in various U-Mich papers, and is supported (with limitations)
by a number of directory servers and APIs. The code indicates
that errorMessage field contains referral/reference information.
Even ignoring the overload of this field, the mechanism is
significantly flawed in design (cannot distinguish referral v.
continuation references) which makes it unusable in modern
directory systems. Another reason to use LDAPv3...
Given that all directory vendors support LDAPv3, I see no reason
why any new client-side support for LDAPv2[+[+]] (or features
thereof). Legacy apps can just use legacy libraries.
Kurt
At 09:46 PM 12/12/2003, Chris Ridd wrote:
>On 12/12/03 10:56 pm, D.Kreft <[EMAIL PROTECTED]> wrote:
>
>> Could someone provide for me an example of what $message->error() would
>> return if the result of a query were LDAP_PARTIAL_RESULTS? I'd like to know
>> precisely what to look for (i.e. regex) when searching for referral urls.
>>
>> The code that I'm inheriting (and rewriting) currently has this:
>>
>> my @urls;
>> if ( $message->code() == LDAP_PARTIAL_RESULTS ) {
>> foreach my $line ( split /\n/, $message->error() ) {
>> next unless ( $line =~ m,(ldap://[^:]+:\d+), );
>> push @urls, $1;
>> }
>> }
>>
>> But I won't be comfortable with this until I can actually see the actual
>> output of $message->error().
>
>That code's dubious for a couple of reasons.
>
>The error method returns the error text returned by the server if there was
>any, or one of the short descriptions from Net::LDAP::Constant if not.
>
>You *cannot* rely on the server returning anything in the error text field,
>and you should certainly not try to parse it.
>
>The second reason is that the partial results error code is non-standard,
>and not part of LDAPv2 or LDAPv3. (This surprised me slightly, but I just
>checked the RFCs.)
>
>In LDAPv3 you can call $message->referrals() if $message->code is
>LDAP_REFERRAL. That only happens if the *entire* operation cannot be carried
>out on the server you sent it to.
>
>The only other case in core LDAPv3 of "referrals" being returned is in the
>search operation when some results could be generated locally by the server,
>and in addition references returned to other servers. Technically these are
>called "continuation references" and not referrals. They could be returned
>in any search result pretty much regardless of the result code. Well,
>probably just OK, TIMELIMIT_EXCEEDED or SIZELIMIT_EXCEEDED. Potentially they
>could be returned from extended operations as well.
>
>To get back continuation references in LDAPv3 just call
>$message->references().
>
>> I see a couple of examples with ldapsearch(1) at
>> http://www.ldap.verisignlabs.com/ldapsearch.html, but I don't know how
>> similar the results are between it and the Perl API.
>>
>> Thanks!
>>
>> -dan
>>
>
>Cheers,
>
>Chris
