[PATCH] Polish the Consistency of Case Sensitivity in Configurations

Hi, all,

I proposed to make it consistent for the case sensitivity of
configuration parsing couple weeks ago. I saw the replies from Alex,
Reiner, and Amos. All of you agreed on this (thanks a lot!). The
attached patch is for this purpose.

The patch follows Alex's idea, i.e., to make all the parameter names
and options case sensitive.

The patch is really simple that changes "strcasecmp" to "strcmp". It
mainly deal with constant configuration options (e.g., enumerative
options and boolean options). For directive names, it's already
consistent (case sensitive), as Amos said, the parser functions are
auto-generated.

I didn't change the case sensitivity of the following parameter values:

- user and group names
- host names
- domain and realm names
- ACL names
- filesystem names
- options in request/response/digest messages

Some of them should be case insensitive, and some of them I cannot
judge so I have to be conservative. If you want to make any of them
case sensitive, please let me know.

Let me know your comments and opinions about the patch. I'm always open.

Thanks,
Tianyin

On Tue, Jan 29, 2013 at 12:21 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> 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? :-)
>
>
> HTH,
>
> Alex.
>

--
Tianyin XU,
http://cseweb.ucsd.edu/~tixu/