4.0.10: Retrieve the correct requested URI info path value, indpt of the routing path used to locate the handler #8844
+197
−2
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
…ing path used to locate the handler (helidon-io#8823)
barchetta
added
webserver
backport
oracle-contributor-agreement
bot
added
the
OCA Verified
tjquinno
approved these changes
Jun 5, 2024
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.
Backport of #8823 to 4.0.10
Description
Fixes #8818
The requested URI info logic used to fetch its path value from the incoming request path() return value. This is incorrect; that path is relative to the routing path which selected the handler, and that value has nothing to do with the path the client originally used in its outgoing request (which is what the requested URI feature is intended to reveal).
This PR changes the way the path is derived for the requested URI info to use the path from the prologue which reflects the entire path, not just the portion used in routing within the server.
It also adds a webserver test that makes sure that the path in the requested URI info is correct.
TL;DR - This bug escaped our attention until now because in 4.0.0 the server always invoked some CORS code, whether CORS was enabled or not. Part of that logic retrieved each request's requested URI info. That data is lazily created and cached. The routing that sends requests to CORS has no path prefix, so the serverRequest.path() value during the CORS-triggered handling just happened to include the entire path.
Later, when a user handler retrieved the requested URI info from the request, even though at that moment the request.path() value was relative to the routing, the cached requested URI info with the original CORS-triggered value was returned.
Beginning in 4.0.1 the server stopped invoking CORS logic unless CORS was enabled. Beginning then, the requested URI information retrieved from a user handler that used path-based routing would be incorrect, omitting the part of the path used in the routing rule.
Documentation
None