[squid-dev] [RFC] Where do ACL flags belong?

[Alex Rousskov]

On 12/04/2015 11:04 PM, Amos Jeffries wrote:
> On 5/12/2015 8:42 a.m., Alex Rousskov wrote:
>> I am not against adding +n support, but I do not recommend forcing users
>> to add +n, just like we do not force them to add +i.

> Then do you thik -n is used rarely enough to warrant breaking BC silently?

Personally, I do not, but this is not my area of expertise so others'
voices (including yours) should carry more weight. My paragraph above
was about new configurations, not about BC. That was misleading; sorry.


> Because having warnings about the line change with no way to silence
> them in the case that it was intentional is not a good option.

I agree. On the other hand, forcing explicit +n in new configurations is
not a good option either.


I see two reasonable solutions:

A. Rename -n to -d (--direct), -a (--as-is), or similar (the exact new
name is not important to me). Warn about inconsistent old -n use. Do not
warn about "inconsistent" -d use. If the upgrading admin was
[incorrectly] interpreting -n the way we implemented -d, then all they
need to do to quiet the warning is to replace every -n with -d, which is
fairly easy.


B. Add a general BC and/or warning suppression mechanism:

    101:acl foo dstdomain    v1
    102:acl foo dstdomain -n v2

  squid.conf:102: Warning: Inconsistent -n use within acl foo
  squid.conf:101:     previous acl foo line without -n
  ... and many more such warnings,
  ... one for each acl that uses -n inconsistently (at least)


Now the admin adds a warning suppression directive:

    100:backward_compatibility acl-n-applies-to-one-line
    101:acl foo dstdomain v1
    102:acl foo dstdomain -n v2

  squid.conf:100: Warning: Not warning about acl-n-applies-to-one-line
  ... and no warnings about inconsistent -n use follow ...


In the extreme, we can even silence that single warning above:

 backward_compatibility \
     acl-n-applies-to-entire-acl \
     no-backward-compatibility-warnings


I like (B) because it is a general mechanism we can reuse for many
future upgrades as well.

Any better ideas? Which BC handling method do you prefer?



>> (-i
>> support preserved for backward compatibility, but I would probably warn
>> about it anyway). Such support does not really add much value AFAICT,
>> but the resulting ACL lines become more and more difficult for a human
>> to interpret correctly because each flag "area" overlaps subsequent
>> flags on the same line. KISS.
> 
> 
> Maybe we should deprecate +i and warn admins to split the line where the
> +i is?
> If you agree, that change and WARNING can go in immediately.

I would agree (to streamline acl syntax), but, again, I do not assign
much weight to my preferences regarding such BC issues.

Also, we may want to add something like (B) above before we add more
warnings that require non-trivial squid.conf changes. Please keep in
mind that many squid.conf files are generated by programs so changing
them requires going through a more complicated _process_ than running a
sed script on a static file.


>> General flags in front of lines loaded from an acl parameter file should
>> be supported.


> You mean in the data file or the squid.conf?

data file


> If you mean the data file, that sounds like its moving the goalpposts of
> this proposal. It can be planned to allow for future addition, but not
> in scope for coding yet.

I thought -i and even perhaps -n in data files is already supported. If
not, I completely agree that support for flags in data files should not
be added during this project -- it becomes a separate issue that we just
need to keep in mind.


> I assumed that since this proposal was coming from you it was a Factory
> intention to do anyway. Just design details and timing to organize.

Factory can do it, but if somebody else can do it quicker, they should
speak up!


> January sounds like it would be just scraping into the beta cycle. But I
> do request that back-compat warning happen within the next few weeks, so
> we can at least start to see if the assumptions are correct.

I cannot promise anything within the next few weeks, but perhaps
somebody else will volunteer to contribute [this part of] the changes.

Let's try to agree on how to handle BC issue first.


Thank you,

Alex.