-
Notifications
You must be signed in to change notification settings - Fork 493
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
httproute: use lists insteads of maps for HTTPRequestHeaderFilter #681
httproute: use lists insteads of maps for HTTPRequestHeaderFilter #681
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hbagdi 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 |
/cc @robscott |
6019033
to
210b8b5
Compare
apis/v1alpha2/httproute_types.go
Outdated
// HTTPHeader represents an HTTP Header name and value as defined by RFC 7230. | ||
type HTTPHeader struct { | ||
// Name is the name of the HTTP query param to be matched. This must be an | ||
// exact string match. (See |
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.
Why is this an exact string match? Below we mention that header names are case insensitive. I think you may have meant to refer to a different section in the RFC: https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.
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 assume that an exact header match is case-insensitive?
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.
Exact/Regex is how we match the value, the header name has always been exact (with the exception being case sensitivity).
apis/v1alpha2/httproute_types.go
Outdated
@@ -530,6 +530,23 @@ const ( | |||
HTTPRouteFilterExtensionRef HTTPRouteFilterType = "ExtensionRef" | |||
) | |||
|
|||
// HTTPHeader represents an HTTP Header name and value as defined by RFC 7230. | |||
type HTTPHeader struct { | |||
// Name is the name of the HTTP query param to be matched. This must be an |
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.
// Name is the name of the HTTP query param to be matched. This must be an | |
// Name is the name of the HTTP header to be matched. This must be an |
210b8b5
to
78de62e
Compare
One question: |
I don't have a strong opinion on struct embedding here, but don't think it needs to block this PR getting in. What happened to the CRD, was the yaml just inaccurate/unexpected? If so, I think it's worth filing a bug on controller-tools repo with a reference to the command we're using to generate CRDs. |
@hbagdi This looks like it's close, let me know when it's ready for me to take another look. |
55c1ce6
to
6b690f8
Compare
@robscott updated. PTAL. |
Thanks @hbagdi! This LGTM but looks like it needs another |
Co-authored-by: Rob Scott <[email protected]>
6b690f8
to
5250dda
Compare
Fixed, I blazed by a bit too fast. |
Thanks! /lgtm |
What type of PR is this?
/kind api-change
/kind cleanup
What this PR does / why we need it:
This matches the API conventions that prefer lists of named subobjects over maps.
Which issue(s) this PR fixes:
Fixes #658
See #657
Does this PR introduce a user-facing change?: