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

[Alex Rousskov]

On 2026-04-21 09:06, Andrey K wrote:
> Hello,
> 
> I've mentioned this briefly in another thread, but I’d like to start a 
> dedicated discussion regarding the support for a "concatenated" value 
> format in helper responses.
> 
> In a recent PR discussion 
> (https://github.com/squid-cache/squid/pull/2395#discussion_r3022844826 
> <https://github.com/squid-cache/squid/pull/2395#discussion_r3022844826>), Alex pointed out issues with using concatenated formats for passing tag values.
> 
> I propose adding support for a custom delimiter for concatenated values 
> within a single KV-pair in the helper output.
> 
> The proposed syntax is:
> <key>=<delimiter>"<value1><delimiter><value2>..."
> 
> Examples:
> group=,"group1,group2,group3"
> clt_con_tag=;"tag1;tag2;tag3"
> 
> Escaping logic:
>      If the delimiter appears inside a value within the token, it must 
> be double-escaped (\\) by the helper.
> For example:
> group=,"Staff:accountants\\,lawyers\\,security,Main_Office"
> This should produce two separate annotations:
> group=Staff:accountants,lawyers,security
> group=Main_Office
> 
> The choice of double escaping is intentional to maintain consistency 
> with the way strwordtok() processes quoted values in Squid.
> This approach ensures that we can preserve the underlying logic for 
> handling values while correctly splitting the "glued" tokens.
> 
> Currently, a comma-separated format is often used de facto, but Squid 
> stores these as a single Entry, requiring the -m option for annotation 
> checks.
> 
> Proposed Change:
> A minor modification to Helper::Reply::parseResponseKeys().
> 
> Pros:
> - More compact data transfer format.
> - Proper data storage on the Squid side (separate values instead of one 
> blob).
> - Flexibility for plugin developers via custom delimiters.
> - Eliminates the need for admins to manually manage the -m option for 
> these cases.
> 
> I am interested in implementing this and submitting a PR. Do you think 
> this solution is needed and fits the project's direction?

I do not know whether this problem needs a solution, but I am not 
excited about the proposed solution, especially because (AFAICT) Squid 
already supports helper responses with multiple same-name annotations 
and treats them correctly.

[ 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

HTH,

Alex.