shashank created CAMEL-26051:
--------------------------------
Summary: camel-undertow, camel-vertx-http - the CamelHttpPath
header is lost or put into the query when the producer endpoint uri has a query
Key: CAMEL-26051
URL: https://issues.apache.org/jira/browse/CAMEL-26051
Project: Camel
Issue Type: Bug
Components: camel-undertow, camel-vertx-http
Reporter: shashank
Assignee: shashank
When the endpoint uri of an undertow or vertx-http producer has a query, the
{{CamelHttpPath}} header is lost or put in the wrong place (main 0c1e85c8631c):
* camel-undertow: {{UndertowHelper.createURL}} appends the path to
{{getHttpURI().toASCIIString()}}, which already ends with {{?query}}
({{http://host/orders?apiVersion=2}} + {{/123}} gives
{{http://host/orders?apiVersion=2/123}}); {{createURI}} then sets the query
again and the path is gone: the request goes to {{/orders?apiVersion=2}}.
* camel-vertx-http: {{VertxHttpHelper.resolveHttpURI}} appends the path the
same way; the path ends up inside the query ({{/orders?apiVersion=2/123}}), or
is dropped when {{CamelHttpQuery}} is set.
camel-http and camel-netty-http insert the path before the query
({{HttpHelper.createURL}} in camel-http-common), so the same route works with
them. The wrong resource is called and nothing is logged.
*Fix*: both helpers insert the path before the {{?}} of the uri, as camel-http
does, with one {{/}} between the endpoint path and the header path. A uri
without a query gives the same result as before; the query handling is
unchanged.
*Upgrade note*: routes that bridge an HTTP consumer (undertow,
platform-http-vertx, servlet, which set {{CamelHttpPath}} from the request) to
these producers now call a different URL:
{{from("undertow:http://0.0.0.0:8080/api?matchOnUriPrefix=true";).to("undertow:http://backend/svc?key=1";)}}
(or {{vertx-http:}} with {{bridgeEndpoint=true}}) sent a request for
{{/api/orders/123}} to {{/svc}} and now sends it to {{/svc/orders/123}}, as
camel-http does. The 4.24 upgrade guide says so; removing the header
({{removeHeader(Exchange.HTTP_PATH)}}) keeps the old target.
*Tests*: new {{UndertowProducerPathHeaderWithEndpointQueryTest}} (7) and
{{VertxHttpPathHeaderWithEndpointQueryTest}} (8) against an in-process JDK
HttpServer that records method, raw path and raw query: path header alone, with
{{CamelHttpQuery}}, POST, trailing slash, no endpoint path, encoded path
(vertx-http), a proxy route behind an undertow consumer with
{{matchOnUriPrefix=true}}. All but the control fail on main (undertow 6 of 7,
vertx-http 7 of 8), e.g. {{expected: <[GET /orders/123 ? apiVersion=2]> but
was: <[GET /orders ? apiVersion=2]>}} (undertow) and {{expected: <[POST
/orders/123/lines ? apiVersion=2]> but was: <[POST /orders ?
apiVersion=2/123/lines]>}} (vertx-http); {{pathHeaderWithoutEndpointQuery}} is
a control that passes on main and with the fix. Unit tests with the fix:
camel-undertow 245 run, camel-vertx-http 116 run, 0 failures.
*Not changed*: the undertow producer writes the request target from the decoded
{{URI.getPath()}}/{{getQuery()}} ({{URISupport.pathAndQueryOf}}), so an encoded
path such as {{/a%20b}} is sent as {{/orders/a b?...}} and the server reads
{{/orders/a}}; independent of the endpoint query, follow-up.
*How it was found*: differential testing of the http producers (camel-http and
camel-netty-http are correct).
*Affected*: main, camel-4.23.x, camel-4.22.x, camel-4.18.x and camel-4.14.x
(the 4.14.9, 4.18.5 and 4.22.2 tags have the same code). Read, not run on those
lines.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
