resultCode vs API error code (Was: Testing successful bind)

[Kurt D. Z. <Ku...@Op...>]

At 11:35 PM 6/8/00 -0700, Paul Heinlein wrote:
>On Thu, 8 Jun 2000, Yann Ramin wrote:
>
>> I've noticed that no error code is returned when a bind operation uses
>> invalid credentials.  ?  How can I test if a bind was successful or
>> not?  This is my main LDAP authentication scheme :)

Return of a success resultCode.

One of the major problems with the C API is that it confuses
server resultCodes with API error codes.  This was a MAJOR
mistake.  A server may return any non-negative value as a
resultCode and clients must treat any unknown value as
an unknown value.  So, say the API returns a non-reserved
code of 0x77.  Is this a resultCode or an API error code?
it could be either.

Note that RFC 2251 reserves a limited set of resultCodes
for API use.  However, API need more than this limited set.
And servers have been known to return resultCodes for
APIs.  This is problematic and will always be so.  The
only way to avoid the problem is to have a clear and
distinct separation of API error codes and protocol result
codes.

For the upcoming C API specification, the authors and I
are discussing two approaches to resolve this issue.
	1) have API routines return an API error code
		and provide separately protocol results
		(including resultCode)
	2) using negative values codes to indicate
		API error codes (because resultCodes must be
		non-negative).

If I was designing a new API, I'd choose option 1.  With
the C API, some (not I) prefer option 2 because it is
less intrusive to older programs.  And some are
willing to assume that clients and servers will be
well behaved (despite operational experience to the
contrary).

It appears that net:::LDAP makes the same mistake.

>  # Hmm. Probably the password is bad. We'll try an
>  # anonymous bind just to make sure the server's running

The server may disallow anonymous binds.  However, it
should return an bind response whether successful or not
and this can be used to test server availability.