[
https://issues.apache.org/jira/browse/CAMEL-20620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17831881#comment-17831881
]
Claus Ibsen commented on CAMEL-20620:
-------------------------------------
Before vs After
~/workspace/camel main !3 ❯ curl -i http://0.0.0.0:8080/api/v3/pet/123
✘ INT
HTTP/1.1 200 OK
*: /pet/123
Accept: */*
User-Agent: curl/8.1.2
transfer-encoding: chunked
Content-Type: application/json
{
"pet": "donald the dock"
}
~/workspace/camel main !1 ❯ curl -i http://0.0.0.0:8080/api/v3/pet/123
HTTP/1.1 200 OK
Accept: */*
User-Agent: curl/8.1.2
transfer-encoding: chunked
Content-Type: application/json
{
"pet": "donald the dock"
}
> camel-platform-http-vertx - Path parameters should not leak back to calling
> client
> ----------------------------------------------------------------------------------
>
> Key: CAMEL-20620
> URL: https://issues.apache.org/jira/browse/CAMEL-20620
> Project: Camel
> Issue Type: Improvement
> Components: camel-platform-http-vertx
> Affects Versions: 4.5.0
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.6.0
>
>
> The path parameters from vertx are stored directly as headers, which means
>
> from("platform-http:/greeting/{name}?matchOnUriPrefix=true")
> That the {name} becomes a path parameter with key name, that then is stored
> in the Camel message as a header. This is convenient as you can then grab
> header.name. But the response to the client often would include this value.
> We should make the header filter strategy to skip path parameters, and there
> is also a * as an all catching path parameter that is returned such as
> ~/workspace ❯ curl -i http://0.0.0.0:8080/api/v3/pet/123
>
> 44s
> HTTP/1.1 200 OK
> *: /pet/123
> Accept: */*
> User-Agent: curl/8.1.2
> transfer-encoding: chunked
> Content-Type: application/json
> {
> "pet": "donald the dock"
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
