Validating HTTPRoute Rules and Expected Statuses

[pleshakov]

Hi,

I wonder if anyone could clarify the expected behavior for routing rules validation. Thanks!

(1)
When parsing a routing rule, an implementation might see a value of some field that is invalid or not supported by the implementation. For example:

• PathMatchType in HTTPPathMatch is not one of Exact;PathPrefix;RegularExpression
• HTTPRouteFilterType in HTTPRouteFilterType is not one of the values supported by the implementation.

For those cases, the prescribed behavior is

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

However, in GEP-1364, it is mentioned:

HTTPRoute with two rules, one valid and one which specifies a HTTPRequestRedirect filter _and a HTTPURLRewrite filter. Accepted is true, because the valid rule can produce some config in the data plane. We'll need to raise the more specific error condition for an incompatible filter combination as well to make the partial validity clear.

which seems to contradict the behavior above.

So I wonder which way an implementation should implement in case of a mix of valid and invalid rules in an HTTPRoute.

(2)

There are cases when an implementation might not support a whole field, not just some values of it. For example, Method in HTTPRouteMatch. For those cases, is "accepted Condition for the Route to status: False with a Reason of UnsupportedValue" still an appropriate condition?

(3)
for fields that are not bound to any enum. For example, Value in HTTPPathMatch . If an implementation considers its value invalid, is "accepted Condition for the Route to status: False with a Reason of UnsupportedValue" still an appropriate condition? In this case, something like InvalidValue seems more appropriate.

[pleshakov]

this was discussed in Kubernetes Gateway API Slack sig-network-gateway-api https://kubernetes.slack.com/archives/CR0H13KGA/p1675122817360569