Add first-class cookie matcher for HTTP routes (align with proposed Gateway API cookie match)

[zhaohuabing]

Title: Add first-class cookie matcher for HTTP routes (align with proposed Gateway API cookie match)

Description: Gateway API is proposing a structured cookie match (kubernetes-sigs/gateway-api#2891); Envoy Gateway tracks it in envoyproxy/gateway#6199. Envoy today can matche the raw cookie header via HeaderMatcher (exact/prefix/suffix/regex/etc.), forcing brittle regex/substring parsing.

Problem: Envoy lacks a native mechanism for matching a specific cookie key/value. This requires parsing the full Cookie header, which impacts performance and makes the semantics less clear.

Request:

Add a cookie-specific matcher in the HTTP route match: API would likely be a new cookie_match with cookie name plus existing match types (exact/prefix/suffix/regex/present/string/range, invert).

[phlax]

cc @mattklein123 @agrawroh @kyessenov

[agrawroh]

I think it might make more sense to write a custom xDS matcher for matching cookies key/value(s) and use it for route matching.

@kyessenov What do you think?

[wbpcode]

I think both Envoy Gateway and Istio didn't provide a good support for the xDS matcher for route? It would be better to take the factor into account.

[zhaohuabing]

I hope cookie matching can be supported in both the routes and matcher APIs.

As @wbpcode said, both Envoy Gateway and Istio are currently using the routes for routing, it would take some time to move to the matcher approach, as it's a non-trival change.

It seems that Matcher doesn't provide feature parity as config.route.v3.Route? There is no way to configure the route-level settings, such as typed_per_filter_config, response_header_to_add.

[agrawroh]

@wbpcode Okay, if Istio doesn't support route matchers well today then it make sense to add a matcher directly to the route instead.

@zhaohuabing I haven't looked too closely, if these are not supported then we should definitely add support for it [Ref].

[zhaohuabing]

Hi @agrawroh It seems that my previous comment about the missing features was wrong. From the link that you shared, the action of the matcher API is config.route.v3.Route(I thought it was config.route.v3.RouteAction), and a new cookie matcher can work with existing route match like this example? cc @wbpcode

                matcher_tree:
                  input:
                    name: request-cookie
                    typed_config:
                      "@type": type.googleapis.com/envoy.type.matcher.v3.HttpRequestCookieMatchInput
                      cookie_name: cookie1 
                  prefix_match_map:
                    map:
                      "foo":
                        action:
                          name: route_foo
                          typed_config:
                            "@type": type.googleapis.com/envoy.config.route.v3.Route
                            match:
                              path: "/foo"
                            route:
                              cluster: cluster_1
                      "bar":
                        action:
                          name: route_foo
                          typed_config:
                            "@type": type.googleapis.com/envoy.config.route.v3.Route
                            match:
                              path: "/bar"
                            route:
                              cluster: cluster_2

[wbpcode]

@zhaohuabing, yeah, it's could works. But do the Envoy Gateway/Istio now support the generic matcher tree for route?

[zhaohuabing]

No, not yet. Ideally, we can support both in Envoy. Envoy Gateway may migrate Route to the matcher API in the future to enable more flexible and better-performing matching.