On 21/09/2012 6:00 a.m., Alex Rousskov wrote:
> On 09/20/2012 05:32 AM, Amos Jeffries wrote:
>> On 20/09/2012 10:54 p.m., Tsantilas Christos wrote:
>>> Hi Amos,
>>> I show you had already fix most of my mistakes in wiki page. Thank you.
>>>
>>> On 09/20/2012 09:40 AM, Amos Jeffries wrote:
>>>> On 20/09/2012 9:40 a.m., wiki_at_wiki.squid-cache.org wrote:
>>>>
>>>>> +
>>>>> + result::
>>>>> + The result code '''OK''' indicates that the certificate validation
>>>>> is successful. The result code '''ERROR''' indicates that an error
>>>>> occurred.
>>>> "ERR" is the standard result code opposite to "OK" (ie invalid
>>>> certificate on succcessful lookup). For helper internal errors please
>>>> use "BH" with a message= key-pair.
>>> OK. Just returning "OK" or "BH" for certificate validation is enough,
>>> because helper is just overwritting or rechecking the SSL errors.
>>> This is what we do in the first implementation we have...
> I think we should continue doing that: return OK regardless of the
> number of certificate problems confirmed or identified by the validator.
Consider what question the helper is trying to answer? "is certificate
valid"
OK/ERR make perfect sense as possible responses when you understand that
both are "success". One meaning valid certificate, one meaning non-valid
certificate.
BH the code for "broken helper" internal errors, independent of the
certificate validity.
>
>>> But we may want to rerurn "OK" only if the validator found the
>>> certificate good (no errors returned) and "ERR" if exist errors in one
>>> of the certificates.
>>> Opinions?
>> Yes that is consistent with the other helpers.
> I would not return ERR or ERROR when the validation helper is
> successfully answering a validation request. Whether the helper found or
> confirmed some invalid certificates is irrelevant -- it successfully did
> what it was asked to do.
That is not what OK means.
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.
>
> ERR or ERROR makes sense if, for example, the validation request itself
> was invalid but the helper is running fine and can accept the next request.
Yes it does make sense. However we should aim for simplicity and
consistency with the existing helper protocols which all use ERR as a
negative success result. The two protocols which differentiate response
results from helper errors use BH code instead of ERR. For now at least
I think it is a good idea to continue with the existing style.
> This is similar to a web server returning a page with bad news content
> using 200 OK status code.
It is even more smilar to a boolean conditional test responding true
whenever all the arguments exist regardless of their values.
> From there server point of view, everything is
> OK
... but a certificate is invalid. Not-OK.
> -- it is just doing its job and does not care whether it delivers bad
> news, good news, or no news at all.
This is not just a helper status field this is a test result AND helper
status field.
Amos
Received on Fri Sep 21 2012 - 09:04:38 MDT
This archive was generated by hypermail 2.2.0 : Fri Sep 21 2012 - 12:00:07 MDT