[squid-dev] Proposal: Helper response: concatenated values with custom delimiter
Andrey K
ankor2023 at gmail.com
Tue Apr 28 08:37:19 UTC 2026
Hello, Amos and Alex,
Thank you for sharing your thoughts on this.
On my part, I see two reasons for implementing support for the key=v1,v2,v3
format:
1. As Amos pointed out in the previous email, using this format will reduce
the volume of traffic sent from the helper, thereby reducing the processing
overhead.
However, the impact will be marginal; for 300 groups, the savings would be
roughly len("group=") * 300 = 1800 bytes.
It would be far more efficient to filter groups during PAC record parsing.
This filtering should be performed as early as possible to prevent further
processing of unused groups. I intend to spin this suggestion off into a
separate discussion thread.
2. Annotation of client connections. Currently, only one tag is supported
for client connection annotation: clt_conn_tag, and the current handler for
this tag does not support multiple occurrences of the same tag in the
helper response.
However, this issue is elegantly addressed by Amos's PR (
https://github.com/squid-cache/squid/pull/2399/) and my proposal to use
NotePairs filtering (
https://github.com/squid-cache/squid/pull/2399/#issuecomment-4224381496).
Additionally, custom helpers already have the flexibility to return values
in the key=v1,v2,v3 format, allowing users to retrieve specific values
using the -m=, option.
Furthermore, I’ve reconsidered the use of a comma as a default value
separator in helper responses. It seems like a poor choice because we
wouldn't be able to distinguish whether the comma is a separator or part of
the token itself.
Therefore, I suggest we close this proposal for now and wait for the
completion of PR#2399.
Kind regards,
Ankor.
вс, 26 апр. 2026 г. в 06:26, Amos Jeffries <squid3 at treenet.co.nz>:
> On 24/04/2026 01:42, Alex Rousskov wrote:
> > 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).
> >
>
> Remember that the earlier work by Andrey did bring up a reasonable
> rational for doing it anyway.
>
> Namely that supporting A,B,C lists improves the bandwidth cost of
> transmission between helper and Squid.
>
> Several of the Kerberos use-cases are sending many group names out of
> the helper. So this specific (accept comma-delimited value list) is not
> a theoretical optimization.
>
>
> Cheers
> Amos
>
> _______________________________________________
> 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/20260428/bd9ada96/attachment.htm>
More information about the squid-dev
mailing list