[
https://issues.apache.org/jira/browse/CAMEL-24418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino updated CAMEL-24418:
-------------------------------------
Component/s: camel-http-common
camel-vertx-http
camel-netty-http
camel-undertow
Description:
HTTP producer helpers run property-placeholder resolution over message-supplied
endpoint-URI override headers (CamelHttpUri and CamelRestHttpUri):
*createURL family - builds the outbound URL*
* camel-http-common HttpHelper.createURL() line 216 - CamelRestHttpUri (always,
before any bridgeEndpoint check) and CamelHttpUri (when bridgeEndpoint=false).
Backs camel-http HttpProducer and HttpPollingConsumer.
* camel-vertx-http VertxHttpHelper.resolveHttpURI() line 58 - CamelRestHttpUri
(always) and CamelHttpUri (when bridgeEndpoint=false)
* camel-undertow UndertowHelper.createURL() line 56 - CamelRestHttpUri
* camel-netty-http NettyHttpHelper.createURL() line 170 - CamelRestHttpUri
*createMethod family - re-parses the header to extract the query string*
* camel-http HttpMethodHelper.createMethod() line 51 - CamelHttpUri, guarded by
skipControlHeaders which defaults to false
* camel-undertow UndertowHelper.createMethod() line 131 - CamelHttpUri, no guard
* camel-http-common HttpHelper.createMethod() line 336 - CamelHttpUri, no
guard. Public API with no caller in the tree: camel-servlet and camel-jetty
ship no producer, their producer side goes through camel-http HttpProducer ->
HttpMethodHelper. Only reachable from third-party code.
uriString = exchange.getContext().resolvePropertyPlaceholders(uriString);
Property placeholders are a route/configuration-authoring feature; resolving
them in a message header means a {{...}} token that only ever appears in
message content is expanded against the application's property sources. This is
the same inconsistency CAMEL-24282 addressed for toD and enrich, where the fix
was to resolve at build time and treat a per-message {{...}} as a literal.
bridgeEndpoint is not a guard for this. It suppresses the CamelHttpUri override
in createURL, but the createMethod sites read the header regardless, so a route
with bridgeEndpoint=true still resolves placeholders taken from the header.
CamelRestHttpUri is consumed before any bridgeEndpoint check in all four
components.
There is also an effect on ordinary usage: a URL that legitimately contains a
literal {{ currently fails with "RuntimeExchangeException: Cannot resolve
property placeholders with uri: ..." instead of being passed through unchanged.
Proposal: drop the per-message resolution at all sites (the endpoint URI itself
is already resolved at build time). If any use case genuinely depends on it,
gate it behind an explicit opt-in rather than leaving it on by default.
Behaviour change, so main only with an upgrade-guide entry. Note that only
camel-http has the skipControlHeaders option (default false);
camel-http-common, camel-vertx-http, camel-undertow and camel-netty-http have
no equivalent.
Tests should cover, per component, both the override-header path and the
bridgeEndpoint=true path.
was:
Three HTTP producer helpers run property-placeholder resolution over the value
of the CamelHttpUri message header:
* camel-http HttpMethodHelper.createMethod() line 51 - guarded by
skipControlHeaders, which defaults to false
* camel-http-common HttpHelper.createMethod() line 336 - no guard (backs
camel-servlet and camel-jetty)
* camel-undertow UndertowHelper.createMethod() line 131 - no guard
uriString = exchange.getContext().resolvePropertyPlaceholders(uriString);
Property placeholders are a route/configuration-authoring feature; resolving
them in a message header means a {{...}} token that only ever appears in
message content is expanded against the application's property sources. This is
the same inconsistency CAMEL-24282 addressed for toD and enrich, where the fix
was to resolve at build time and treat a per-message {{...}} as a literal.
Proposal: drop the per-message resolution at all three sites (the endpoint URI
itself is already resolved at build time). If any use case genuinely depends on
it, gate it behind an explicit opt-in rather than leaving it on by default.
Behaviour change, so main only with an upgrade-guide entry. Note that
camel-http-common and camel-undertow also lack the skipControlHeaders guard
that camel-http has, so they are the more urgent of the three.
Summary: HTTP producers - do not resolve property placeholders in
message-supplied endpoint-URI override headers (was: camel-http,
camel-http-common, camel-undertow - do not resolve property placeholders in the
CamelHttpUri header value)
> HTTP producers - do not resolve property placeholders in message-supplied
> endpoint-URI override headers
> -------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24418
> URL: https://issues.apache.org/jira/browse/CAMEL-24418
> Project: Camel
> Issue Type: Improvement
> Components: camel-http, camel-http-common, camel-netty-http,
> camel-undertow, camel-vertx-http
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.23.0
>
>
> HTTP producer helpers run property-placeholder resolution over
> message-supplied endpoint-URI override headers (CamelHttpUri and
> CamelRestHttpUri):
> *createURL family - builds the outbound URL*
> * camel-http-common HttpHelper.createURL() line 216 - CamelRestHttpUri
> (always, before any bridgeEndpoint check) and CamelHttpUri (when
> bridgeEndpoint=false). Backs camel-http HttpProducer and HttpPollingConsumer.
> * camel-vertx-http VertxHttpHelper.resolveHttpURI() line 58 -
> CamelRestHttpUri (always) and CamelHttpUri (when bridgeEndpoint=false)
> * camel-undertow UndertowHelper.createURL() line 56 - CamelRestHttpUri
> * camel-netty-http NettyHttpHelper.createURL() line 170 - CamelRestHttpUri
> *createMethod family - re-parses the header to extract the query string*
> * camel-http HttpMethodHelper.createMethod() line 51 - CamelHttpUri, guarded
> by skipControlHeaders which defaults to false
> * camel-undertow UndertowHelper.createMethod() line 131 - CamelHttpUri, no
> guard
> * camel-http-common HttpHelper.createMethod() line 336 - CamelHttpUri, no
> guard. Public API with no caller in the tree: camel-servlet and camel-jetty
> ship no producer, their producer side goes through camel-http HttpProducer ->
> HttpMethodHelper. Only reachable from third-party code.
> uriString = exchange.getContext().resolvePropertyPlaceholders(uriString);
> Property placeholders are a route/configuration-authoring feature; resolving
> them in a message header means a {{...}} token that only ever appears in
> message content is expanded against the application's property sources. This
> is the same inconsistency CAMEL-24282 addressed for toD and enrich, where the
> fix was to resolve at build time and treat a per-message {{...}} as a literal.
> bridgeEndpoint is not a guard for this. It suppresses the CamelHttpUri
> override in createURL, but the createMethod sites read the header regardless,
> so a route with bridgeEndpoint=true still resolves placeholders taken from
> the header. CamelRestHttpUri is consumed before any bridgeEndpoint check in
> all four components.
> There is also an effect on ordinary usage: a URL that legitimately contains a
> literal {{ currently fails with "RuntimeExchangeException: Cannot resolve
> property placeholders with uri: ..." instead of being passed through
> unchanged.
> Proposal: drop the per-message resolution at all sites (the endpoint URI
> itself is already resolved at build time). If any use case genuinely depends
> on it, gate it behind an explicit opt-in rather than leaving it on by default.
> Behaviour change, so main only with an upgrade-guide entry. Note that only
> camel-http has the skipControlHeaders option (default false);
> camel-http-common, camel-vertx-http, camel-undertow and camel-netty-http have
> no equivalent.
> Tests should cover, per component, both the override-header path and the
> bridgeEndpoint=true path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
