router: integrate matching API

api/envoy/config/route/v3/BUILD

@@ -15,5 +15,6 @@ api_proto_package(
         "//envoy/type/tracing/v3:pkg",
         "//envoy/type/v3:pkg",
         "@com_github_cncf_udpa//udpa/annotations:pkg",
+        "@com_github_cncf_udpa//xds/type/matcher/v3:pkg",
     ],
 )

api/envoy/config/route/v3/route_components.proto

@@ -16,6 +16,8 @@ import "google/protobuf/any.proto";
 import "google/protobuf/duration.proto";
 import "google/protobuf/wrappers.proto";
 
+import "xds/type/matcher/v3/matcher.proto";
+
 import "envoy/annotations/deprecation.proto";
 import "udpa/annotations/migrate.proto";
 import "udpa/annotations/status.proto";
@@ -36,7 +38,7 @@ option (udpa.annotations.file_status).package_version_status = ACTIVE;
 // host header. This allows a single listener to service multiple top level domain path trees. Once
 // a virtual host is selected based on the domain, the routes are processed in order to see which
 // upstream cluster to route to or whether to perform a redirect.
-// [#next-free-field: 21]
+// [#next-free-field: 22]
 message VirtualHost {
   option (udpa.annotations.versioning).previous_message_type = "envoy.api.v2.route.VirtualHost";
 
@@ -86,8 +88,13 @@ message VirtualHost {
 
   // The list of routes that will be matched, in order, for incoming requests.
   // The first route that matches will be used.
+  // Only one of this and `matcher` can be specified.
   repeated Route routes = 3;
 
+  // The match tree to use when resolving route actions for incoming requests. Only one of this and `routes`
+  // can be specified.
+  xds.type.matcher.v3.Matcher matcher = 21;
+
   // Specifies the type of TLS enforcement the virtual host expects. If this option is not
   // specified, there is no TLS requirement for the virtual host.
   TlsRequirementType require_tls = 4 [(validate.rules).enum = {defined_only: true}];
@@ -214,7 +221,7 @@ message Route {
   string name = 14;
 
   // Route matching parameters.
-  RouteMatch match = 1 [(validate.rules).message = {required: true}];
+  RouteMatch match = 1;
 
   oneof action {
     option (validate.required) = true;

api/envoy/config/route/v4alpha/BUILD

@@ -13,5 +13,6 @@ api_proto_package(
         "//envoy/type/tracing/v3:pkg",
         "//envoy/type/v3:pkg",
         "@com_github_cncf_udpa//udpa/annotations:pkg",
+        "@com_github_cncf_udpa//xds/type/matcher/v3:pkg",
     ],
 )

api/envoy/config/route/v4alpha/route_components.proto

@@ -16,6 +16,8 @@ import "google/protobuf/any.proto";
 import "google/protobuf/duration.proto";
 import "google/protobuf/wrappers.proto";
 
+import "xds/type/matcher/v3/matcher.proto";
+
 import "udpa/annotations/status.proto";
 import "udpa/annotations/versioning.proto";
 import "validate/validate.proto";
@@ -34,7 +36,7 @@ option (udpa.annotations.file_status).package_version_status = NEXT_MAJOR_VERSIO
 // host header. This allows a single listener to service multiple top level domain path trees. Once
 // a virtual host is selected based on the domain, the routes are processed in order to see which
 // upstream cluster to route to or whether to perform a redirect.
-// [#next-free-field: 21]
+// [#next-free-field: 22]
 message VirtualHost {
   option (udpa.annotations.versioning).previous_message_type = "envoy.config.route.v3.VirtualHost";
 
@@ -84,8 +86,13 @@ message VirtualHost {
 
   // The list of routes that will be matched, in order, for incoming requests.
   // The first route that matches will be used.
+  // Only one of this and `matcher` can be specified.
   repeated Route routes = 3;
 
+  // The match tree to use when resolving route actions for incoming requests. Only one of this and `routes`
+  // can be specified.
+  xds.type.matcher.v3.Matcher matcher = 21;
+
   // Specifies the type of TLS enforcement the virtual host expects. If this option is not
   // specified, there is no TLS requirement for the virtual host.
   TlsRequirementType require_tls = 4 [(validate.rules).enum = {defined_only: true}];
@@ -212,7 +219,7 @@ message Route {
   string name = 14;
 
   // Route matching parameters.
-  RouteMatch match = 1 [(validate.rules).message = {required: true}];
+  RouteMatch match = 1;
 
   oneof action {
     option (validate.required) = true;

docs/root/intro/arch_overview/advanced/matching/matching_api.rst

@@ -16,6 +16,9 @@ better performance than the linear list matching as seen in Envoy's HTTP routing
 use of extension points to make it easy to extend to different inputs based on protocol or
 environment data as well as custom sublinear matchers and direct matchers.
 
+Filter Integration
+##################
+
 Within supported environments (currently only HTTP filters), a wrapper proto can be used to
 instantiate a matching filter associated with the wrapped structure:
 
@@ -28,7 +31,7 @@ The above example wraps a HTTP filter (the
 allowing us to define a match tree to be evaluated in conjunction with evaluation of the wrapped
 filter. Prior to data being made available to the filter, it will be provided to the match tree,
 which will then attempt to evaluate the matching rules with the provided data, triggering an
-action if match evaluation completes in an action.
+action if match evaluation results in an action.
 
 In the above example, we are specifying that we want to match on the incoming request header
 ``some-header`` by setting the ``input`` to
@@ -54,7 +57,7 @@ the filter if ``some-header: skip_filter`` is present and ``second-header`` is s
 .. _arch_overview_matching_api_iteration_impact:
 
 HTTP Filter Iteration Impact
-============================
+****************************
 
 The above example only demonstrates matching on request headers, which ends up being the simplest
 case due to it happening before the associated filter receives any data. Matching on other HTTP
@@ -80,8 +83,15 @@ client will receive an invalid response back from Envoy. If the skip action was
 trailers, the same gRPC-Web filter would consume all the data but never write it back out (as this
 happens when it sees the trailers), resulting in a gRPC-Web response with an empty body.
 
+HTTP Routing Integration
+########################
+
+The matching API can be used with HTTP routing, by specifying a match tree as part of the virtual host
+and specifying a Route as the resulting action. See examples in the above sections for how the match
+tree can be configured.
+
 Match Tree Validation
-=====================
+#####################
 
 As the match tree structure is very flexible, some filters might need to impose additional restrictions
 on what kind of match trees can be used. This system is somewhat inflexible at the moment, only supporting
@@ -91,7 +101,7 @@ will fail during configuration load, reporting back which data input was invalid
 
 This is done for example to limit the issues talked about in
 :ref:`the above section <arch_overview_matching_api_iteration_impact>` or to help users understand in what
-context a match tree can be used for a specific filter. Due to the limitations of the validations framework
+context a match tree can be used for a specific filter. Due to the limitations of the validation framework
 at the current time, it is not used for all filters.
 
 For HTTP filters, the restrictions are specified by the filter implementation, so consult the individual

docs/root/intro/arch_overview/http/http_routing.rst

@@ -192,3 +192,59 @@ upon configuration load and cache the contents.
 
 If **response_headers_to_add** has been set for the Route or the enclosing Virtual Host,
 Envoy will include the specified headers in the direct HTTP response.
+
+Routing Via Generic Matching
+----------------------------
+
+Envoy recently added support for utilzing a :ref:`generic match tree <envoy_v3_api_msg_config>` to
+specify the route table. This is a more expressive matching engine than the original one, allowing
+for sublinear matching on arbitrary headers (unlike the original matching engine which could only
+do this for :authority in some cases).
+
+To use the generic matching tree, specify a ref:`matcher <fds>` on a virtual host with a RouteAction action:
+
+```
+  matcher:
+    "@type": type.googleapis.com/envoy.config.common.matcher.v3.Matcher
+    matcher_tree:
+      input:
+        name: request-headers
+        typed_config:
+          "@type": type.googleapis.com/envoy.type.matcher.v3.HttpRequestHeaderMatchInput
+          header_name: :path
+      exact_match_map:
+        map:
+          "/new_endpoint/foo":
+            action:
+              name: route
+              typed_config:
+                "@type": type.googleapis.com/envoy.config.route.v3.Route
+                route:
+                  cluster: cluster_foo
+                request_headers_to_add:
+                - header:
+                    key: x-route-header
+                    value: new-value
+          "/new_endpoint/bar":
+            action:
+              name: route
+              typed_config:
+                "@type": type.googleapis.com/envoy.config.route.v3.Route
+                route:
+                  cluster: cluster_bar
+                request_headers_to_add:
+                - header:
+                    key: x-route-header
+                    value: new-value
+```
+
+This allows resolving the same Route proto message used for the `routes`-based routing using the additional
+matching flexibility provided by the generic matching framework.
+
+The only inputs supported are request headers (via `envoy.type.matcher.v3.HttpRequestHeaderMatchInput`). See
+the docs for the :ref:`matching API <arch_overview_matching_api>` for more information about the API as a whole.
+
+Known limiations:
+- The matching tree doesn't work with path rewrites. This is because this relies on rewriting the matched path
+  against the rewrite rule, but the matching engine allows matching on :path in many different ways, making it
+  ambiguous which path match should be used when rewriting.

source/common/matcher/matcher.h

@@ -72,9 +72,9 @@ template <class DataType> using DataInputFactoryCb = std::function<DataInputPtr<
 template <class DataType, class ActionFactoryContext> class MatchTreeFactory {
 public:
   MatchTreeFactory(ActionFactoryContext& context,
-                   Server::Configuration::ServerFactoryContext& server_factory_context,
+                   Server::Configuration::ServerFactoryContext& factory_context,
                    MatchTreeValidationVisitor<DataType>& validation_visitor)
-      : action_factory_context_(context), server_factory_context_(server_factory_context),
+      : action_factory_context_(context), server_factory_context_(factory_context),
         validation_visitor_(validation_visitor) {}
 
   // TODO(snowp): Remove this type parameter once we only have one Matcher proto.

source/common/router/BUILD

@@ -61,9 +61,12 @@ envoy_cc_library(
         "//source/common/http:headers_lib",
         "//source/common/http:path_utility_lib",
         "//source/common/http:utility_lib",
+        "//source/common/http/matching:data_impl_lib",
+        "//source/common/matcher:matcher_lib",
         "//source/common/protobuf:utility_lib",
         "//source/common/tracing:http_tracer_lib",
         "//source/extensions/filters/http/common:utility_lib",
+        "@envoy_api//envoy/config/common/matcher/v3:pkg_cc_proto",
         "@envoy_api//envoy/config/core/v3:pkg_cc_proto",
         "@envoy_api//envoy/config/route/v3:pkg_cc_proto",
         "@envoy_api//envoy/type/matcher/v3:pkg_cc_proto",