Re: Proposal: Helper response: concatenated values with custom delimiter
Andrey K <[email protected]> Tue, 28 Apr 2026 11:37:19 +0300
| Newsgroups | gmane.comp.web.squid.devel |
|---|---|
| Message-ID | <CADJd0Y2e3x-ZPjd0jfw92mGtvXh3Zxx7qe15iHHRh-NZat0XUg@mail.gmail.com> |
--===============2084624229642474597==
Content-Type: multipart/alternative; boundary="0000000000005753c406508124ae"
--0000000000005753c406508124ae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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=3Dv1,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=3D") * 300 =3D 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=3Dv1,v2,v3 format, allowing users to retrieve specific values
using the -m=3D, option.
Furthermore, I=E2=80=99ve reconsidered the use of a comma as a default valu=
e
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.
=D0=B2=D1=81, 26 =D0=B0=D0=BF=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 06:26, Amo=
s Jeffries <[email protected]>:
> 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=3Dv1 key=3Dv2
> >> format, and the
> >> key=3Dv1,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 ver=
y
> > compelling use case to add a "list-values" optimization (when we alread=
y
> > 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
> [email protected]
> https://lists.squid-cache.org/listinfo/squid-dev
>
--0000000000005753c406508124ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">Hello, Amos and Alex,<div><br></div><div>=
Thank you for sharing your thoughts on this.<br><br>On my part, I see two r=
easons for implementing support for the <font face=3D"monospace">key=3Dv1,v=
2,v3</font> format:<br><br>1. As Amos pointed out in the previous email, us=
ing this format will reduce the volume of traffic sent from the helper, the=
reby reducing the processing overhead.<br>However, the impact will be margi=
nal; for 300 groups, the savings would be roughly<font face=3D"monospace"> =
len("group=3D") * 300 =3D 1800 bytes</font>. <br>It would be far =
more efficient to filter groups during PAC record parsing. This filtering s=
hould be performed as early as possible to prevent further processing of un=
used groups. I intend to spin this suggestion off into a separate discussio=
n thread.</div><div><br>2. Annotation of client connections. Currently, onl=
y one tag is supported for client connection annotation: <font face=3D"mono=
space">clt_conn_tag</font>, and the current handler for this tag does not s=
upport multiple occurrences of the same tag in the helper response.<br>Howe=
ver, this issue is elegantly addressed by Amos's PR (<a href=3D"https:/=
/github.com/squid-cache/squid/pull/2399/">https://github.com/squid-cache/sq=
uid/pull/2399/</a>) and my proposal to use NotePairs filtering (<a href=3D"=
https://github.com/squid-cache/squid/pull/2399/#issuecomment-4224381496">ht=
tps://github.com/squid-cache/squid/pull/2399/#issuecomment-4224381496</a>).=
<br><br>Additionally, custom helpers already have the flexibility to return=
values in the <font face=3D"monospace">key=3Dv1,v2,v3</font> format, allow=
ing users to retrieve specific values using the<font face=3D"monospace"> -m=
=3D, </font>option.<br><br>Furthermore, I=E2=80=99ve reconsidered the use o=
f 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 com=
ma is a separator or part of the token itself.<br><br><br>Therefore, I sugg=
est we close this proposal for now and wait for the completion of PR#2399.<=
/div><div><br></div><div>Kind regards,</div><div>=C2=A0 =C2=A0 =C2=A0Ankor.=
</div></div><div><br></div><br><div class=3D"gmail_quote gmail_quote_contai=
ner"><div dir=3D"ltr" class=3D"gmail_attr">=D0=B2=D1=81, 26 =D0=B0=D0=BF=D1=
=80. 2026=E2=80=AF=D0=B3. =D0=B2 06:26, Amos Jeffries <<a href=3D"mailto=
:[email protected]">[email protected]</a>>:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">On 24/04/2026 01:42, Alex Rousskov wro=
te:<br>
> On 2026-04-22 07:24, Andrey K wrote:<br>
>> Hello, Amos and Alex,<br>
>><br>
>> Thank you for the discussion and the proposed formats.<br>
>><br>
>> Since we already support the<br>
>> =C2=A0=C2=A0 =C2=A0 key=3Dv1 key=3Dv2<br>
>> format, and the<br>
>> =C2=A0=C2=A0 =C2=A0 key=3Dv1,v2<br>
>> format is currently undocumented, I think we should answer two <br=
>
>> questions first:<br>
>><br>
>> 1. Do we really need to support list-values? It seems Alex thinks =
we <br>
>> might not need them at all.<br>
> <br>
> If you have to ask, then the answer is "no" or "not yet=
": We need a very <br>
> compelling use case to add a "list-values" optimization (whe=
n we already <br>
> support lists of values). Since you are not sure, and you were the onl=
y <br>
> one making/wanting related changes (AFAICT), we evidently lack such a =
<br>
> case today.<br>
> <br>
> Rule of thumb: Avoid complex optimizations until their expense can be =
<br>
> justified by a use case (that can also guide their implementation).<br=
>
> <br>
<br>
Remember that the earlier work by Andrey did bring up a reasonable <br>
rational for doing it anyway.<br>
<br>
Namely that supporting A,B,C lists improves the bandwidth cost of <br>
transmission between helper and Squid.<br>
<br>
Several of the Kerberos use-cases are sending many group names out of <br>
the helper.=C2=A0 So this specific (accept comma-delimited value list) is n=
ot <br>
a theoretical optimization.<br>
<br>
<br>
Cheers<br>
Amos<br>
<br>
_______________________________________________<br>
squid-dev mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">squid-=
[email protected]</a><br>
<a href=3D"https://lists.squid-cache.org/listinfo/squid-dev" rel=3D"norefer=
rer" target=3D"_blank">https://lists.squid-cache.org/listinfo/squid-dev</a>=
<br>
</blockquote></div></div>
--0000000000005753c406508124ae--
--===============2084624229642474597==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
squid-dev mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-dev
--===============2084624229642474597==--