[squid-dev] Proposal: Helper response: concatenated values with custom delimiter

[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.

ср, 22 апр. 2026 г. в 00:17, Alex Rousskov <rousskov at measurement-factory.com
>:

> On 2026-04-21 15:57, Amos Jeffries wrote:
>
> > The helper protocol documents ',' as list delimiter
>
> Where do we document ',' as a delimiter for annotation values in helper
> responses? I cannot find any such text on AddonHelpers page or inside
> cf.data.pre.
>
> > On 22/04/2026 03:11, Alex Rousskov wrote:
> >> [ If there is a real, serious need to optimize that existing support,
> >> then ] can we invent another syntax that will not result in
> >> mishandling any existing helper annotation (that is not treated as a
> >> list today)? For example, perhaps we can use isKeyNameChar()
> >> restrictions to place the delimiter first, before the annotation name?
> >>
> >>      (m=,)name=value1,value2
> >>
> >
> > Hmm.  When I combine that idea with older proposals floated about
> > kv-pair append/replace syntax there are some nice implications.
> >
> > How about this:
> >
> > 1) change of kv-pair grammar to:
> >
> >     kv-pair = [ '_' ] key [ flag ] '=' ( value / list )
>
> Yes, AFAICT, placing handling instructions _after_ the key should also
> work (for the same isKeyNameChar) reason) and is more aesthetically
> pleasing than my sketch above.
>
> If we really have to add this new feature, then I would probably use
> curly braces for these optional instructions, to make it similar to our
> logformat %codes:
>
>      name{...}=value...
>
> For example:
>
>      name{m}=value1,value2
>
> or
>
>      name{m=:}=value1:value2
>
>
> > * flag does not need to be limited to a single character. It could be
> > several.
>
> Any syntax should allow adding safe, backward-compatible support for
> additional/complex instructions in the future, of course, including
> multiple instructions.
>
>
> HTH,
>
> 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/4670a040/attachment.htm>