Skip to content

Dapr SDK 1.14.0 Issue with Slash "\" in URI #1314

@rahulpoddar-fyndna

Description

@rahulpoddar-fyndna

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

vikram-mahadevkar commented on Apr 19, 2025

@vikram-mahadevkar
  • In our application we have code which uses DaprClient.invokeMethod method provided by Dapr SDK to make remote call to other apps.
  • As during JUnit run sidecar is not available, we create mock HTTP endpoints using WireMock library which mimics endpoints provides by Dapr sidecar and return configured mock response.
  • In our application we use leading slash(/) in all endpoints while calling DaprClient.invokeMethod method.
  • These JUnits were working properly with Dapr SDK version 1.13.3.
  • But post upgrade to Dapr SDK version 1.14.0, these JUnits are failing. If we remove leading slash from endpoint then JUnits work as expected.
  • We understand that there are changes in Dapr SDK version 1.14.0 to Replacing OkHttpClient with Java 11 HttpClient(Replacing OkHttpClient with Java 11 HttpClient #1218). We suspect this issue might be related to these changes, but Dapr team can confirm on this.

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

artur-ciocanu commented on Apr 19, 2025

@artur-ciocanu
Contributor

Thanks for the repro scenario we will take a look and get back to you.

artur-ciocanu

artur-ciocanu commented on Apr 21, 2025

@artur-ciocanu
Contributor

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.

@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

rdosifyndna commented on Apr 22, 2025

@rdosifyndna

@artur-ciocanu @rahulpoddar-fyndna
Sharing an example of code for incorrect encoding on parameters -

dapr-caller (the invoker service)

@GetMapping
public JsonNode call(@RequestParam String uri) {
  Map<String, List<String>> queryParams = new HashMap<>();
  queryParams.put("uri", List.of(uri));
  HttpExtension httpExtension =
    new HttpExtension(DaprHttp.HttpMethods.GET, queryParams, new HashMap<>());
  Mono<JsonNode> responseMono =
    daprClient.invokeMethod("dapr-called", "/called", null, httpExtension, JsonNode.class);
  return responseMono.block();
  }

dapr-called (the invoked service)

@GetMapping
public ObjectNode get(@RequestParam String uri) {
  ObjectNode objectNode = objectMapper.createObjectNode();
  objectNode.put("uri", uri);
  return objectNode;
}

Request

curl --location --request GET 'http://localhost:9998/caller' --form 'uri="abc/pqr"'

Response (observed)

{
    "uri": "abc%2Fpqr"
}

Response (expected)

{
    "uri": "abc/pqr"
}

Attaching the source code for reference-

dapr-encoded-params.zip

artur-ciocanu

artur-ciocanu commented on Apr 22, 2025

@artur-ciocanu
Contributor

@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!

artur-ciocanu

artur-ciocanu commented on Apr 26, 2025

@artur-ciocanu
Contributor

@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

cicoyle commented on Apr 30, 2025

@cicoyle
Contributor

The fix is confirmed for v1.14.1-rc-1, so I will cut 1.14.1 later today 👍🏻 Thx for reporting this issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @artur-ciocanu@cicoyle@vikram-mahadevkar@rahulpoddar-fyndna@rdosifyndna

      Issue actions

        Dapr SDK 1.14.0 Issue with Slash "\" in URI · Issue #1314 · dapr/java-sdk