HeaderMatchType(s) too restrictive?

[mikhail-aws]

Intro
Description for context https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HeaderMatchType

HeaderMatchType specifies the semantics of how HTTP header values should be compared. Valid HeaderMatchType values, along with their conformance levels, are:

“Exact” - Core
“RegularExpression” - Implementation Specific

Note that values may be added to this enum, implementations must ensure that unknown values will not cause a crash.

Unknown values here must result in the implementation setting the Accepted Condition for the Route to status: False, with a Reason of UnsupportedValue.

Problem
Should we relax validation on HeaderMatchType? I think Exact and RegularExpression is reasonable baseline. But at the same time implementation might provide more options beyond these 2.

We are implementing Gateway-API for AWS Lattice, and lattice supports Contains and Prefix options for HeaderTypes (ref). So now we have a dilemma how to approach this. Either create a very limited RegularExpression that will mimic Prefix and Contains, or CRDs. Both do not sound right.

Are there other options?

My thinking is that HeaderMatchType should not be restricted to these 2 options. The rule should be "At Least Exact and RegularExpression", but not "Only Exact and RegularExpression". Which also fits into second part of the documentation, we should anticipate new and Unknown types:

Note that values may be added to this enum, implementations must ensure that unknown values will not cause a crash.

Unknown values here must result in the implementation setting the Accepted Condition for the Route to status: False, with a Reason of UnsupportedValue.

[tokers]

Either create a very limited RegularExpression that will mimic Prefix and Contains, or CRDs. Both do not sound right.

Since the regular expression can mimic the prefix and contains way, what's your concern about using the regular expression? Performance?

[mikhail-aws]

Right now we dont support headers regex for various reasons. Contains, Prefix, Exact cover lots of use-cases without need for regex.

[robscott]

With every match type we add, we try to ensure there's a path to portability. For example, if a majority of envoy, haproxy, and nginx could support a match type and there was some kind of evidence of widespread usage of those features, that would be a good signal towards inclusion in the API.

I haven't looked into these specific match types, but if they meet the criteria I mentioned above, I'd say it would be worth a small GEP to add these to the API.

[robscott]

Thanks @mikhail-aws! That sounds promising. @pleshakov and/or @brianehlert can you chime in on what NGINX is capable of here?

[tokers]

Em, this let me remember the "match expression" in APISIX where people can specify a left value, an operator and right value to compose an expression. The operator can be:

• Equal
• NotEqual
• GreaterThan
• LessThan
• Contains
• Exist
• ......

This is flexible but not all of the implementations support.

[pleshakov]

@robscott

NGINX without any extensions only supports exact or regex match (details: map directive, if directive)

The we implemented advanced routing rules matching like headers in our NGINX-based implementation is using njs, which allows running JavaScript code as part of request processing. Considering that, String matching like prefix, suffix, contains can be supported. (details -- https://nginx.org/en/docs/njs/compatibility.html String prototype methods)

[robscott]

Thanks @tokers and @pleshakov! It looks like a lot of implementations could support contains, prefix and suffix matches, even if in some cases they were implemented by regex behind the scenes. @mikhail-aws it seems like this could merit a small GEP that both proposed some more common + portable match types as well as a domain-prefixed match type for implementation-specific matches (as @youngnick suggested below). Let us know if we can help with anything.

[mikhail-aws]

I will try to find time in next few weeks to get familiar with contribution guideline and GEP scope. If there is another similar size GEP that I can learn from that would be great.

[youngnick]

I agree that it would be better to make this more extensible - but if we're going to allow other values, I think we should use the domain-prefixed string pattern, and reserve barewords for Gateway API reserved words.

So, Exact and RegularExpression are reserved barewords, while implementation.domain.io/MatchType would be a domain-prefixed string, and would be allowed at Implementation Specific support.

All other barewords would be reserved for future expansion - with the intent that implementation.domain.io/MatchType, if supported across multiple implementations, could eventually become an Extended MatchType constant in Gateway API itself, with clear conformance tests to ensure portability.