Skip to content

Commit 22e05d6

Browse files
squidadmsquidadm
committed
2026-04-22
1 parent 3f10e3f commit 22e05d6

23 files changed

Lines changed: 1293 additions & 26 deletions

‎squid-dev/2026-April.txt‎

Lines changed: 323 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2961,3 +2961,326 @@ HTH,
29612961
Alex.
29622962

29632963

2964+
From ankor2023 at gmail.com Wed Apr 22 09:45:23 2026
2965+
From: ankor2023 at gmail.com (Andrey K)
2966+
Date: Wed, 22 Apr 2026 12:45:23 +0300
2967+
Subject: [squid-dev] Proposal: Helper response: concatenated values with
2968+
custom delimiter
2969+
In-Reply-To: <35430c76-dbda-436c-b015-0214c5b4c352@measurement-factory.com>
2970+
References: <CADJd0Y2fXgTkm4nCQw4WqymYFWY0EDUPk_bifHh2bhKvZYC8XQ@mail.gmail.com>
2971+
<4a1febf2-bc80-4088-93f6-0d4835c0b9ea@measurement-factory.com>
2972+
<e06eec20-edf3-4e0c-85f1-525364ddeb2b@treenet.co.nz>
2973+
<35430c76-dbda-436c-b015-0214c5b4c352@measurement-factory.com>
2974+
Message-ID: <CADJd0Y0HWzDK6L13piLt03VyM+6uVCc3wh8wc-38i5=MAaYhwQ@mail.gmail.com>
2975+
2976+
Hello, Alex and Amos,
2977+
2978+
I have submitted the PR: https://github.com/squid-cache/squid/pull/2410
2979+
2980+
Alex, thank you very much for your recommendations regarding the code
2981+
refactoring.
2982+
2983+
> Ideally, explicitOrDefaultValue should be private, but achieving that
2984+
> ideal requires more refactoring work, and I do not recommend it at this
2985+
> time.
2986+
2987+
I didn't see any difficulties there, so I've already made
2988+
explicitOrDefaultValue private.
2989+
2990+
2991+
> The "TODO: Some callers..." comment will need to be
2992+
> adjusted as well.
2993+
2994+
I have removed the "TODO" comment entirely since access to the storage
2995+
variable is now properly protected via accessors.
2996+
2997+
Kind regards,
2998+
Ankor.
2999+
3000+
??, 22 ???. 2026??. ? 00:17, Alex Rousskov <rousskov at measurement-factory.com
3001+
>:
3002+
3003+
> On 2026-04-21 15:57, Amos Jeffries wrote:
3004+
>
3005+
> > The helper protocol documents ',' as list delimiter
3006+
>
3007+
> Where do we document ',' as a delimiter for annotation values in helper
3008+
> responses? I cannot find any such text on AddonHelpers page or inside
3009+
> cf.data.pre.
3010+
>
3011+
> > On 22/04/2026 03:11, Alex Rousskov wrote:
3012+
> >> [ If there is a real, serious need to optimize that existing support,
3013+
> >> then ] can we invent another syntax that will not result in
3014+
> >> mishandling any existing helper annotation (that is not treated as a
3015+
> >> list today)? For example, perhaps we can use isKeyNameChar()
3016+
> >> restrictions to place the delimiter first, before the annotation name?
3017+
> >>
3018+
> >> (m=,)name=value1,value2
3019+
> >>
3020+
> >
3021+
> > Hmm. When I combine that idea with older proposals floated about
3022+
> > kv-pair append/replace syntax there are some nice implications.
3023+
> >
3024+
> > How about this:
3025+
> >
3026+
> > 1) change of kv-pair grammar to:
3027+
> >
3028+
> > kv-pair = [ '_' ] key [ flag ] '=' ( value / list )
3029+
>
3030+
> Yes, AFAICT, placing handling instructions _after_ the key should also
3031+
> work (for the same isKeyNameChar) reason) and is more aesthetically
3032+
> pleasing than my sketch above.
3033+
>
3034+
> If we really have to add this new feature, then I would probably use
3035+
> curly braces for these optional instructions, to make it similar to our
3036+
> logformat %codes:
3037+
>
3038+
> name{...}=value...
3039+
>
3040+
> For example:
3041+
>
3042+
> name{m}=value1,value2
3043+
>
3044+
> or
3045+
>
3046+
> name{m=:}=value1:value2
3047+
>
3048+
>
3049+
> > * flag does not need to be limited to a single character. It could be
3050+
> > several.
3051+
>
3052+
> Any syntax should allow adding safe, backward-compatible support for
3053+
> additional/complex instructions in the future, of course, including
3054+
> multiple instructions.
3055+
>
3056+
>
3057+
> HTH,
3058+
>
3059+
> Alex.
3060+
>
3061+
> _______________________________________________
3062+
> squid-dev mailing list
3063+
> squid-dev at lists.squid-cache.org
3064+
> https://lists.squid-cache.org/listinfo/squid-dev
3065+
>
3066+
-------------- next part --------------
3067+
An HTML attachment was scrubbed...
3068+
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20260422/4670a040/attachment.htm>
3069+
3070+
From ankor2023 at gmail.com Wed Apr 22 09:46:46 2026
3071+
From: ankor2023 at gmail.com (Andrey K)
3072+
Date: Wed, 22 Apr 2026 12:46:46 +0300
3073+
Subject: [squid-dev] Issue with acl note (without -m) splitting helper
3074+
tokens containing commas
3075+
In-Reply-To: <b57c2d2b-37ed-4fe6-ab49-09bcc7a6ba76@measurement-factory.com>
3076+
References: <CADJd0Y1M=Z9VY6spPMcR1SoFgrfDKuWdbWM=6=A=CEoS+oi+Og@mail.gmail.com>
3077+
<10e9ebca-6fa4-48a9-9082-1c03eb97a792@measurement-factory.com>
3078+
<3d5b3018-9757-4e7d-bb24-172c674c2359@treenet.co.nz>
3079+
<b57c2d2b-37ed-4fe6-ab49-09bcc7a6ba76@measurement-factory.com>
3080+
Message-ID: <CADJd0Y0Gz1CycykX8SbYuNtJqxvDtgGdg93xfo34tBouA=kpzg@mail.gmail.com>
3081+
3082+
Hello, Alex and Amos,
3083+
3084+
I have submitted the PR: https://github.com/squid-cache/squid/pull/2410
3085+
3086+
Alex, thank you very much for your recommendations regarding the code
3087+
refactoring.
3088+
3089+
> Ideally, explicitOrDefaultValue should be private, but achieving that
3090+
> ideal requires more refactoring work, and I do not recommend it at this
3091+
> time.
3092+
3093+
I didn't see any difficulties there, so I've already made
3094+
explicitOrDefaultValue private.
3095+
3096+
3097+
> The "TODO: Some callers..." comment will need to be
3098+
> adjusted as well.
3099+
3100+
I have removed the "TODO" comment entirely since access to the storage
3101+
variable is now properly protected via accessors.
3102+
3103+
Kind regards,
3104+
Ankor.
3105+
3106+
??, 21 ???. 2026??. ? 17:47, Alex Rousskov <rousskov at measurement-factory.com
3107+
>:
3108+
3109+
> On 2026-04-21 04:01, Amos Jeffries wrote:
3110+
> > I do not understand why we need to store annotations in their
3111+
> > serialized format in the first place.
3112+
>
3113+
> Today, we store "serialized" annotations because different ACLs may
3114+
> specify different delimiters for the same imported annotation value.
3115+
> There are two reasonable ways to look at the current design:
3116+
>
3117+
> A: This design is broken: Deserialization should happen at annotation
3118+
> import time (e.g., in helper response parser). Something like "-m"
3119+
> belongs to helper configuration, not ACLs. 2015 commit 76ee67ac was too
3120+
> focused on its "_match_ substrings of _existing_ annotations" use cases
3121+
> to realize that this is an import feature, not a matching feature.
3122+
>
3123+
> B: This design is correct: Future ACLs may specify match regexes or even
3124+
> custom matching functions that would interpret imported values
3125+
> (effectively deserializign them) differently in different contexts. For
3126+
> example, a helper may send "metadata_" annotation for a denied user
3127+
> using a different syntax than the one used for "metadata_" annotation
3128+
> for an allowed user. 2015 commit 76ee67ac got it right: We should place
3129+
> "-m" inside ACLs, just like we place "-i" inside ACLs. If helpers want
3130+
> Squid to import a list of values, we should add such support, but that
3131+
> is a separate matter.
3132+
>
3133+
>
3134+
> >>> 2. Supporting custom delimiters in helper responses.
3135+
> >>> I also propose a PR to support a format where tag values can be
3136+
> >>> passed as a list with a custom delimiter:
3137+
> >>> <key>=<delimiter>"<value1><delimiter><value2>..."
3138+
> >>> For example:
3139+
> >>> group=,"group1,group2,group3"
3140+
> >>> clt_con_tag=;"tag1;tag2;tag3"
3141+
> >>> In this PR, the helper response would be tokenized based on the
3142+
> >>> specified custom delimiter, while still supporting delimiter escaping
3143+
> >>> with a backslash (\).
3144+
> >>
3145+
> >> I do not think this hack will work well as is, without syntax
3146+
> >> modifications because Squid already uses double quotes specially in
3147+
> >> this context. Overloading quotation meaning would be confusing/wrong.
3148+
> >>
3149+
> >> Overall, I am not excited about this hack, but let's start with these
3150+
> >> questions about its scope:
3151+
> >>
3152+
> >> * Can the same effect be achieved today by sending a helper response
3153+
> >> containing multiple same-name annotations? For example:
3154+
> >>
3155+
> >> group=group1 group=group2 group=group3
3156+
> >>
3157+
> >
3158+
> > No. That will be added as three different kv-pair by the helper logic.
3159+
>
3160+
> If the above does add three different name=value annotations with the
3161+
> same name, then the answer to my question is "Yes" rather than "No".
3162+
>
3163+
> I did _not_ test this, but, after looking at
3164+
> Helper::Reply::parseResponseKeys() code, I suspect that, yes, "the same
3165+
> effect be achieved today by sending a helper response containing
3166+
> multiple same-name annotations". If that untested theory is correct,
3167+
> then we do not need an additional hack to allow helpers to send Squid a
3168+
> list of same-name values.
3169+
>
3170+
> Alex.
3171+
>
3172+
> _______________________________________________
3173+
> squid-dev mailing list
3174+
> squid-dev at lists.squid-cache.org
3175+
> https://lists.squid-cache.org/listinfo/squid-dev
3176+
>
3177+
-------------- next part --------------
3178+
An HTML attachment was scrubbed...
3179+
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20260422/741ac8a6/attachment-0001.htm>
3180+
3181+
From ankor2023 at gmail.com Wed Apr 22 11:24:13 2026
3182+
From: ankor2023 at gmail.com (Andrey K)
3183+
Date: Wed, 22 Apr 2026 14:24:13 +0300
3184+
Subject: [squid-dev] Proposal: Helper response: concatenated values with
3185+
custom delimiter
3186+
In-Reply-To: <35430c76-dbda-436c-b015-0214c5b4c352@measurement-factory.com>
3187+
References: <CADJd0Y2fXgTkm4nCQw4WqymYFWY0EDUPk_bifHh2bhKvZYC8XQ@mail.gmail.com>
3188+
<4a1febf2-bc80-4088-93f6-0d4835c0b9ea@measurement-factory.com>
3189+
<e06eec20-edf3-4e0c-85f1-525364ddeb2b@treenet.co.nz>
3190+
<35430c76-dbda-436c-b015-0214c5b4c352@measurement-factory.com>
3191+
Message-ID: <CADJd0Y3dcvhy29RBP5_upzGOJXPFryLzq_CvzU2Yq_Q33oQt6w@mail.gmail.com>
3192+
3193+
Hello, Amos and Alex,
3194+
3195+
Thank you for the discussion and the proposed formats.
3196+
3197+
Since we already support the
3198+
key=v1 key=v2
3199+
format, and the
3200+
key=v1,v2
3201+
format is currently undocumented, I think we should answer two questions
3202+
first:
3203+
3204+
1. Do we really need to support list-values? It seems Alex thinks we might
3205+
not need them at all.
3206+
2. If we do, is a comma enough as the default separator?
3207+
3208+
I believe we should settle these points before designing a new format for
3209+
value lists.
3210+
3211+
What are your thoughts?
3212+
3213+
Kind regards,
3214+
Ankor.
3215+
3216+
3217+
??, 22 ???. 2026??. ? 00:17, Alex Rousskov <rousskov at measurement-factory.com
3218+
>:
3219+
3220+
> On 2026-04-21 15:57, Amos Jeffries wrote:
3221+
>
3222+
> > The helper protocol documents ',' as list delimiter
3223+
>
3224+
> Where do we document ',' as a delimiter for annotation values in helper
3225+
> responses? I cannot find any such text on AddonHelpers page or inside
3226+
> cf.data.pre.
3227+
>
3228+
> > On 22/04/2026 03:11, Alex Rousskov wrote:
3229+
> >> [ If there is a real, serious need to optimize that existing support,
3230+
> >> then ] can we invent another syntax that will not result in
3231+
> >> mishandling any existing helper annotation (that is not treated as a
3232+
> >> list today)? For example, perhaps we can use isKeyNameChar()
3233+
> >> restrictions to place the delimiter first, before the annotation name?
3234+
> >>
3235+
> >> (m=,)name=value1,value2
3236+
> >>
3237+
> >
3238+
> > Hmm. When I combine that idea with older proposals floated about
3239+
> > kv-pair append/replace syntax there are some nice implications.
3240+
> >
3241+
> > How about this:
3242+
> >
3243+
> > 1) change of kv-pair grammar to:
3244+
> >
3245+
> > kv-pair = [ '_' ] key [ flag ] '=' ( value / list )
3246+
>
3247+
> Yes, AFAICT, placing handling instructions _after_ the key should also
3248+
> work (for the same isKeyNameChar) reason) and is more aesthetically
3249+
> pleasing than my sketch above.
3250+
>
3251+
> If we really have to add this new feature, then I would probably use
3252+
> curly braces for these optional instructions, to make it similar to our
3253+
> logformat %codes:
3254+
>
3255+
> name{...}=value...
3256+
>
3257+
> For example:
3258+
>
3259+
> name{m}=value1,value2
3260+
>
3261+
> or
3262+
>
3263+
> name{m=:}=value1:value2
3264+
>
3265+
>
3266+
> > * flag does not need to be limited to a single character. It could be
3267+
> > several.
3268+
>
3269+
> Any syntax should allow adding safe, backward-compatible support for
3270+
> additional/complex instructions in the future, of course, including
3271+
> multiple instructions.
3272+
>
3273+
>
3274+
> HTH,
3275+
>
3276+
> Alex.
3277+
>
3278+
> _______________________________________________
3279+
> squid-dev mailing list
3280+
> squid-dev at lists.squid-cache.org
3281+
> https://lists.squid-cache.org/listinfo/squid-dev
3282+
>
3283+
-------------- next part --------------
3284+
An HTML attachment was scrubbed...
3285+
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20260422/1d8664a6/attachment.htm>
3286+

