[
https://issues.apache.org/jira/browse/CAMEL-24577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110643#comment-18110643
]
Federico Mariani commented on CAMEL-24577:
------------------------------------------
PR opened: https://github.com/apache/camel-spring-boot/pull/1932
The rest placeholders are now evaluated against the path Spring matched the
request against (the parsed RequestPath), so path variable headers are
percent-decoded and carry no matrix parameters, in line with the vertx engine.
getRawPath() and therefore Exchange.HTTP_PATH are unchanged, and the
context-path handling of CAMEL-22116/CAMEL-23191 is preserved.
Note: the path is parsed from the request rather than read back from the
attribute Spring caches, because the consumer services the request on its own
executor and the dispatch may already have removed the cached path by then.
_Comment added by Claude Code on behalf of Federico Mariani._
> camel-platform-http-starter - path variable headers are derived from the
> undecoded request URI
> ----------------------------------------------------------------------------------------------
>
> Key: CAMEL-24577
> URL: https://issues.apache.org/jira/browse/CAMEL-24577
> Project: Camel
> Issue Type: Improvement
> Components: camel-platform-http, camel-spring-boot-starters
> Reporter: Andrea Cosentino
> Assignee: Federico Mariani
> Priority: Minor
> Fix For: 4.23.0
>
>
> {{SpringBootPlatformHttpBinding.populateRequestParameters()}} evaluates REST
> path placeholders against
> {{getRawPath(request)}}:
> {code:java}
> String path = getRawPath(request);
> ...
> HttpHelper.evalPlaceholders(message.getHeaders(), path, consumerPath);
> {code}
> and the override returns the undecoded request URI:
> {code:java}
> @Override
> protected String getRawPath(HttpServletRequest request) {
> String uri = request.getRequestURI();
> {code}
> So path-variable headers are built from a value that is still percent-encoded
> and still carries matrix
> parameters, which can differ from the path Spring actually matched the
> request against. The Vert.x engine uses
> the decoded parameters.
> *Why this was deferred from CAMEL-24496*
> The obvious fix - extracting the variables from the decoded {{RequestPath}}
> Spring has already parsed - is wider
> than it looks. The base-class {{getRawPath}} also feeds
> {{Exchange.HTTP_PATH}} for every request, not only
> placeholder evaluation, so changing the override changes a widely used header.
> The override also exists on purpose: CAMEL-22116 added it so Spring Boot
> could supply its own logic, and
> CAMEL-23191 refined it for servlet context-path handling. Any change here has
> to preserve both.
> *Proposal*
> Extract path variables from {{ServletRequestPathUtils.getParsedRequestPath}}
> (or the handler mapping's
> URI-template-variables attribute) for the placeholder evaluation only,
> leaving {{getRawPath}} and therefore
> {{Exchange.HTTP_PATH}} unchanged. Add tests covering a percent-encoded
> segment and a segment carrying a matrix
> parameter, asserting the header value matches what Spring matched.
> Split out of CAMEL-24496, which is resolved.
> ----
> _This issue was drafted by Claude Code on behalf of Andrea Cosentino._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
