Support RegularExpression as a HTTPRoute HeaderMatchType

[simonfelding]

Description:
The HTTPRoute resource allows for defining two HeaderMatchType: Exact (Core) and RegularExpression (Implementation specific).

Envoy Gateway only supports the Exact match type, and it would be really nice to have regex support.

I want to use it to make routing decisions based on a partial header match - like so:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: grafana
spec:
  rules:
  - matches:
    - header:
        type: RegularExpression
        name: "Host"
        value: "^grafana"
    backendRefs:
    - name: grafana
      port: 80

This would be really useful, as spec.hostnames only supports doing a full FQDN match, or a wildcard subdomain. I want to match like "grafana.*" so I can better repurpose my HTTPRoutes for a general setup, without having to use complex variable substitution and whatnot.

I believe it should be somewhat trivial to implement as it is already a feature in Envoy

[arkodg]

pretty sure this is supported

gateway/internal/xds/translator/route.go

Line 153 in c4bc5b2

} else if pathMatch.SafeRegex != nil {

can you try name: ":authority" https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto

[arkodg]

if the API doesnt support http2 header (that start with :) , another workaround is to use early header mutation to insert a header and then use it here https://gateway.envoyproxy.io/docs/tasks/traffic/http-request-headers/#early-header-modification (value can be set to %REQ(:AUTHORITY)%)

[simonfelding]

pretty sure this is supported

Thanks so much for both those links! You're right, it does seem like it is supported and totally doable! I'll try it out later and report back. I think the early header modification would make sense.

You seem very knowledgeable - could you maybe point me in some direction where I can get a deeper understanding of Envoy? 😄

I have a discussion going on over at the Gateway API SIG. Do you think it would make sense to solve my fundamental problem (allowing wildcard suffix in hostname, such as grafana.*) at the API and Envoy level by patching the file mentioned there?

[arkodg]

there are some free courses in Envoy here https://www.envoyproxy.io/training

looks like you're an expert navigator of Github :) envoyproxy/envoy#38607 is a well written issue, hope it get accepted, good luck !
If that capability is in, then the CEL validation for the hostnames can be loosened like how your PR in Gateway API does it, and it should be possible in an easier way. It makes the logic of hostname intersection a litter harder to compute for implementations, but still possible.