<div dir="ltr">Hello, Alex and Amos,<div><br></div><div>I have submitted the PR: <a href="https://github.com/squid-cache/squid/pull/2410" target="_blank">https://github.com/squid-cache/squid/pull/2410</a></div><div><br></div><div>Alex, thank you very much for your recommendations regarding the code refactoring.</div><div><br></div><div>> Ideally, explicitOrDefaultValue should be private, but achieving that<br>> ideal requires more refactoring work, and I do not recommend it at this<br>> time.</div><div><br></div><div>I didn't see any difficulties there, so I've already made <font face="monospace">explicitOrDefaultValue</font> private.<br><br><br>> The "TODO: Some callers..." comment will need to be<br>> adjusted as well.</div><div><br></div><div>I have removed the <font face="monospace">"TODO"</font> comment entirely since access to the storage variable is now properly protected via accessors.</div><div><br></div><div>Kind regards,</div><div>    Ankor.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">вт, 21 апр. 2026 г. в 17:47, Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2026-04-21 04:01, Amos Jeffries wrote:<br>
> I do not understand why we need to store annotations in their <br>
> serialized format in the first place.<br>
<br>
Today, we store "serialized" annotations because different ACLs may <br>
specify different delimiters for the same imported annotation value. <br>
There are two reasonable ways to look at the current design:<br>
<br>
A: This design is broken: Deserialization should happen at annotation <br>
import time (e.g., in helper response parser). Something like "-m" <br>
belongs to helper configuration, not ACLs. 2015 commit 76ee67ac was too <br>
focused on its "_match_ substrings of _existing_ annotations" use cases <br>
to realize that this is an import feature, not a matching feature.<br>
<br>
B: This design is correct: Future ACLs may specify match regexes or even <br>
custom matching functions that would interpret imported values <br>
(effectively deserializign them) differently in different contexts. For <br>
example, a helper may send "metadata_" annotation for a denied user <br>
using a different syntax than the one used for "metadata_" annotation <br>
for an allowed user. 2015 commit 76ee67ac got it right: We should place <br>
"-m" inside ACLs, just like we place "-i" inside ACLs. If helpers want <br>
Squid to import a list of values, we should add such support, but that <br>
is a separate matter.<br>
<br>
<br>
>>> 2. Supporting custom delimiters in helper responses.<br>
>>> I also propose a PR to support a format where tag values can be <br>
>>> passed as a list with a custom delimiter:<br>
>>>      <key>=<delimiter>"<value1><delimiter><value2>..."<br>
>>> For example:<br>
>>>      group=,"group1,group2,group3"<br>
>>>      clt_con_tag=;"tag1;tag2;tag3"<br>
>>> In this PR, the helper response would be tokenized based on the <br>
>>> specified custom delimiter, while still supporting delimiter escaping <br>
>>> with a backslash (\).<br>
>><br>
>> I do not think this hack will work well as is, without syntax <br>
>> modifications because Squid already uses double quotes specially in <br>
>> this context. Overloading quotation meaning would be confusing/wrong.<br>
>><br>
>> Overall, I am not excited about this hack, but let's start with these <br>
>> questions about its scope:<br>
>><br>
>> * Can the same effect be achieved today by sending a helper response <br>
>> containing multiple same-name annotations? For example:<br>
>><br>
>>      group=group1 group=group2 group=group3<br>
>><br>
> <br>
> No. That will be added as three different kv-pair by the helper logic.<br>
<br>
If the above does add three different name=value annotations with the <br>
same name, then the answer to my question is "Yes" rather than "No".<br>
<br>
I did _not_ test this, but, after looking at <br>
Helper::Reply::parseResponseKeys() code, I suspect that, yes, "the same <br>
effect be achieved today by sending a helper response containing <br>
multiple same-name annotations". If that untested theory is correct, <br>
then we do not need an additional hack to allow helpers to send Squid a <br>
list of same-name values.<br>
<br>
Alex.<br>
<br>
_______________________________________________<br>
squid-dev mailing list<br>
<a href="mailto:squid-dev@lists.squid-cache.org" target="_blank">squid-dev@lists.squid-cache.org</a><br>
<a href="https://lists.squid-cache.org/listinfo/squid-dev" rel="noreferrer" target="_blank">https://lists.squid-cache.org/listinfo/squid-dev</a><br>
</blockquote></div>