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
