Azure web app deployed as docker container endless 301 loop

Question

We are trying to migrate our REST Web API from being hosted as a Windows .NET Core 3.1 stacked web app to a containerized web app on Linux on Azure.

So far we have managed to push the image to the Azure Container Registry where it's being automatically picked up and successfully deployed to an App Service. Unfortunately, the app does not properly work yet. When trying to fetch some configuration data from a (anonymous) end-point from our API (GET https://foo.azurewebsites.net/api/configuration), instead of returning the data - as it used to do - I get a 301 (Moved Permanently) status code that points exactly to itself: location: https://foo.azurewebsites.net/api/configuration which leads to redirection loop.

So far I have no idea why I'm getting a 301 and I'm glad for any hints.

Points of interest:

Docker: the base for the image is: mcr.microsoft.com/dotnet/core/aspnet:3.1
Azure: Authentication / Authorization is switched off
Azure: no Front Doors are installed
The app is correctly serving the Swagger UI.
The Docker image works fine locally.

You may need the code and sample api in Startup to create a test project before we can debug the problem. — Jason Pan, Jan 19 '21 at 01:01
It is recommended to deploy on iis first, and then [attach to the vs 2019 debugging process to troubleshoot errors](https://stackoverflow.com/questions/848987/attach-debugger-to-iis-instance/19436912). — Jason Pan, Jan 19 '21 at 01:02
I know that your application is deployed under linux. My suggestion is to ensure that the program runs normally, so you can deploy iis locally. — Jason Pan, Jan 19 '21 at 01:04
@JasonPan thanks for your support. Sorry, if this didn't come across but we are trying to migrate *from* Windows/IIS to Docker/Linux. Our code already worked fine in the previous deployment setup. — Dejan, Jan 19 '21 at 06:38
https://learn.microsoft.com/en-us/visualstudio/containers/edit-and-refresh?view=vs-2019 — Jason Pan, Jan 19 '21 at 07:02
@JasonPan the docker image works locally without any issues. All add this observation to the question. — Dejan, Jan 19 '21 at 08:05
@JasonPan Ok. This is guiding me in an interesting direction. It's also related to https://stackoverflow.com/a/51153544/331281 — Dejan, Jan 19 '21 at 08:54

Dejan · Answer 1 · 2021-01-20T09:24:55.770

Here's how I solved the problem: it turned out that the cause for the permanent redirect loop was a conjunction of how the proxy works in the Azure deployment (thanks to Jason Pan for pointing me in that direction) and the following code that we had in our Startup:

services.AddControllersWithViews()
        .AddMvcOptions(o =>
        {
           ...
           o.Filters.Add(new RequireHttpsAttribute { Permanent = true }); // REMOVE THIS LINE
           ...
        });

Once I removed RequireHttpsAttribute filter, the app started working as expected. And since I've configured the TLS/SSL settings to allow HTTPS only, I think it is safe to omit the filter.

UPDATE 2021-01-20

I've just figured out that there's a better way to do this that does not require to remove the RequireHttpsAttribute filter. The core of the problem is that Kestrel does not know that communication is happening over a secure channel as the reverse proxy is forwarding requests over http to Kestrel. So we need to enable the forwarding of headers. For .NET Core 2.x applications this meant to follow the steps explained in Configure ASP.NET Core to work with proxy servers and load balancers. Luckily, for ASP.NET Core 3.x applications there a much more simpler way (that unfortunately is not mentioned in the official docs yet but was part of the preview 6 announcement): simply set the ASPNETCORE_FORWARDEDHEADERS_ENABLED environment variable to true. This can be done the usual way in the Azure portal under Confguration > Application settings:

Azure web app deployed as docker container endless 301 loop

1 Answers1