We have a Camel route on Spring Boot that exposes a REST endpoint like this:

 <rest id="rest-service" path="/">
      <get id="docmanagement" path="/bar/">
        <to uri="direct:docmanagement"/>
      </get>
    </rest>

and then makes a request on an HTTP endpoint, like this:

 <setHeader name="destHost">
        <constant>http://192.168.1.10:8080</constant>
      </setHeader>
      <toD uri="${header.destHost}/foo/?throwExceptionOnFailure=false&amp;bridgeEndpoint=true"/>

Of course, in the real application the header value 'destHost' is not hard-coded, but part of the application logic.

When this application runs, the request gets made, not on '/foo/' as the toD URI suggests, but on '/foo/bar'. Somehow, the context URI of the REST request has been added to the request URI.

This does not happen if the target endoint is hard-coded in the toD URI. The expansion of other header values in the toD URI seems not to be a problem. The same code did not work this way in Fuse 7.

This problem prevents the application being migrated from Fuse 7 to Camel on Spring Boot.

Steps to reproduce
----------------------------

1. Unpack and deploy appcontext2.zip

2. Modify camel-context.xml so that the value of the header destHost is set to a URL of any available HTTP server. It doesn't matter what the server is, and it doesn't have to return a valid response – you just need to be able to see the request being made on it (e.g., using tcpdump).

3. mvn spring-boot run

4. Make a request on the application's REST endpoint, e.g.:

$ curl http://localhost:20001/bar/123

5. Note that the request is made on

/foo/bar/123

when it should be made on

/foo/123

It seems that the use of the header substitution has caused the context path of the REST request to be pushed into the request path of the <toD> HTTP request, even though there is no mention of it in the <toD> URI itself.

6. Modify camel-context.xml, and replace ${header.destHost} with a hard-coded target host. The request is made on

/foo/123/bar/123

as expected.