A request to update the Dapr version is being made due to the failure of invocation requests caused by the addition of extra headers

[theringe]

This issue is a: (mark with an x)

• [v] bug report -> please search issues before submitting
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Issue description

When using Dapr invocation for communication between Container Apps, requests fail in the current Dapr version (i.e., 1.12.5) because the request is forcibly appended with Transfer-Encoding before reaching the destination.

Steps to reproduce

1. Create two Azure Container Apps within the same Container App Environment without VNET integration. These represent the "caller" and the "callee"
2. Confirm that the Dapr version used by ACA is indeed 1.12.5.
3. Set up a service on the callee using the graphene-django framework with an endpoint at /graphql.
4. The caller sends a simple GraphQL query to the callee using curl via Dapr, explicitly adding the Content-Length header while ensuring that no Transfer-Encoding is present.
   json_data='{"query":"query MyQuery {\n notificationRetrive(caller: \"2\", notificationId: \"2\") {\n messageId\n }\n}","operationName":"MyQuery"}'
content_length=$(echo -n "$json_data" | wc -c)
curl -v -X POST http://localhost:3500/v1.0/invoke/app-id-of-callee/method/graphql/ -H "Content-Length: $content_length" -H "Content-Type: application/json" --data-binary "$json_data"

Expected behavior [What you expected to happen.]
The callee is expected to receive the Content-Length header from the caller without Transfer-Encoding being added. It should return a successful status code, not a 4XX.

Actual behavior [What actually happened.]
However, the callee receives an empty Content-Length header (not even a number) and has Transfer-Encoding forcibly added. It returns a 4XX status code.

Screenshots
Caller


Callee

Additional context

I was able to reproduce this issue in my local environment using Dapr version 1.12.5. However, after updating Dapr to version 1.14.5 RC1 locally, the issue was resolved.

From my research, it appears that some updates between versions 1.12.5 and 1.14.5 are closely related to this problem. Since I cannot control the pace of Azure's Dapr updates, I would like to request an expedited update to address this issue.
Release Dapr Runtime v1.14.3 [RECALLED] · dapr/dapr

Release Dapr Runtime v1.13.2 · dapr/dapr