Willy, 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.
Regards, Elliot On Thursday, January 9, 2020, 12:42:36 AM EST, Willy Tarreau <w...@1wt.eu> wrote: 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, Willy