‎squid-dev/2026-April/010018.html‎

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@
1212
}
1313
</style>
1414
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
15-
<LINK REL="Previous" HREF="010028.html">
15+
<LINK REL="Previous" HREF="010033.html">
1616
<LINK REL="Next" HREF="010020.html">
1717
</HEAD>
1818
<BODY BGCOLOR="#ffffff">
@@ -23,7 +23,7 @@ <H1>[squid-dev] NO_SPECIAL_HANDLING define for HTTP methods</H1>
2323
</A><BR>
2424
<I>Sun Apr 19 21:35:02 UTC 2026</I>
2525
<P><UL>
26-
<LI>Previous message (by thread): <A HREF="010028.html">[squid-dev] Issue with acl note (without -m) splitting helper tokens containing commas
26+
<LI>Previous message (by thread): <A HREF="010033.html">[squid-dev] Issue with acl note (without -m) splitting helper tokens containing commas
2727
</A></li>
2828
<LI>Next message (by thread): <A HREF="010020.html">[squid-dev] NO_SPECIAL_HANDLING define for HTTP methods
2929
</A></li>
@@ -54,11 +54,12 @@ <H1>[squid-dev] NO_SPECIAL_HANDLING define for HTTP methods</H1>
5454

5555

5656

57+
5758
<!--endarticle-->
5859
<HR>
5960
<P><UL>
6061
<!--threads-->
61-
<LI>Previous message (by thread): <A HREF="010028.html">[squid-dev] Issue with acl note (without -m) splitting helper tokens containing commas
62+
<LI>Previous message (by thread): <A HREF="010033.html">[squid-dev] Issue with acl note (without -m) splitting helper tokens containing commas
6263
</A></li>
6364
<LI>Next message (by thread): <A HREF="010020.html">[squid-dev] NO_SPECIAL_HANDLING define for HTTP methods
6465
</A></li>

‎squid-dev/2026-April/010020.html‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -61,6 +61,7 @@ <H1>[squid-dev] NO_SPECIAL_HANDLING define for HTTP methods</H1>
6161

6262

6363

64+
6465
<!--endarticle-->
6566
<HR>
6667
<P><UL>

‎squid-dev/2026-April/010023.html‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -69,6 +69,7 @@ <H1>[squid-dev] NO_SPECIAL_HANDLING define for HTTP methods</H1>
6969

7070

7171

72+
7273
<!--endarticle-->
7374
<HR>
7475
<P><UL>

‎squid-dev/2026-April/010026.html‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -99,6 +99,7 @@ <H1>[squid-dev] Proposal: Helper response: concatenated values with custom delim
9999

100100

101101

102+
102103
<!--endarticle-->
103104
<HR>
104105
<P><UL>

0 commit comments

Comments
 (0)