我们正在尝试将 REST Web API 从作为 Windows .NET Core 3.1 堆栈式 Web 应用托管迁移到 Linux on Azure 上的容器化 Web 应用。
到目前为止，我们已成功将镜像推送到 Azure 容器注册表，在那里它会被自动拾取并成功部署到应用服务。不幸的是，该应用程序还不能正常工作。当尝试从我们的 API (GET https://foo.azurewebsites.net/api/configuration) 的(匿名)端点获取一些配置数据时，我没有像以前那样返回数据，而是得到了 301(永久移动)状态代码，该代码完全指向本身:location: https://foo.azurewebsites.net/api/configuration这会导致重定向循环。
到目前为止，我不知道为什么会收到 301，我很高兴收到任何提示。
兴趣点:
- Docker:镜像的基础是:
mcr.microsoft.com/dotnet/core/aspnet:3.1 - Azure:身份验证/授权已关闭
- Azure:无 Front Doors已安装
- 应用正确地服务于 Swagger UI。
- Docker 镜像在本地运行良好。
最佳答案
以下是我解决问题的方法:事实证明，永久重定向循环的原因是代理在 Azure 部署中的工作方式(感谢 Jason Pan 为我指出了这个方向)和以下代码的结合我们在 Startup 中有:
services.AddControllersWithViews()
.AddMvcOptions(o =>
{
...
o.Filters.Add(new RequireHttpsAttribute { Permanent = true }); // REMOVE THIS LINE
...
});
删除 RequireHttpsAttribute 过滤器后，应用程序开始按预期工作。由于我已将 TLS/SSL 设置配置为仅允许 HTTPS，因此我认为省略过滤器是安全的。
更新 2021-01-20
我刚刚发现有一种更好的方法可以做到这一点，不需要删除 RequireHttpsAttribute 过滤器。问题的核心在于，Kestrel 不知道通信是通过安全通道进行的，因为反向代理正在通过 http 将请求转发到 Kestrel。所以我们需要启用 header 转发。对于 .NET Core 2.x 应用程序，这意味着遵循 Configure ASP.NET Core to work with proxy servers and load balancers 中解释的步骤。 。幸运的是，对于 ASP.NET Core 3.x 应用程序，有一种更简单的方法(遗憾的是官方文档中尚未提及，但已在 preview 6 公告中提及):只需设置 ASPNETCORE_FORWARDEDHEADERS_ENABLED环境变量设置为true。这可以在 Azure 门户中的配置> 应用程序设置下以常规方式完成:
关于asp.net-core - Azure Web应用程序部署为docker容器无尽的301循环，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/65779034/