Currently, .NET Core will ignore automatic HTTPS -> HTTP redirects in HttpClientHandler. This is already a different behavior from .NET Framework (which allows automatic HTTPS -> HTTP redirects).
.NET Core is different from .NET Framework in this manner in order to provide a more secure behavior pattern. However, currently .NET Core simply ignores the HTTPS -> HTTP redirect. It leaves the final response with the 3xx response. This has caused a lot of developer confusion when troubleshooting issues.
This issue is now tracking to make a behavior change to .NET Core. Instead of ignoring HTTPS -> HTTP redirects, it will instead throw an HttpRequestException with a suitable inner exception and error message.
Although I understand why the behavior was changed, it is an unfortunate change because existing code gets to depend on observed behavior.
If the behavior is going to change again as being described here, at least offer the option to opt-in (or out depending on the defaults) on the new behavior of throwing when redirecting from HTTPS to HTTP.
We've decided to re-scope this issue to just add more logging information when a redirect is blocked. The goal is to make it easier to discover why the redirect is not happening, while also maintaining compatibility with our current behavior.
The key reason for re-scoping was to avoid breaking change for people who already implemented the workaround we suggested.
Most helpful comment
Although I understand why the behavior was changed, it is an unfortunate change because existing code gets to depend on observed behavior.
If the behavior is going to change again as being described here, at least offer the option to opt-in (or out depending on the defaults) on the new behavior of throwing when redirecting from HTTPS to HTTP.