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

From: Tianyin Xu <tixu_at_cs.ucsd.edu>
Date: Tue, 29 Jan 2013 14:08:55 -0800

Hi, Alex,

On Tue, Jan 29, 2013 at 1:00 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 01/29/2013 01:35 PM, Tianyin Xu wrote:
>
>> As long as the rule of case sensitivity is consistent, I
>> think it's good and less confusing. Anyway, identifiers like file
>> paths, urls, hostnames are case sensitive.
>
> Well, host names are usually case insensitive, but the exact answer (and
> many other similar caveats) depend on the context.
>
>
>> So, I should make everything case sensitive by replacing the
>> strcasecmp-like string comparison to strcmp. Am I right?
>
> You would have to carefully evaluate each context rather than quickly
> replacing everything, I am afraid. Also, I recommend waiting for other
> opinions before proceeding with this project: Others may prefer a
> different sensitivity default or even vote against any changes in this area!
>

Yes, sure! Replacing everything using a script is not responsible. I
won't do that.
Let's wait to see the opinions from other folks.

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

--
Tianyin XU,
http://cseweb.ucsd.edu/~tixu/
Received on Tue Jan 29 2013 - 22:09:03 MST

This archive was generated by hypermail 2.2.0 : Wed Jan 30 2013 - 12:00:08 MST