-
Notifications
You must be signed in to change notification settings - Fork 223
Description
Setup:
dapr-sdk: 1.14.0
dapr runtime: 1.15.4
Facing issue with leading slash in url.While it worked with earlier SDK versions, it's failing with new sdk 1.14.0.
We observed that including a leading slash (/) in the endpoint causes the call to fail with an HTTP 400 error.
Example:
When ServiceA invokes ServiceB with the endpoint defined as:
udirBaseURI: "/udir/translate" → The call fails with HTTP 400.
udirBaseURI: "udir/translate" → The call succeeds.
Please note this is observed when side is mocked and using dapr sdk as is for service to service invocation.
Another observation is as follows
Analysis:
Dapr has recently changed the implementation of service invocation replacing OkHttpClient with Java's HttpClient. Please refer to the commit: cdda128
The newly added createQuery method tries to encode the query parameters before trying to create java URI
eg uri=/serviceB-point/serviceB-address/fetch-by-id gets encoded to uri=%2FserviceB-point%2FserviceB-address%2Ffetch-by-id gets
Java URI creation, apparently encodes the query parameters again before sending the http request
eg uri=%2FserviceB-point%2FserviceB-address%2Fetch-by-id gets encoded again to uri=%252FserviceB-point%252FserviceB-address%252Ffetch-by-id
On the server side, Spring decodes the query parameter just once which is causing the problem.
eg uri=%252F2FserviceB-point%252F2FserviceB-address%252Ffetch-by-id gets decoded to uri=%2FserviceB-point%2FserviceB-address%2Ffetch-by-id which should have been /serviceB-point/serviceB-address/fetch-by-id
The impact is also seen in path parameter scenarios.
Activity
vikram-mahadevkar commentedon Apr 19, 2025
Please find attached sample spring boot project which contains two test cases testInvokeSayHelloWithoutLeadingSlash() and testInvokeSayHelloWithLeadingSlash().
Both test cases are successful with Dapr SDK version 1.13.3 as expected. (please make changes in build.gradle to switch SDK versions)
But test case testInvokeSayHelloWithLeadingSlash() fails with Dapr SDK version 1.14.0.
Please let us know in case any other details are needed.
wiremock-test-case.zip
artur-ciocanu commentedon Apr 19, 2025
Thanks for the repro scenario we will take a look and get back to you.
artur-ciocanu commentedon Apr 21, 2025
@rahulpoddar-fyndna thanks a lot for a detailed description, I was wondering if you could share an example related to incorrect encoding on parameters. There is a fix #1320, but I want to double check that the way we handle parameter encoding in correct, so an example would really help.
Thank you.
rdosifyndna commentedon Apr 22, 2025
@artur-ciocanu @rahulpoddar-fyndna
Sharing an example of code for incorrect encoding on parameters -
dapr-caller (the invoker service)
dapr-called (the invoked service)
Request
curl --location --request GET 'http://localhost:9998/caller' --form 'uri="abc/pqr"'
Response (observed)
Response (expected)
Attaching the source code for reference-
dapr-encoded-params.zip
artur-ciocanu commentedon Apr 22, 2025
@rdosifyndna thanks a lot for the repo steps. I will try to run some tests locally and see if the issue is fixed by recent PR. Thank you!
Merge branch 'master' into daprgh-1314
Merge branch 'master' into daprgh-1314
Merge branch 'master' into daprgh-1314
Merge branch 'master' into daprgh-1314
artur-ciocanu commentedon Apr 26, 2025
@rdosifyndna I have finally managed to confirm that this PR: #1320 fixes the issue that you have reported, both the forward slash and incorrect encoding.
We are waiting for the final review and we will see how are we going to release it.
cicoyle commentedon Apr 30, 2025
The fix is confirmed for
v1.14.1-rc-1
, so I will cut1.14.1
later today 👍🏻 Thx for reporting this issue!