IIS部署的ASP.NET核心应用程序提供间歇性431请求标头太长错误

Question

我正在开发一个ASP.NET核心应用程序，它通过GraphQL使用RestSharp端点来检索数据。这是一个Intranet类型的应用程序，部署在Windows 2016 IIS服务器上，我们正在使用Windows身份验证。我们遇到的问题是，属于大量活动目录组的某个用户正在间歇性地获得431个请求标头过长的错误。

我尝试过以下方法：

1. 我在IISDefaults中为应用程序和服务设置startup.cs： services.AddAuthentication(IISDefaults.AuthenticationScheme);
2. 我在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;

3. 将MaxFieldLength和MaxRequestBytes的注册表项设置为允许的最大值。

从stdout登录：

info：Microsoft.AspNetCore.Server.Kestrel [17]连接ID“0HLIABLA41UKH”错误请求数据：“请求标头太长。” Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException：请求标头太长。 Microsoft.AspNetCore上的Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException.Throw（RequestRejectionReason reason）at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TakeMessageHeaders（ReadOnlySequence1 buffer, SequencePosition& consumed, SequencePosition& examined) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.ParseRequest(ReadOnlySequence1 buffer，SequencePosition＆consume，SequencePosition＆examine） Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests [TContext]（IHttpApplication1 application) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequestsAsync[TContext](IHttpApplication1应用程序）信息中的.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest（ReadResult result，Boolean＆endConnection）info：Microsoft。 AspNetCore.Hosting.Internal.WebHost [1]

Answer 1

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

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

Answer 2

这有时会发生，因为您的AD帐户位于许多安全组中。如果减少所在的组数，则Windows身份验证标头的大小应会减小，从而允许您发出请求。

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

这通常被报告为HTTP 400。

https://support.microsoft.com/en-au/help/327825/problems-with-kerberos-authentication-when-a-user-belongs-to-many-grou

Answer 3

不幸的是，我还没有足够的声誉评论@Jonas Wik的答案，所以我必须将其作为答案发布。 Jonas走在正确的轨道上并帮助解决了我在ASP.NET Core Web应用程序中遇到的类似情况。但是，在查看了Kestrel服务器上的Microsoft文档后，我发现Jonas的方法需要稍微修改才能成为最完整的答案。大多数功劳都归功于他，因为我们指向了正确的方向。

他建议在创建和配置Web主机构建器时链接UseKestrel()辅助方法。然而，根据微软的文档，CreateDefaultBuilder()已经在幕后调用UseKestrel()。当需要其他配置时，应使用辅助方法ConfigureKestrel()进一步配置Kestrel。更新Jonas的答案将如下所示：

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

完全披露：我已经完成了两项工作，并没有注意到差异或任何不良副作用。但是，最好与他们记录的实践保持一致，以确保在未来的开发过程中没有任何障碍！

How to Use Kestrel in ASP.NET Core Apps