;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").
&g
oc.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
> > > Sent: Monday, Jun
e 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
> > Sent: Monday, June 19, 2023 12:09 AM
> > To: dev@trafficser
"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
> Sent: Monday, June 19, 2023 1
: James Peach
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 matc
We have to keep in mind the tunnel_route use case which may use multiple
match groups from various match groups within the sni:
https://docs.trafficserver.apache.org/en/latest/admin-guide/files/sni.yaml.en.html#examples
---
sni:
- fqdn: '*.foo.com'
tunnel_route: '$1.myfoo'
- fqdn: '*.ba
IIUC, the regex is used to match a policy configuration based on the requested
hostname (either inbound or outbound). This means that the matching doesn’t
need to be constrained by wildcard certificate semantics.
It’s not made explicit in the documentation, but it looks like the policy match
de
The use case of a * in the middle of a hostname seems odd to me. TLS
Certificates usually follow DNS practices -- a wildcard would normally be for
subdomains -- *.mail.example.com, but not in the middle of a name -- I don't
think DNS (or most Certificate providers) has a concept that would allow
I believe I was the one that brought in the pcre logic. As I recall we
needed to support * within the name, e.g. bob.*.com. Using simple pcre
seemed the most direct path to correctly support that use case. For simple
pcre's at the time the performance overhead did not seem that onerous.
Perhaps t
> 3. Allow `$N` (capturing) support in the tunnel_route field as is
Does this mean we keep allowing "*.example.com" to be used for "
for.bar.example.com" ? And multiple wildcards as well? Just for
tunnel_route use case? If it's going to be an incompatible change anyway, I
think we should provide a
Hello, ATS Developers
I'd like to hear your thoughts about the regex support in the fqdn
field of sni.yaml.
Recently, we have discussions across PRs (#9736 and #9767), and I have
a question.
# Short version
Does anybody use complicated regex other than `*` in the fqdn filed of
the sni.yaml?
- e
11 matches
Mail list logo
