zwoop commented on PR #12669:
URL: https://github.com/apache/trafficserver/pull/12669#issuecomment-3715970578
First, I really like the concepts of virtual host configurations, and
eliminating the (IMO weird) ordering requirements that remap.config has today.
That's great!
I have some concerns about the path forward here, and how this essentially
encapsulates the existing "map" directives as strings, rather than YAML'fying
them properly. What I have had in mind is something more inline with the below
(just an example, not a final proposal), where the top-level selector is a
FQDN, and under there we have sub-selectors. Initially, only PATH is such a
sub-selector, but one could in the future easily see adding sub selectors for
e.g. header values, or request method (GET vs POST) etc.
Key here is to avoid putting us in a situation where the YAML has to
dramatically change in future version. Essentially, future proof the virtual
host YAML, such that adding features later (such as method sub-selectors) does
not break existing configurations.
Here's an example of how a currently supported remap.config could be moved
to a new YAML format, putting all the path matches into one single virtual host
YAML config. (Note that the format here allows multiple top level host
selectors, I just have one here).
```
remap:
- maps:
scheme: http
host: example.com
paths:
- path: /foo
origin:
scheme: http
host: foo.example.com
path: /
- path: /bar
origin
scheme: http
host: bar.example.com
path: /some_special_path
plugins:
- name: header_rewrite.so
parameters:
- "/etc/trafficserver/foo.hrw"
- name: cachekey.so
parameters:
- "/etc/trafficserver/foo.cachekey
```
Again, this is not a final proposal / schema, just thinking out loud.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
