fix(kuma-cp) ensure HTTP router filter ordering #3082
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The HTTP connection manager filter chain must terminate with the router filter. Each time a filter is added, the configurer needs to be careful to prepend itself to the chain to ensure that the router remains last. This makes it hard to reason about the ordering of filters, since it will be the reverse of the configurer application order, and it makes it unnecessarily tricky to write new configurers. So the easiest approach is for the builder to simply ensure that there is always a router filter appended when it builds the filter chain. Since it is a filter chain builder, it's reasonable for it to know something about filter chain semantics. We might need to do something more complicated if we ever need to set any fields in the router, but for now it seems reasonable to stick with simplicity. Signed-off-by: James Peach <james.peach@konghq.com>
Not really. I made this change because I got burned by adding a new filter, and the current behavior is brain-bending. If the order is wrong, envoy will refuse the payload, so it's tested in that sense. |
jakubdyszkiewicz
approved these changes
Nov 8, 2021
michaelbeaumont
approved these changes
Nov 8, 2021
mergify bot
pushed a commit
that referenced
this pull request
Nov 9, 2021
The HTTP connection manager filter chain must terminate with the router filter. Each time a filter is added, the configurer needs to be careful to prepend itself to the chain to ensure that the router remains last. This makes it hard to reason about the ordering of filters, since it will be the reverse of the configurer application order, and it makes it unnecessarily tricky to write new configurers. So the easiest approach is for the builder to simply ensure that there is always a router filter appended when it builds the filter chain. Since it is a filter chain builder, it's reasonable for it to know something about filter chain semantics. We might need to do something more complicated if we ever need to set any fields in the router, but for now it seems reasonable to stick with simplicity. Signed-off-by: James Peach <james.peach@konghq.com> (cherry picked from commit 11e3b32)
jpeach
added a commit
that referenced
this pull request
Nov 9, 2021
The HTTP connection manager filter chain must terminate with the router filter. Each time a filter is added, the configurer needs to be careful to prepend itself to the chain to ensure that the router remains last. This makes it hard to reason about the ordering of filters, since it will be the reverse of the configurer application order, and it makes it unnecessarily tricky to write new configurers. So the easiest approach is for the builder to simply ensure that there is always a router filter appended when it builds the filter chain. Since it is a filter chain builder, it's reasonable for it to know something about filter chain semantics. We might need to do something more complicated if we ever need to set any fields in the router, but for now it seems reasonable to stick with simplicity. Signed-off-by: James Peach <james.peach@konghq.com> (cherry picked from commit 11e3b32) Co-authored-by: James Peach <james.peach@konghq.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
The HTTP connection manager filter chain must terminate with the router
filter. Each time a filter is added, the configurer needs to be careful
to prepend itself to the chain to ensure that the router remains last.
This makes it hard to reason about the ordering of filters, since it
will be the reverse of the configurer application order, and it makes
it unnecessarily tricky to write new configurers.
So the easiest approach is for the builder to simply ensure that there
is always a router filter appended when it builds the filter chain.
Since it is a filter chain builder, it's reasonable for it to know
something about filter chain semantics. We might need to do something
more complicated if we ever need to set any fields in the router, but
for now it seems reasonable to stick with simplicity.
Full changelog
N/A
Issues resolved
N/A
Documentation
N/A
Testing
Backwards compatibility
backport-to-stablelabel if the code is backwards compatible. Otherwise, list breaking changes.