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

[Andrey K]

Hello, Alex and Amos,

I have submitted the PR: https://github.com/squid-cache/squid/pull/2410

Alex, thank you very much for your recommendations regarding the code
refactoring.

> Ideally, explicitOrDefaultValue should be private, but achieving that
> ideal requires more refactoring work, and I do not recommend it at this
> time.

I didn't see any difficulties there, so I've already made
explicitOrDefaultValue private.


> The "TODO: Some callers..." comment will need to be
> adjusted as well.

I have removed the "TODO" comment entirely since access to the storage
variable is now properly protected via accessors.

Kind regards,
    Ankor.

вт, 21 апр. 2026 г. в 17:47, Alex Rousskov <rousskov at measurement-factory.com
>:

> 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.
>
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20260422/741ac8a6/attachment-0001.htm>