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
