You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Title: Router QueryParameterMatcher fails to respect present_match
Description:
When configuring a route matcher to match based on the non-existence of a query_parameter, the route is incorrectly matched when present_match is set to false. This causes traffic to be routed to the incorrect upstream.
Expected Functionality: Based on the documentation, I'd expect that setting present_match: true would return true if the param key exists, and false if the param key does not exist. present_match: false should then return false if the key exists, and true if the param key does not exist.
Repro steps:
All steps are using the example config in the below config section. Overall, this is very easy to reproduce. envoy -c Path/To/example.yaml --service-cluster test_cluster --service-node test_node --log-level debug
The config should return the following responses: /?foo -> foo /?bar -> bar /?foo=1&bar=1 -> Catchall Response! /?anyOtherKey -> Catchall Response!
But running curl against http://localhost:10000 shows a very different story: curl 'http://localhost:10000?foo' -> Catchall Response! -- should return foo curl 'http://localhost:10000?foo=1' -> Catchall Response! -- should return foo curl 'http://localhost:10000?foo=1&bar=1' -> foo -- should return Catchall Response! curl 'http://localhost:10000?bar' -> Catchall Response! -- should return bar curl 'http://localhost:10000?bar=1' -> Catchall Response! -- should return bar curl 'http://localhost:10000?bar=1&foo=1' -> foo -- should return Catchall Response! curl 'http://localhost:10000?anyOtherKey' -> correctly returns Catchall Response!
To really drive this home, comment out lines 19-40 in the example config, so that you are only left with the following 2 matchers:
- match:
prefix: /query_parameters:
- name: foopresent_match: false
- name: barpresent_match: falsedirect_response:
status: 200body:
inline_string: "foo bar, you should never see this"
- match:
prefix: "/"direct_response:
status: 200body:
inline_string: "Catchall Response!"
We should get Catchall Response! for everything even if we pass in foo and bar in our request, but that is not the case:
curl 'http://localhost:10000?foo' -> Catchall - correct curl 'http://localhost:10000?bar' -> Catchall - correct curl 'http://localhost:10000?foo&bar' -> foo bar, you should never see this curl 'http://localhost:10000?bar=1&foo=1' -> foo bar, you should never see this
## Description
The query parameter matcher implementation did not properly implement
`present_match` functionality. While the matcher code exists, it isn't
properly initializing the matcher, causing `present_match` checks to
always fail.
This PR adds the missing functionality and also adds the test coverage
to verify both `present_match: true` and
`present_match: false` behaviors work as expected.
**Fixes:** #37951
---
**Commit Message:** router: fix query parameter present_match support
**Additional Description:** Adds the missing support for `present_match`
while matching query parameters.
**Risk Level:** Low
**Testing:** Added Unit Tests
**Docs Changes:** N/A
**Release Notes:** Added
---------
Signed-off-by: Rohit Agrawal <[email protected]>
Title: Router QueryParameterMatcher fails to respect present_match
Description:
When configuring a route matcher to match based on the non-existence of a query_parameter, the route is incorrectly matched when
present_match
is set tofalse
. This causes traffic to be routed to the incorrect upstream.Expected Functionality: Based on the documentation, I'd expect that setting
present_match: true
would returntrue
if the param key exists, andfalse
if the param key does not exist.present_match: false
should then returnfalse
if the key exists, andtrue
if the param key does not exist.Repro steps:
All steps are using the example config in the below config section. Overall, this is very easy to reproduce.
envoy -c Path/To/example.yaml --service-cluster test_cluster --service-node test_node --log-level debug
The config should return the following responses:
/?foo
->foo
/?bar
->bar
/?foo=1&bar=1
->Catchall Response!
/?anyOtherKey
->Catchall Response!
But running curl against
http://localhost:10000
shows a very different story:curl 'http://localhost:10000?foo'
->Catchall Response!
-- should returnfoo
curl 'http://localhost:10000?foo=1'
->Catchall Response!
-- should returnfoo
curl 'http://localhost:10000?foo=1&bar=1'
->foo
-- should returnCatchall Response!
curl 'http://localhost:10000?bar'
->Catchall Response!
-- should returnbar
curl 'http://localhost:10000?bar=1'
->Catchall Response!
-- should returnbar
curl 'http://localhost:10000?bar=1&foo=1'
->foo
-- should returnCatchall Response!
curl 'http://localhost:10000?anyOtherKey'
-> correctly returnsCatchall Response!
To really drive this home, comment out lines 19-40 in the example config, so that you are only left with the following 2 matchers:
We should get
Catchall Response!
for everything even if we pass infoo
andbar
in our request, but that is not the case:curl 'http://localhost:10000?foo'
->Catchall
- correctcurl 'http://localhost:10000?bar'
->Catchall
- correctcurl 'http://localhost:10000?foo&bar'
->foo bar, you should never see this
curl 'http://localhost:10000?bar=1&foo=1'
->foo bar, you should never see this
Config:
Envoy Info:
Related Issues:
This looks to be the same as #14656, which was
present_match: false
not being respected for HeaderMatch: #14656The text was updated successfully, but these errors were encountered: