Dapr: Should `daprd` follow redirects during method invocation?

[philliphoff]

When configured to use HTTP, daprd uses the valyala/fasthttp library for relaying method invocations to the application. The generic verb form Do() of invoking requests using this library does not automatically follow redirects (whereas, other forms do follow redirects, e.g. Get() and Post()).

Question: should daprd itself manage redirects as part of method invocation or simply return the redirection to the caller?

The current behavior complicates .NET Core development. By default, new web applications are scaffolded to support both HTTP and HTTPS endpoints, with calls to the HTTP endpoint redirected to HTTPS endpoint. daprd passes along the redirection to the caller, with several consequences:

• The subsequent call could fail if TLS certificate validation is enabled (which is likely, if the caller was not expecting to be redirected to HTTPS backed by a development (i.e. self-signed) certificate). On the other hand, it appears that daprd is statically configured to not validate certificates, so the redirection would be transparent to the caller).
• Dapr ends up being bypassed as the caller makes the subsequent call directly to the application endpoint (which may be confusing to users, as well as bypasses Dapr's tracing).

To have .NET Core projects work with Dapr out of the box, users must remember to use a --no-https flag when scaffolding. (Alternatively, users can disable the HTTPS endpoint redirection post-scaffolding.)

Obviously Dapr needs to work well across a broad set of platforms and stacks, even if that means it's less than optimal for a particular platform/stack in one specific scenario (like .NET Core scaffolding). Still, I wonder if this is potentially a larger issue. If an application is explicitly making calls via Dapr, would it expect to get back a response that then requires it to immediately call a non-Dapr endpoint?

[yaron2]

which may be confusing to users, as well as bypasses Dapr's tracing

Tracing will still kick in on the daprd instance that's invoked to make the service invocation call.

users must remember to use a --no-https flag when scaffolding

Correct, and this is also by design. Since Dapr is recommended to be deployed in the same network namespace as the app (on localhost), Dapr is expected to work with http and not https endpoints, with performance being just one of the reasons.

While Dapr's app channel could be made to allow for https invocations, it wouldn't be true to the local-close-to-compute sidecar nature of Dapr in regards to how it communicates with the app.

There's a good comment here about why redirects are best handled in user code.

[philliphoff]

Tracing will still kick in on the daprd instance that's invoked to make the service invocation call.

On the initial call that returns the redirect response, yes, but not the subsequent call, which bypasses the daprd instance entirely, right? (E.g. GET http://localhost:3500/v1.0/invoke/app/method/appmethod returns 307, with Location set to https://localhost:5001/appmethod).

While Dapr's app channel could be made to allow for https invocations, it wouldn't be true to the local-close-to-compute sidecar nature of Dapr in regards to how it communicates with the app.

I totally buy that argument but, at the same time, I'm trying to feel out ways to remove a stumbling block for that (.NET Core) just-trying-out-Dapr-for-the-first-time developer, which could then cloud their overall view of Dapr. We've already seen users get confused when they miss the --no-https flag and invocation fails due to the redirect. (I've even made that mistake myself.)

[yaron2]

Well, Envoy handles redirects internally for kinda/sorta similar reasons.. maybe we can do the same thing ourselves.

[chivandikwa]

If the decision is made that dapr will not handle redirects it would also be great to document this somewhere so users know this early on. I found out the hard way wondering why the /dapr/subscribe was not being called and eventually saw a 307 in the logs, would have been nice to know up front about https.

[rynowak]

We have another hit for this issue in .NET Core here: https://github.com/dotnet/tye/issues/765