apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <minf...@sharp.fm>
Subject Re: additional error code
Date Wed, 21 Jun 2006 11:05:51 GMT
On Wed, June 21, 2006 12:21 pm, Joe Orton wrote:

> The key to solving this properly is to abstract away the underlying
> error codes returned by the toolkit being wrapped - the LDAP code
> doesn't do that, it just dumps the LDAP_* errors in a structure (and
> hence PR 39529).

LDAP error codes are abstracted in apr_ldap_init.h, the real fix for PR
39529 should be made here, not in mod_authnz_ldap.

> If the aim is to actually abstract away the SSL toolkit then you need to
> work out exactly what error codes need to be returned and where (i.e.
> have a well-defined API), then define new errors in apr-util in the
> _USERERR space and map these from the toolkit used.  (it's a pity there
> wasn't an error code space reserved for apr-util in apr_errno.h; that
> would be useful to fix in APR 2.0)

The raw error codes must always be available, otherwise detail of the
error gets hidden from the end user. This is why the raw LDAP codes are
made available in the structure.

I've spent ages in the past trying to unravel "certificate has expired"
errors that were really expired CA certs buried somewhere, because the app
involved didn't log the real SSL error message.


View raw message