[squid-dev] RFC: Reject repeated same-name annotations

ngtech1ltd at gmail.com ngtech1ltd at gmail.com
Thu Dec 15 22:27:19 UTC 2022


Hey Alex,

I must admit that I didn't understand it enough to make sense on what specific scenario for example it will affect.
We have a set of sources for a "note" ie:
* "note" directive
* adaptation_meta directive
* annotate_transaction ACL [1]
* annotate_client ACL [1]
* adaptation services responses (eCAP and ICAP)
* helper responses

The only one I have used until today is the helpers and maybe once more with an ICAP service.

I couldn't make sense the 1+2 appended comments with the rejection RFC.
I assumed that what would happen is that if multiple helpers for example will use the same note or
a single response will contain multiple notes with the same key these will be appended.
The last time I have seen this I assumed it's in an array fashion ie multiple values compared to a single string.
I do not remember the subject enough but what I do remember is that there was an issue with
the comparison/check of a note ACL when two values were applied with the same name.

>From what I understood until now a single helper that will respond with multiple note_1=v note_1=v
Will trigger a fatal error and I have mixed feelings about it.
However, if multiple helpers will send both each in it's turn a note_1=v these will be appended.

I agree that the result should be predictable however if logs can help to trace the issue I believe it's predicted enough
to not say about the current situation "un-predictable".
I would say that since it's not a "sync" engine which the timing belt must not miss a "beat" or a "tooth"
It's an async engine which is far more complex.

I hope I understood the RFC and what's above it so my words will make sense of themselves.

Eliezer

----
Eliezer Croitoru
NgTech, Tech Support
Mobile: +972-5-28704261
Email: ngtech1ltd at gmail.com
Web: https://ngtech.co.il/
My-Tube: https://tube.ngtech.co.il/

-----Original Message-----
From: squid-dev <squid-dev-bounces at lists.squid-cache.org> On Behalf Of Alex Rousskov
Sent: Thursday, 15 December 2022 23:30
To: Squid Developers <squid-dev at lists.squid-cache.org>
Subject: [squid-dev] RFC: Reject repeated same-name annotations

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 at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev



More information about the squid-dev mailing list