-
Notifications
You must be signed in to change notification settings - Fork 480
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(HTTPRouteMatcher): implement http method filter #733
feat(HTTPRouteMatcher): implement http method filter #733
Conversation
Welcome @secustor! |
Hi @secustor. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@@ -408,6 +408,10 @@ type HTTPQueryParamMatch struct { | |||
Value string `json:"value"` | |||
} | |||
|
|||
// HTTPMethod describes how to select a HTTP route by matching the HTTP | |||
// method. | |||
type HTTPMethod string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it an appropriate layer to add some kind of enum to allow specific values? E.g. the http methods defined by the HTTP spec.
See https://datatracker.ietf.org/doc/html/rfc7231#section-4 and here https://datatracker.ietf.org/doc/html/rfc5789#section-2
I thinking more about a way to avoid mistakes when defining the paths and only when the config is applied to not route through to the correct service
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively we could reuse the HttpMethod from the genproto
package which is already a dependency. https://pkg.go.dev/google.golang.org/genproto/googleapis/cloud/scheduler/v1#HttpMethod
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of an enum here. I'd also recommend adding enum validation to the field as shown here: https://github.com/kubernetes-sigs/gateway-api/blob/master/apis/v1alpha2/httproute_types.go#L271.
I think I'd prefer defining our own custom types instead of reusing the ones defined in genproto. That will allow us more flexibility in terms of documentation and support levels.
Also appreciate the RFC references by @brunoarueira. Where possible, we like to reference specific RFCs when documenting a feature/field in the comments (example: https://github.com/kubernetes-sigs/gateway-api/blob/master/apis/v1alpha2/httproute_types.go#L342).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW there is an IANA registry for HTTP methods
https://www.iana.org/assignments/http-methods/http-methods.xhtml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the work on this!
/ok-to-test
@@ -408,6 +408,10 @@ type HTTPQueryParamMatch struct { | |||
Value string `json:"value"` | |||
} | |||
|
|||
// HTTPMethod describes how to select a HTTP route by matching the HTTP | |||
// method. | |||
type HTTPMethod string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of an enum here. I'd also recommend adding enum validation to the field as shown here: https://github.com/kubernetes-sigs/gateway-api/blob/master/apis/v1alpha2/httproute_types.go#L271.
I think I'd prefer defining our own custom types instead of reusing the ones defined in genproto. That will allow us more flexibility in terms of documentation and support levels.
Also appreciate the RFC references by @brunoarueira. Where possible, we like to reference specific RFCs when documenting a feature/field in the comments (example: https://github.com/kubernetes-sigs/gateway-api/blob/master/apis/v1alpha2/httproute_types.go#L342).
…num instead of string
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly LGTM, just a few nits.
/cc @bowei @hbagdi @youngnick |
apis/v1alpha2/httproute_types.go
Outdated
HTTPMethodConnect HTTPMethod = "CONNECT" | ||
HTTPMethodOptions HTTPMethod = "OPTIONS" | ||
HTTPMethodTrace HTTPMethod = "TRACE" | ||
HTTPMethodPatch HTTPMethod = "PATCH" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this is a good idea or not.
Custom HTTP methods are a thing, although not common in practice.
For the 99% of the cases, these defined methods will suffice.
If there comes a time when we want to support custom HTTP methods, how can we do so without a breaking change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm not mistaken it is already possible to match the HTTP method via header value match.
In this case we could reference the user to that method.
The alternatives are dropping enum and revert to string or a more complex structure instead of the simple key-value pair.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With :method
pseudo-header (https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.1)
If we go down this route we need to make it explicit in the spec that implementation must accept pseudo-headers though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we go down this route we need to make it explicit in the spec that implementation must accept pseudo-headers though.
We should clarify this regardless. Else implementations will drift in this aspect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, +1 on defining pseudo-header matching. Controllers can map the pseudo header name to the underlying proxy control.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opened up #740 to track this conversation.
My only slight hesitation is that then there are two ways to do the same thing. In this case, that might be okay because custom HTTP methods are not common. Not really sure.
…pport form Core to Extended
Co-authored-by: Harry <[email protected]>
Co-authored-by: Harry <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was about to lgtm this but found a couple of small issues.
Thanks! Will leave LGTM for someone else. /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: robscott, secustor 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:
Approvers can indicate their approval by writing |
@secustor Thank you for your contribution! |
What type of PR is this?
/kind feature
/kind api-change
What this PR does / why we need it:
This PR adds a HTTPMatcher to allow match one or more specific HTTP methods.
If multiple are defined it is defined as logical OR.
Which issue(s) this PR fixes:
Fixes #624
Does this PR introduce a user-facing change?: