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

[Alex Rousskov]

On 2026-04-22 07:24, Andrey K wrote:
> Hello, Amos and Alex,
> 
> Thank you for the discussion and the proposed formats.
> 
> Since we already support the
>      key=v1 key=v2
> format, and the
>      key=v1,v2
> format is currently undocumented, I think we should answer two questions 
> first:
> 
> 1. Do we really need to support list-values? It seems Alex thinks we 
> might not need them at all.

If you have to ask, then the answer is "no" or "not yet": We need a very 
compelling use case to add a "list-values" optimization (when we already 
support lists of values). Since you are not sure, and you were the only 
one making/wanting related changes (AFAICT), we evidently lack such a 
case today.

Rule of thumb: Avoid complex optimizations until their expense can be 
justified by a use case (that can also guide their implementation).


> 2. If we do, is a comma enough as the default separator?

It is enough as a starting point _if_ we preserve the possibility of 
adding reasonable support for other separators without breaking any 
existing (at that time) helpers.


> I believe we should settle these points before designing a new format 
> for value lists.

I agree. Moreover, if the answer to the first question is "no" (or "not 
yet"), then we do not need to answer the second question (now).


Cheers,

Alex.


> ср, 22 апр. 2026 г. в 00:17, Alex Rousskov:
> 
>     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 <mailto:squid-dev at lists.squid-cache.org>
>     https://lists.squid-cache.org/listinfo/squid-dev
>     <https://lists.squid-cache.org/listinfo/squid-dev>
>