Re: LDAP C API: ber_* error handling

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Mark Smith writes:
>"Kurt D. Zeilenga" wrote:
>> ...
>> I would not object if we ducked this issue for now (leaving it a later API
>> extension).  That is, I'd be happy with a simple clarification.

>>         ber_* routines only indicate an error has occurred.  This
>>         specification does not define a mechanism to obtain detail
>>         information about the error.  Implementations of this API
>>         SHOULD provide such a mechanism.
> 
> Okay with me, but I think we should agree on the error reporting
> mechanism very soon as this is a big deal in some environments.
> 
> Other opinions?  Should we address this issue now?

Well - one note: error conditions from ber_* functions is another point
where the draft's functions can't be used to write a conforming server.
rfc2251 section 4.1.1 "Message Envelope" says:

   If the server receives a PDU from the client in which the LDAPMessage
   SEQUENCE tag cannot be recognized, the messageID cannot be parsed,
   the tag of the protocolOp is not recognized as a request, or the
   encoding structures or lengths of data fields are found to be
   incorrect,

In several of these cases, the ber_* function returns LBER_ERROR.

   then the server MUST return the notice of disconnection
   described in section 4.4.1, with resultCode protocolError, and
   immediately close the connection.

However, conditions like malloc error (too large object) also return
LBER_ERROR but reqire the server to take another action, so it does have
to look look _somewhere_ to find out which error actually happened:

   In other cases that the server
   cannot parse the request received by the client, the server MUST
   return an appropriate response to the request, with the resultCode
   set to protocolError.

I'm not sure if this is an argument for or against doing it now, but I
_am_ sure that most programs that only use the ber_* functionality in
the draft will be incorrect.


I think my vote is to get this draft out the door soon, with or without
some of the discussed changes, and then prepare to abandon further work
on this API and instead design a new API which avoids the cumbersome
things in this one - like the error handling.

-- 
Hallvard