Re: Propose to polish the consistency of case sensitivity in configurations

On 30/01/2013 9:21 a.m., Alex Rousskov wrote:
> On 01/29/2013 01:49 AM, Tianyin Xu wrote:
>
>> 3. For configuration like A B=C, A and B should be sensitive while C
>> should be insensitive.
> The case sensitivity of squid.conf directive parameters (i.e., all the
> stuff that follows the directive name) depends on the directive. Many C
> values are case-sensitive (e.g., various locations). However, you should
> not see a lot of str*cmp() code applied to those values -- if that is
> how you plan locating code for planned consistency fixes.
>
>
> We can probably declare all known names such as directive names and
> directive parameter names case-insensitive. That would make their
> handling consistent and backward compatible. However, that "permissive"
> direction feels inconsistent with recent changes that, among other
> things, restricted the variation of "positive" keywords such as "on",
> "enabled", and "yes".
>
> Other than consistency with some existing options, I do not see value in
> making configuration names case-insensitive (unless required so by some
> communication protocol, of course). Variations in case just make configs
> messier IMO. If we were to start from scratch, I would argue that all
> known configuration names should be case sensitive.
>
> I find it interesting that squid.conf.documented does not document
> default case sensitivity. Perhaps we can use that to justify making
> everything sensitive by default? :-)

It seems to have started as all case-sensitive then been moved to
insensitive in bits and pieces as users complained about the strictness,
Their mixed-case configs resulting in "Bungled config" when to a human
it reads "right".

I'm of the opinion we should be strict in what we want, loose in what we
accept, and liberal with annoying warnings when they don't follow the
party line.

NP: changing the case-sensitivity on directive names is an
all-or-nothing choice, since the directive parser functions are
auto-generated.

Amos
Received on Wed Jan 30 2013 - 07:13:04 MST