Thanks for the note back.  Your suggestion seems like a good approach.  I'll 
submit a new patch when I have this worked up and tested for a bit.


    On Thursday, January 9, 2020, 12:42:36 AM EST, Willy Tarreau <w...@1wt.eu> 
 Hi Elliot & Chris,

On Sun, Jan 05, 2020 at 09:09:18PM +0000, Elliot Otchet wrote:
>  Hi,
> An updated patch is attached for the implementation that adds documentation
> to the doc/configuration.txt and fixes an issue identified during testing.
> I couldn't locate tests for the preexisting ssl_c_s_dn and related
> parameters.  I'd be happy to add tests for the new ones if someone could
> point me in the right direction of the existing ones.

Sorry for the late response, it seems your previous messages were sent
in the unlucky period where everyone's busy doing everything but looking 
at the mailing list :-)

I understand the problem you're facing and I agree that it's easier to have
fresh new code to handle this. However instead of having a separate set of
sample fetches for this, it would be much better to add an optional argument
to the existing one which would change the output format. This would even
allow to factor some existing code I guess. Look for example at the UUID
sample fetch which is a good illustration of this:

  uuid([<version>]) : string
    Returns a UUID following the RFC4122 standard. If the version is not
    specified, a UUID version 4 (fully random) is returned.

I'm seeing that ssl_c_i_dn() and ssl_c_s_dn() already take up to two
optional args. But that doesn't prevent one from adding a third one with
the output format specification. If you just want to get it emitted with
no specific field filtering you could just use "ssl_c_i_dn(,,rfc2253)" for
example (or any other arg value you choose).

Just my two cents,


Reply via email to