@@ -1358,3 +1358,141 @@ Kind regards,
13581358An HTML attachment was scrubbed...
13591359URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20260420/b4759344/attachment.htm>
13601360
1361+ From rousskov at measurement-factory.com Mon Apr 20 14:14:11 2026
1362+ From: rousskov at measurement-factory.com (Alex Rousskov)
1363+ Date: Mon, 20 Apr 2026 10:14:11 -0400
1364+ Subject: [squid-dev] NO_SPECIAL_HANDLING define for HTTP methods
1365+ In-Reply-To: <CA+Y8hcMtE4VTDJ1SAxmTgkmuTtZRKCjD0YCE9Gmv7z9zMZMHag@mail.gmail.com>
1366+ References: <CA+Y8hcMtE4VTDJ1SAxmTgkmuTtZRKCjD0YCE9Gmv7z9zMZMHag@mail.gmail.com>
1367+ Message-ID: <8e930040-e70c-4d8a-95ca-c1a29c709980@measurement-factory.com>
1368+
1369+ On 2026-04-19 17:35, Francesco Chemolli wrote:
1370+
1371+ > I stumbled upon src/http/MethodType.h and the fact that a lot of
1372+ > methods are hidden behind a NO_SPECIAL_HANDLING preprocessor macro.
1373+ > Does anyone have any memory about what the purpose of that exclusion?
1374+
1375+ I can only speculate why those "hidden" methods were added, and I do not
1376+ want to do that.
1377+
1378+ We should remove those "hidden" methods (and the macro) -- that enum is
1379+ not the right place to enumerate the names of various methods (and their
1380+ specs) that Squid never uses by name because Squid does not handle them
1381+ "specially".
1382+
1383+ Alex.
1384+
1385+
1386+ From rousskov at measurement-factory.com Mon Apr 20 17:37:58 2026
1387+ From: rousskov at measurement-factory.com (Alex Rousskov)
1388+ Date: Mon, 20 Apr 2026 13:37:58 -0400
1389+ Subject: [squid-dev] Issue with acl note (without -m) splitting helper
1390+ tokens containing commas
1391+ In-Reply-To: <CADJd0Y2eRvv9dtZKRFgzQk3bRZJCXvzxkYCAzSgqw-fweGd7MA@mail.gmail.com>
1392+ References: <CADJd0Y1M=Z9VY6spPMcR1SoFgrfDKuWdbWM=6=A=CEoS+oi+Og@mail.gmail.com>
1393+ <CADJd0Y2eRvv9dtZKRFgzQk3bRZJCXvzxkYCAzSgqw-fweGd7MA@mail.gmail.com>
1394+ Message-ID: <5c838da1-984d-4089-af25-d18a833582b6@measurement-factory.com>
1395+
1396+ On 2026-04-20 05:50, Andrey K wrote:
1397+
1398+ > I think I?ve come up with a way to minimize the impact of removing the
1399+ > default comma delimiter on existing Squid setups.
1400+ > We can introduce a new build-time configuration option,
1401+ > --with-annotation-values-default-delimiter, so that users who rely on
1402+ > the comma separator can rebuild Squid with
1403+ > --with-annotation-values-default-delimiter=,.
1404+
1405+ Please do not introduce ./configure options for functionality that can
1406+ be configured by more dynamic means (e.g., via squid.conf).
1407+
1408+
1409+ > While this approach is more conceptually sound and aligns better with
1410+ > the documentation, I am concerned that many users rely on
1411+ > vendor-provided binary packages and won't have the opportunity to
1412+ > recompile Squid from source.
1413+
1414+ Your concern is valid, and there are other reasons we should avoid
1415+ avoidable ./configure options.
1416+
1417+ I will respond to your other suggestions separately.
1418+
1419+
1420+ Thank you,
1421+
1422+ Alex.
1423+
1424+
1425+ > ??, 17 ???. 2026??. ? 16:08, Andrey K <ankor2023 at gmail.com
1426+ > <mailto:ankor2023 at gmail.com>>:
1427+ >
1428+ > Hello,
1429+ >
1430+ > While working with annotations, I?ve noticed an inconsistency in how
1431+ > acl note (without the -m option) handles tokens received from
1432+ > helpers when they contain a comma.
1433+ >
1434+ > According to the documentation, an ACL like this:
1435+ > ? ? acl staff note group Staff:accountants,lawyers,security
1436+ > should match a helper response such as:
1437+ > ? ? group="Staff:accountants,lawyers,security"
1438+ >
1439+ > However, this is not the case. The helper's response is split into
1440+ > tokens using a comma as the default delimiter. As a result, only
1441+ > ACLs like the following will match:
1442+ > ? ? acl staff note group lawyers
1443+ >
1444+ > This behavior occurs because in Acl::NoteCheck::matchNotes(), a
1445+ > comma is passed as the default delimiter to the expandListEntries()
1446+ > function:
1447+ > ? ? bool
1448+ > ? ? ACLNoteStrategy::matchNotes(ACLData<MatchType> *noteData, const
1449+ > NotePairs *note) const
1450+ > ? ? {
1451+ > ? ? ? ? const NotePairs::Entries &entries =
1452+ > note->expandListEntries(&delimiters.value);
1453+ > ? ? ? ? for (auto e: entries)
1454+ > ? ? ? ? ? ? if (noteData->match(e.getRaw()))
1455+ > ? ? ? ? ? ? ? ? return true;
1456+ > ? ? ? ? return false;
1457+ > ? ? }
1458+ >
1459+ > After reviewing the source code, I found that the comma is added in
1460+ > src/acl/Note.h within the AnnotationCheck class constructor:
1461+ > ? ? AnnotationCheck(): delimiters(CharacterSet("__FILE__", ",")) {}
1462+ >
1463+ > Using a comma as the default delimiter makes it difficult to
1464+ > validate full tokens that may naturally contain commas.
1465+ >
1466+ > I would like to propose two changes:
1467+ > 1. Removing the default comma delimiter.
1468+ > I am prepared to submit a simple PR to exclude this comma to fix the
1469+ > incorrect matching of strings containing commas.
1470+ > However, I realize this might be a breaking change for users who
1471+ > currently rely on this implicit splitting behavior.
1472+ >
1473+ > 2. Supporting custom delimiters in helper responses.
1474+ > I also propose a PR to support a format where tag values can be
1475+ > passed as a list with a custom delimiter:
1476+ > ? ? <key>=<delimiter>"<value1><delimiter><value2>..."
1477+ > For example:
1478+ > ? ? group=,"group1,group2,group3"
1479+ > ? ? clt_con_tag=;"tag1;tag2;tag3"
1480+ > In this PR, the helper response would be tokenized based on the
1481+ > specified custom delimiter, while still supporting delimiter
1482+ > escaping with a backslash (\).
1483+ > In this scenario, having a hardcoded comma as the default delimiter
1484+ > in the AnnotationCheck class would also create complications.
1485+ >
1486+ > I would appreciate your thoughts on these proposals and whether they
1487+ > align with the project's roadmap.
1488+ >
1489+ > Kind regards,
1490+ > ? ? Ankor.
1491+ >
1492+ >
1493+ > _______________________________________________
1494+ > squid-dev mailing list
1495+ > squid-dev at lists.squid-cache.org
1496+ > https://lists.squid-cache.org/listinfo/squid-dev
1497+
1498+
0 commit comments