Dapr SDK 1.14.0 Issue with Slash "\" in URI

[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.

[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]

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

[artur-ciocanu]

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]

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

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

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