> 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 standard way that is restricted but safe and enough for normal use cases. Also, it's currently not even a backward match. "*.example.com" actually matches "foo.example.com.evil.com". I don't like current behavior at all. Too many bad surprises.
I'm fine with having another way of matching if tunnel_route relies on pattern matching with capturing, but I'd want to use real regex instead of the current tunnel_route specific pattern matching. It'd be a disaster if we introduced another key that interprets the pattern string in a different way. -- Masakazu On Thu, Jun 8, 2023 at 5:33 PM Masaori Koshiba <masa...@apache.org> wrote: > 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.g. > ``` > sni: > fqdn: foo([0-9]+).example.com > ``` > > # Long version > > Let's start with history, > > 1. v8.0.0 > > The fqdn field has wildcard support since the sni.yaml was introduced > by v8.0.0. The doc clearly mentions this. > > > This configuration file accepts wildcard entries. To apply an SNI based > setting on all the server names > > with a common upper level domain name, the user needs to enter the fqdn > in the configuration with > > a *. followed by the common domain name. (*.yahoo.com for example). > https://docs.trafficserver.apache.org/admin-guide/files/sni.yaml.en.html > > 2. v9.0.0 > > PR#4630 replaced the implementation to use `pcre_regex`. This change > is released by v9.0.0. It looks like the > main motivation was cleanup and bugfix. But also preparing for full > regex fqdn support in the future. > > 3. Now > > Craig found using `pcre_regex` has a big performance overhead. > (PR#9736 is trying to fix it) > We also noticed several issues. > > a). The current wildcard matching behavior is not following RFC6125 > Section 6.4.3. Masakazu pointed out this on the PR#9767. > > b). The regex support has some restrictions. > - e.g. dot `.` is replaced with `\.` automatically, so you can't > specify dot as "any character" as usual. > > # Proposal > > It looks like allowing regex is making things complicated confusing > people with wildcard support. > I'd propose the below for v10.0.0. > > 1. Allow `*` in the fqdn field as is - e.g. `*.example.com` > 2. Do NOT support regex in the fqdn field - e.g. `foo[0-9]+.example.com` > 3. Allow `$N` (capturing) support in the tunnel_route field as is > > Overall, it's almost roll back the behavior what we have with v8.x. > Unfortunately, this will be an incompatible change with v9.x. > So I'd back to my above question to see the impact. > > Does anybody has complicated regex in your deployment and will be > affected by this change? > > # One more > > Finally, if somebody has real use case of complicated regex and needs > full set of pcre regex, we need to > have another discussion on how to realize it. > > An idea suggested by Masakazu on PR#9767 is adding another dedicated > key. I think it's a good idea > because it aligns with `remap` and `regex_map` in the remap.config and > implementation will be much simpler. > > However, let's start from we really need full regex support in the > sni.yaml or not. > > Thanks, > Masaori >
