Asp.net core Azure web应用程序部署为docker容器循环

我们正在尝试将REST Web API从作为Windows.NET Core 3.1堆叠Web应用程序托管迁移到Azure上Linux上的容器化Web应用程序

到目前为止，我们已经成功地将映像推送到Azure容器注册表，在那里它将被自动拾取并成功部署到应用程序服务。不幸的是，该应用程序还不能正常工作。尝试从API（

GET）的（匿名）端点获取一些配置数据时https://foo.azurewebsites.net/api/configuration

），而不是像以前那样返回数据，我得到一个301（永久移动）完全指向自身的状态代码：

位置：https://foo.azurewebsites.net/api/configuration

这将导致重定向循环

到目前为止，我不知道为什么我会得到301，我很高兴得到任何提示

关注点：

• Docker:映像的基础是：

  mcr.microsoft.com/dotnet/core/aspnet:3.1

• Azure:身份验证/授权已关闭
• Azure:没有安装任何组件
• 该应用程序正确地服务于招摇过市用户界面
• Docker映像在本地运行良好

---

我是如何解决这个问题的：事实证明，永久重定向循环的原因是代理在Azure部署中的工作方式（感谢Jason Pan为我指出了这个方向）和我们在

启动中的以下代码结合在一起的：

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

一旦我删除了
requireHttpAttribute
过滤器，应用程序就开始按预期工作。由于我已经将TLS/SSL设置配置为只允许HTTPS，因此我认为省略过滤器是安全的

更新2021-01-20

我刚刚发现有一种更好的方法可以做到这一点，它不需要删除
requireHttpAttribute
过滤器。问题的核心是Kestrel不知道通信是通过安全通道进行的，因为反向代理通过
http
将请求转发给Kestrel。因此，我们需要启用头的转发。对于.NET Core 2.x应用程序，这意味着要遵循中介绍的步骤。幸运的是，对于ASP.NET Core 3.x应用程序，有一种更简单的方法（遗憾的是，官方文档中还没有提到这一点，但这是发布的一部分）：只需将ASPNETCORE\u FORWARDEDHEADERS\u ENABLED环境变量设置为
true
。这可以在Azure门户中的配置应用程序设置下以常规方式完成：

在我们调试问题之前，您可能需要在启动时使用代码和示例api创建测试项目。建议先在iis上部署，然后再部署。我知道您的应用程序部署在linux下。我的建议是确保程序正常运行，以便您可以在本地部署iis。@JasonPan感谢您的支持。很抱歉，如果没有遇到此问题，但我们正在尝试从Windows/IIS迁移到Docker/Linux。我们的代码在以前的部署设置中已经运行良好。