On 09/21/2012 03:04 AM, Amos Jeffries wrote:
> BH the code for "broken helper" internal errors, independent of the
> certificate validity.
Agreed.
> Both OK and ERR mean the helper has successfully done what it was asked
> to do. OK being the positive result, ERR the negative result. These
> semantics are laid out by the existing authentication and ACL interfaces
> which are where OK/ERR come from.
>
> I am pushing for the BH result code from NTLM/Kerberos to be added so we
> can distinguish between the three true/false/error states. The use of
> letters "ERR" is unfortunate, but what we are stuck with for now at least.
OK. I am not ecstatic about this design, but I agree that we should keep
it consistent across helpers, and it is not worth perfecting now,
despite its deficiencies. Perhaps we can document it better (and be more
explicit about its problems) so that more developers use the right code
from the beginning.
The new certificate validation helper will use ERR response code if it
returns any certificate validation errors.
What should a helper return when it thinks the request itself is invalid
(e.g., missing a required field)? It is not an internal helper error
(from helper point of view anyway) so BH does not apply. Both OK and ERR
indicate success so they are not applicable either.
Thank you,
Alex.
Received on Fri Sep 21 2012 - 14:42:37 MDT
This archive was generated by hypermail 2.2.0 : Sat Sep 22 2012 - 12:00:07 MDT