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., [email protected] 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. >> 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. 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. This is similar to a web server returning a page with bad news content using 200 OK status code. From there server point of view, everything is OK -- it is just doing its job and does not care whether it delivers bad news, good news, or no news at all. Thank you, Alex.
