C# IIS部署的ASP.NET核心应用程序给出的间歇431请求头太长错误

我正在开发一个ASP.NET核心应用程序，它通过

RestSharp

使用

GraphQL

端点来检索数据。这是一个内部网类型的应用程序，部署在Windows 2016 IIS服务器上，我们正在使用Windows身份验证。我们遇到的问题是，某个属于大量active directory组的用户正在收到间歇性的431请求头过长错误

我尝试了以下几点：

我正在为应用程序和服务设置

startup.cs

中的

IISDefaults

：

services.AddAuthentication(IISDefaults.AuthenticationScheme);

我正在通过RestRequest中的UseDefaultCredentials

var client = new RestClient(endpoint);
var request = new RestRequest(Method.POST);
request.UseDefaultCredentials = true;
request.AddHeader("content-type", "application/json");
request.AddParameter("application/json", data, ParameterType.RequestBody);
IRestResponse response = client.Execute(request);
return response.Content;

将

MaxFieldLength

和

MaxRequestBytes

的注册表项设置为允许的最大值

来自标准输出的日志：

信息：Microsoft.AspNetCore.Server.Kestrel[17] 连接id“0HLIABLA41UKH”请求数据错误：“请求头太长。” Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException:请求头太长。在Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException.Throw（RequestRejectionReason）在Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TakeMessageHeaders（ReadOnlySequence

1缓冲区，SequencePosition&consumed，SequencePosition&Inspected）位于Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.ParseRequest（ReadOnlySequence

1缓冲区，SequencePosition&consumed，SequencePosition&Inspected，SequencePosition&Inspected），位于Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest（ReadResult结果，布尔值和endConnection）在Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext]（IHttpApplication

1应用程序）在Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequestsAsync[TContext]（IHttpApplication

1应用程序） 信息：Microsoft.AspNetCore.Hosting.Internal.WebHost[1]

---

通过设置MaxRequestHeadersTotalSize Kestrel选项解决了这一问题。默认值为32768

        public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                   .UseStartup<Startup>()
                   .UseKestrel(options =>
                   {
                      options.Limits.MaxRequestHeadersTotalSize = 1048576;
                   });

公共静态IWebHostBuilder CreateWebHostBuilder（字符串[]args）=>
WebHost.CreateDefaultBuilder（args）
.UseStartup（）
.UseKestrel（选项=>
{
options.Limits.MaxRequestHeadersTotalSize=1048576；
});

这有时会发生，因为您的广告帐户位于许多安全组中。如果减少所属组的数量，则Windows auth标头的大小应减小，从而允许您发出请求

如果您不能离开您所在的任何安全组，则必须使用其他答案的方法

这通常被称为HTTP 400

---

乔纳斯走上了正确的道路，帮助解决了我在ASP.NET核心web应用程序中遇到的类似情况。然而，在查看Kestrel服务器上的Microsoft文档后，我发现如果使用ASP.NET Core 2.2，Jonas的方法需要稍微修改（感谢@cristi71000的评论）。大部分功劳都应该归于@Jonas Wik，因为他为我们指明了正确的方向

他建议在创建和配置web主机生成器时链接

UseKestrel（）

helper方法。但是，根据Microsoft针对ASP.NET Core 2.2的文档，

CreateDefaultBuilder（）

已经在幕后调用了

UseKestrel（）

。当需要额外配置时，应使用助手方法

ConfigureKestrel（）

进一步配置Kestrel。更新Jonas对ASP.NET Core 2.2的回答时，应如下所示：

公共静态IWebHostBuilder CreateWebHostBuilder（字符串[]args）=>
WebHost.CreateDefaultBuilder（args）
.UseStartup（）
.ConfigureKestrel（（上下文、选项）=>
{
options.Limits.MaxRequestHeadersTotalSize=1048576；
});

充分披露：我已经做了这两件事，没有注意到任何差异或任何不良副作用。然而，最好遵守他们的文档化实践，以确保在未来的开发中不会出现任何问题

---

该用户是500多个Active Directory组的管理员和成员。这是针对ASP.NET Core 2.2的。Jonas的答案是ASP.NETCore2。1@cristi71000谢谢你的意见。我已经更新了我的答案。我在问题或Jonas的回答中没有看到任何指示ASP.NET Core特定版本的内容，但在查看文档后，我确实看到配置Kestrel的过程确实从v2.1更改为v2.2。我修改了我的答案，希望能为其他读者指出正确的方向，如果他们的目标是v2.2。