latest mcr.microsoft.com/dotnet/aspnet:9.0 on ubuntu-latest causing 307 redirects from app.UseHttpsRedirection();

[adambient]

Describe the bug

In my Azure Web App for Containers application which I publish via Azure DevOps using these images in my Dockerfile

FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS base
ENV TZ=Europe/London
WORKDIR /app
EXPOSE 8080
EXPOSE 8081

FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
...

Causes my website to continually redirect giving ERR_TOO_MANY_REDIRECTS in e.g. chrome. As part of my investigation I found that removing this line of code from my Startup.cs

app.UseHttpsRedirection();

prevented the continual redirects but it broke the authentication flow so is not a solution.

Going back to previous working images so that my Dockerfile is as follows fixes the issue

FROM mcr.microsoft.com/dotnet/aspnet@sha256:d5507d8292fb2469ec0b9913f3cd4bb8d5a014bd6dc00c33fd4c4e7310229f07 AS base
ENV TZ=Europe/London
WORKDIR /app
EXPOSE 8080
EXPOSE 8081

FROM mcr.microsoft.com/dotnet/sdk@sha256:c5b188baf837b0180a14f988815b9cc7a55b836dd6cbe1b6e6523cf3098faaa8 AS build

So I believe the issue is with the current version of mcr.microsoft.com/dotnet/aspnet:9.0 and possibly mcr.microsoft.com/dotnet/sdk:9.0.

I am publishing to my web app for containers using ubuntu-latest

Which .NET image(s) are you using?

mcr.microsoft.com/dotnet/aspnet:9.0
mcr.microsoft.com/dotnet/sdk:9.0

Steps to reproduce

Publish an ASP.NET Core Web Application to Azure Web App for Containers using ubuntu-latest with the docker file referencing mcr.microsoft.com/dotnet/aspnet:9.0 and in the Startup.cs have app.UseHttpsRedirection();

Other information

A workaround is to use older images so that the Dockerfile is something like

FROM mcr.microsoft.com/dotnet/aspnet@sha256:d5507d8292fb2469ec0b9913f3cd4bb8d5a014bd6dc00c33fd4c4e7310229f07 AS base
ENV TZ=Europe/London
WORKDIR /app
EXPOSE 8080
EXPOSE 8081

FROM mcr.microsoft.com/dotnet/sdk@sha256:c5b188baf837b0180a14f988815b9cc7a55b836dd6cbe1b6e6523cf3098faaa8 AS build

Output of docker version

using Task : Docker in Azure DevOps Version 2.256.1 so not sure which version of docker

Output of docker info

using Task : Docker in Azure DevOps Version 2.256.1 so not sure which version of docker

[BrennanConroy]

Can you turn on debug logging? Also potentially share a network trace?

Edit: Are you using UseForwardedHeaders middleware?

[adambient]

Thank you I have now recreated the issue to try to provide you with the info I hope this helps...

When I turn on trace/debug logging our logs have this info

Jun 12, 2025 @ 08:24:56.043	Request starting HTTP/1.1 GET http://REDACTED.azurewebsites.net/ - - -	
	Jun 12, 2025 @ 08:24:56.043	All hosts are allowed.	
	Jun 12, 2025 @ 08:24:56.043	Unknown proxy: [::ffff:172.16.5.1]:36559	
	Jun 12, 2025 @ 08:24:56.043	Redirecting to 'https://REDACTED.azurewebsites.net/'.	
	Jun 12, 2025 @ 08:24:56.043	Connection id "0HND9G3FM2910" completed keep alive response.	
	Jun 12, 2025 @ 08:24:56.043	Request finished HTTP/1.1 GET http://REDACTED.azurewebsites.net/ - 307 0 - 0.1677ms	
	Jun 12, 2025 @ 08:24:55.690	Request starting HTTP/1.1 GET http://REDACTED.azurewebsites.net/ - - -

The response in fiddler is

HTTP/1.1 307 Temporary Redirect
Content-Length: 0
Date: Thu, 12 Jun 2025 07:21:46 GMT
Server: Kestrel
Location: https://REDACTED.azurewebsites.net/
X-Frame-Options: SAMEORIGIN

it redirects to iteself until you get ERR_TOO_MANY_REDIRECTS in chrome

We are using UseForwardedHeaders, the code in our Startup.cs is

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedProto
});

This issue is resolved by pinning old images specifically

mcr.microsoft.com/dotnet/aspnet@sha256:d5507d8292fb2469ec0b9913f3cd4bb8d5a014bd6dc00c33fd4c4e7310229f07
mcr.microsoft.com/dotnet/sdk@sha256:c5b188baf837b0180a14f988815b9cc7a55b836dd6cbe1b6e6523cf3098faaa8

[BarbeRouss]

I just had an issue with the ForwardedHeaders in that image version, and thought it might be related.
We have a blazor app behind an Azure Application gateway, and we use Microsoft Entra Id for the login. We have this in our Program.cs to handle the fact that the application gateway send a x-original-host header instead of the X-Forwarded-Host, and to make sure that after the login, the user is redirected to the proper URL.

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
	ForwardedHeaders = ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedHost,
	ForwardedHostHeaderName = "x-original-host"
});

Using the new docker image, we are no longer redirected to the original host, but to the internal hostname of the container app.

If you think that it is not related, I will file a new issue.

[darena-antonw]

Might be related, our problem is that the forward header options stopped working when building for container with the 8.0.17 .net version

images used: sdk:8.0-jammy & aspnet:8.0-jammy

sdk@sha256:e12df6fb2eaa26a07be20ba87c529b0dff4df83c7ddcba2e1ae642e529b1d5ce
aspnet@sha256:3cede7ca994a4fe47c347fad0720e81dadfd3f5245bec4b5bb5c5d17e0d19167

reverting to 8.0.16 version fixes the issue

sdk@sha256:b7c27d609d9331f6715bb1fddc0e8a87c42ef1f34dacd43c059921c5c5f91cb9
aspnet@sha256:823310e3e2902712c6972ff07e83ec84d9a5d79732fa790e4bc69fca1fccdc96

[mthalman]

Moved to aspnetcore repo to investigate.

[dixong]

I had much the same issue. I have the correct forward header options configured but on logging the Request.Scheme it would always show http and not https and fail to redirect with authentication. This is in a Blazor Server application.

I've reverted to 8.0.16 and it works as expected