[squid-dev] Issue with acl note (without -m) splitting helper tokens containing commas

Alex Rousskov rousskov at measurement-factory.com
Tue Apr 21 14:47:15 UTC 2026


On 2026-04-21 04:01, Amos Jeffries wrote:
> I do not understand why we need to store annotations in their 
> serialized format in the first place.

Today, we store "serialized" annotations because different ACLs may 
specify different delimiters for the same imported annotation value. 
There are two reasonable ways to look at the current design:

A: This design is broken: Deserialization should happen at annotation 
import time (e.g., in helper response parser). Something like "-m" 
belongs to helper configuration, not ACLs. 2015 commit 76ee67ac was too 
focused on its "_match_ substrings of _existing_ annotations" use cases 
to realize that this is an import feature, not a matching feature.

B: This design is correct: Future ACLs may specify match regexes or even 
custom matching functions that would interpret imported values 
(effectively deserializign them) differently in different contexts. For 
example, a helper may send "metadata_" annotation for a denied user 
using a different syntax than the one used for "metadata_" annotation 
for an allowed user. 2015 commit 76ee67ac got it right: We should place 
"-m" inside ACLs, just like we place "-i" inside ACLs. If helpers want 
Squid to import a list of values, we should add such support, but that 
is a separate matter.


>>> 2. Supporting custom delimiters in helper responses.
>>> I also propose a PR to support a format where tag values can be 
>>> passed as a list with a custom delimiter:
>>>      <key>=<delimiter>"<value1><delimiter><value2>..."
>>> For example:
>>>      group=,"group1,group2,group3"
>>>      clt_con_tag=;"tag1;tag2;tag3"
>>> In this PR, the helper response would be tokenized based on the 
>>> specified custom delimiter, while still supporting delimiter escaping 
>>> with a backslash (\).
>>
>> I do not think this hack will work well as is, without syntax 
>> modifications because Squid already uses double quotes specially in 
>> this context. Overloading quotation meaning would be confusing/wrong.
>>
>> Overall, I am not excited about this hack, but let's start with these 
>> questions about its scope:
>>
>> * Can the same effect be achieved today by sending a helper response 
>> containing multiple same-name annotations? For example:
>>
>>      group=group1 group=group2 group=group3
>>
> 
> No. That will be added as three different kv-pair by the helper logic.

If the above does add three different name=value annotations with the 
same name, then the answer to my question is "Yes" rather than "No".

I did _not_ test this, but, after looking at 
Helper::Reply::parseResponseKeys() code, I suspect that, yes, "the same 
effect be achieved today by sending a helper response containing 
multiple same-name annotations". If that untested theory is correct, 
then we do not need an additional hack to allow helpers to send Squid a 
list of same-name values.

Alex.



More information about the squid-dev mailing list