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
I believe I found a possible bug, or at least a not intuitive behavior when ReplacePath rule is preceded by PathPrefixStrip
Basically because PathPrefixStrip is a Matcher, but also happens to be a Modifier as well, when combined with ReplacePath, like PathPrefixStrip:/management;ReplacePath:/health, due to the order in which the Modifiers are applied in server.go, the above rule-set does not behave as expected.
While one would expect that we match the request to /management url, strip the /management prefix, followed by a replace with /health. This is NOT, however, what is happening. The matcher does the job correctly and matches the request on /management and sends it down the correct Handler chain, but that's when the issue creeps in.
Because ReplacePath Modifier gets executed first in the Handler chain, it replaces /management with /health, and when StripPrefix Modifier gets called, it is trying to match the Path with /management prefix, and obviously failing to do so, thus returning 404-Not Found.
If the Rule is written as PathPrefixStrip:/management;ReplacePath:/management/health, then everything works, but the actual invocation URL Path ends up being NOT /management/health but /health, thus making this configuration be misleading.
I believe I found a possible bug, or at least a not intuitive behavior when ReplacePath rule is preceded by PathPrefixStrip
Basically because PathPrefixStrip is a Matcher, but also happens to be a Modifier as well, when combined with ReplacePath, like PathPrefixStrip:/management;ReplacePath:/health, due to the order in which the Modifiers are applied in server.go, the above rule-set does not behave as expected.
While one would expect that we match the request to /management url, strip the /management prefix, followed by a replace with /health. This is NOT, however, what is happening. The matcher does the job correctly and matches the request on /management and sends it down the correct Handler chain, but that's when the issue creeps in.
Because ReplacePath Modifier gets executed first in the Handler chain, it replaces /management with /health, and when StripPrefix Modifier gets called, it is trying to match the Path with /management prefix, and obviously failing to do so, thus returning 404-Not Found.
If the Rule is written as PathPrefixStrip:/management;ReplacePath:/management/health, then everything works, but the actual invocation URL Path ends up being NOT /management/health but /health, thus making this configuration be misleading.
This issue relates to #1374
The text was updated successfully, but these errors were encountered: