Hello,
I propose to adjust Squid code to reject repeated same-name
annotations from each and every source that supplies annotations:
* "note" directive
* adaptation_meta directive
* annotate_transaction ACL [1]
* annotate_client ACL [1]
* adaptation services responses (eCAP and ICAP)
* helper responses
If this RFC is approved: A configuration that contains a directive with
repeated same-name annotations will be rejected with a fatal ERROR[2]. A
helper or service response that contains repeated same-name annotations
will trigger a non-fatal (to Squid or transaction) cache.log ERROR[2].
Currently, Squid treats repeated same-name annotations inconsistently.
Depending on the annotation source, Squid processing code may
* use the first same-name annotation and ignore repetitions
* use the last same-name annotation and ignore repetitions
* use all same-name annotations, honoring repetitions
These inconsistencies make it difficult to improve/enhance/optimize
Squid code, while Squid ignorance hides misconfigurations and
helper/service implementation bugs, including problems that may be
related to access controls and other sensitive matters.
Any objections or better ideas?
Thank you,
Alex.
[1] In this context, we are talking about same-name annotations
mentioned in the corresponding ACL _configuration_ (i.e. all "acl"
directives with a given ACL name). A repeated _computation_ of
annotate_foo ACL will continue to deal with same-name annotations as
documented -- a "name+=value" configuration will continue to append
values to the existing same-name annotation, while a "name=value"
configuration will continue to overwrite any existing same-name annotation.
[2] Repeated same-name annotations that all have identical _values_ will
be flagged with a WARNING instead. Some overly simplistic configuration
generators, complicated configurations build from many include files,
and dumb helpers/services might generate repeated same-everything
annotations. Since such repetitions can be _safely_ ignored (honoring
just one name=value pair among all the identical ones), we do not have
to reject the configuration or log an ERROR because of them.
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
