Thanks for the comments, let's call a consensus. (Sorry for leaving this for a while)
Overall, we can agree with dropping regex support from the fqdn field. The proposal is below. ---- 1. Allow single left-most `*` in the fqdn field 2. Do NOT support regex in the fqdn field 3. Allow `$1` (capturing) support in the tunnel_route field 4. Matching depends on the order of entries (like remap.config) - e.g. Supported: - "*.example.com" - "*" NOT Supported: - "foo[0-9]+.example.com" (regex) - "bar.*.example.net" (`*` in the middle) - "*.bar.*.com" (multiple `*`) - "*.*.baz.com" (multiple `*`) - "baz*.example.net" (partial wildcard) - "*baz.example.net" (partial wildcard) - "b*z.example.net" (partial wildcard) ---- I'll update PR#9736 to follow this. — Masaori On Fri, Jun 23, 2023 at 6:22 AM Brian Neradt <brian.ner...@gmail.com> wrote: > > > > > Susan or Brian, would you describe more about these use cases? > > > > a). * in the middle - "foo.*.com" > > b). multiple * - "*.bar.*.com" > > > > Why it's required or how it's useful? > > > > I agree with we don't need to follow the wildcard certificats > > semantics (RFC6125 6.4.3) in the fqdn field if we want. However, I'm > > wondering why the left-most label wildcard is not enough. > > > > My point is to ensure that we understand that dropping internal wildcard > matching doesn't just limit fqdn item match in the sni.yaml, it also limits > the tunnel_route group feature. As far as I know, no one at Yahoo uses > match groups from within the SNI rather than from the left. So I'm OK > dropping internal wildcard groups as well. > > Brian > > On Thu, Jun 22, 2023 at 2:01 AM Masaori Koshiba <masa...@apache.org> wrote: > > > Susan or Brian, would you describe more about these use cases? > > > > a). * in the middle - "foo.*.com" > > b). multiple * - "*.bar.*.com" > > > > Why it's required or how it's useful? > > > > I agree with we don't need to follow the wildcard certificats > > semantics (RFC6125 6.4.3) in the fqdn field if we want. However, I'm > > wondering why the left-most label wildcard is not enough. > > > > — Masaori > > > > On Tue, Jun 20, 2023 at 9:19 AM James Peach <jpe...@apache.org> wrote: > > > > > > > > > > > > > On 20 Jun 2023, at 8:19 am, Alan Carroll <a...@network-geographics.com> > > wrote: > > > > > > > > Note this could be done the same way as remap - put all the literals > > in one search structure and check for that first. If there's a match, it's > > for a specific line in the file and one need only linear search the regular > > expressions before that line. Anecdotally I've been told you can improve > > remap performance by expanding regular expressions into literals if the set > > of values isn't too large (e.g. "*.swoc.io" in practice means " > > zwoop.swoc.io", "susan.swoc.io" and "amc.swoc.io"). > > > > > > Yup there are various ways to redesign the feature to improve lookup > > performance, but I expect they would all be breaking changes to existing > > config. > > > > > > > -----Original Message----- > > > > From: James Peach <jpe...@apache.org> > > > > Sent: Monday, June 19, 2023 12:09 AM > > > > To: dev@trafficserver.apache.org > > > > Subject: Re: [Discussion/Proposal] Regex support in sni.yaml > > > > > > > > It’s not made explicit in the documentation, but it looks like the > > policy match depends on the order of entries, so you’d have to make a > > linear scan doing regex matches, which makes it more attractive to use > > regex matching to reduce the size of the list. > > > > > > > > -- > "Come to Me, all who are weary and heavy-laden, and I will > give you rest. Take My yoke upon you and learn from Me, for > I am gentle and humble in heart, and you will find rest for > your souls. For My yoke is easy and My burden is light." > > ~ Matthew 11:28-30
