Liberal config parsing with regard to quoted values

[johrstrom]

Hi - I maintain an Ansible role for installing a package that uses apache and could use this library.

The gist of this feature request is to basically be a little more liberal in parsing configurations with and without quotes, such that folks who have to template .conf files don't have to do fancy footwork in terms of which config needs quotes and which can't have them.

That is, templates can either always add quotes or never have them or both and any combination of quoted and non-quoted configs would work.

For example OIDCScope needs quotes

mod_auth_openidc/auth_openidc.conf

Line 151 in 109c841

#OIDCScope "<scope(s)-separated-by-spaces-and-enclosed-in-double-quotes>"

And OIDCStateMaxNumberOfCookies doesn't, but it does have spaces in it.

mod_auth_openidc/auth_openidc.conf

Line 574 in 109c841

#OIDCStateMaxNumberOfCookies <number> [false|true]

So someone templating a .conf file would have to know this and quote OIDCScope but ensure that OIDCStateMaxNumberOfCookies has no quotes.

Not sure about the level of difficulty in doing this (likely a lot) and/or why it's like this now (I'm sure there's a good reason) - but it would sure make the downstream templaters a lot happier.

[zandbelt]

in general there's a difference expressed by the quotes i.e. the value is a single value with spaces when surrounded with quotes, otherwise it denotes several different values/parameters; I'm guessing that OIDCScope is the only thing that stands out to you and that is because it is directly copied into the authorization request, which requires a space-separated string there by spec; technically OIDCScope could be changed to consume multiple values, but I'm not sure it is worth the effort, unless you see other problems with other primitives (since other primitives should consume - single and multiple - values that can be quoted or unquoted)

[johrstrom]

in general there's a difference expressed by the quotes

I see - you need to be able to differentiate 2 different values or 1 value that has space in it. I just used those 2 as off the top examples, but I get what you're saying - you need to know to interpret the values and quoting solves that.

OK - I guess I'll just take more care downstream. Thanks! This was a feature request/idea so feel free to close if you like.