Description
Is there an existing issue for this?
- I have searched the existing issues
Describe the bug
When using Microsoft.AspNetCore.Rewrite
to configure a Redirect, the scheme configured in the redirect is ignored and replaced with the scheme that was used for the original request. For example, a redirect rule to http://www.example.com
will actually redirect to https://www.example.com
if your endpoint was served over HTTPS, while a redirect rule to https://www.example.com
will actually redirect to http://www.example.com
if your endpoint was served over HTTP.
This was a breaking change for us on moving from .NET Core 3.1 to .NET 6.
The behaviour occurs at line 100 of RedirectRule, and appears to have been introduced in this commit of 21st April 2021.
Expected Behavior
The scheme configured in the redirect should be respected, as in .NET Core 3.1, to continue to allow redirects to URLs with a different scheme to the receiving endpoint.
Steps To Reproduce
In ASP.NET Core middleware configuration/start-up (e.g. on the vanilla ASP.NET Core Web API template in Visual Studio):
var options = new RewriteOptions().AddRedirect("test", "http://www.example.com");
app.UseRewriter(options);
Now, when running locally over HTTPS, send a request to https://localhost:[port]/test
. An HTTP 302 is returned with the header location: https://www.example.com
, despite the configuration.
Equivalently, replace http://www.example.com
in the configuration with https://www.example.com
and access over HTTP at http://localhost:[port]/test
. An HTTP 302 is returned with the header location: http://www.example.com
, despite the configuration.
Exceptions (if any)
No response
.NET Version
6.0.203
Anything else?
ASP.NET Core runtime version 6.0.5.