Tightening GRPCRoute validation, fixing gaps in HTTPRoute and Gateway webhook validation

[robscott]

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
This PR started with a single goal - address feedback from #1538 by filling in missing GRPCRoute webhook validation. As I started that process, I realized that we'd introduced some significant gaps between v1a2 and v1b1 validation among the resources that had graduated. This also updates that logic to share code where possible and provide a consistent experience.

Does this PR introduce a user-facing change?:

- GRPCRoute: Regex validation for Method and Service has been tightened to match GRPC spec.
- GRPCRoute: Webhook validation of GRPCRoute has been expanded to closely match HTTPRoute validation.
- HTTPRoute and Gateway: Gaps between webhook validation for v1alpha2 and v1beta1 have been closed.
- HTTPRoute: Validating webhook now ensures that Exact and Prefix path match values can now only include valid path values per RFC-3986. (RegularExpression path matches are not affected by this change).

[youngnick]

LGTM once the existing comments are resolved, although I'm still in favor of extra protection on top of the CRD validation in the webhook for paths and methods.

[robscott]

Adding a hold since I want to wait for a couple reviews on this one.

/hold

[youngnick]

/lgtm

[gyohuangxin]

There are two different methods to handle return errs in webhook validation now.

1. If the condition matches, return errors immediately to avoid returning too many errors :
   

   gateway-api/apis/v1beta1/validation/common.go

   Lines 52 to 54 in df03bd5

   	if len(s[0]) == 0 || len(*targetSection) == 0 {
   	errs = append(errs, field.Required(path.Child("parentRefs"), "sectionNames must be specified when more than one parentRef refers to the same parent"))
   	return errs

2. Return errors at the end of the function like your code.

I think we should unify the ways to return errors to users, returning all errors or returning the first error. What do you think?

[robscott]

If needed we can file a follow up for this since it doesn't feel directly tied to this PR. In general I think we should return as many errors as we reasonably can so users don't have take multiple iterations to fix a set of problems. I think that largely matches what we're already doing, but your specific example may be an example where it makes sense to return both errors.

[gyohuangxin]

Please remove the blank line.

[robscott]

I think this may just be a preference thing but I actually prefer a bit more whitespace like this. In this case, this func is copied almost verbatim from HTTPRoute and maintains the same spacing as the original function:

gateway-api/apis/v1beta1/validation/httproute.go

Lines 180 to 196 in df03bd5

	func validateHTTPHeaderMatches(matches []gatewayv1b1.HTTPHeaderMatch, path *field.Path) field.ErrorList {
	var errs field.ErrorList
	counts := map[string]int{}
	for _, match := range matches {
	// Header names are case-insensitive.
	counts[strings.ToLower(string(match.Name))]++
	}
	for name, count := range counts {
	if count > 1 {
	errs = append(errs, field.Invalid(path, http.CanonicalHeaderKey(name), "cannot match the same header multiple times in the same rule"))
	}
	}
	return errs
	}

If you feel strongly about where we should have new lines in our functions it may be worth a follow up issue to discuss more.

[robscott]

Still need one more LGTM, but removing hold since I think we have consensus on the changes here.

/hold cancel

[shaneutt]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gnossen, robscott, shaneutt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [robscott,shaneutt]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jackstine]

I had a question about the validation here