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.
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