On 22/09/2012 2:42 a.m., Alex Rousskov wrote:
> 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.
If we assume that Squid is always right (it does hard-code the lookup
details) the helper not being able to cope with the request made is a
BH. All of these status codes can respond with message="" key-pair to
explain more.
Amos
Received on Sat Sep 22 2012 - 00:37:10 MDT
This archive was generated by hypermail 2.2.0 : Sat Sep 22 2012 - 12:00:07 MDT