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