Question

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

我尝试了以下操作：

我正在为应用程序和服务设置IISDefaults中的startup.cs：
```
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.Internal.Http.Http1Connection.TakeMessageHeaders（ReadOnlySequence 1 buffer, SequencePosition& consumed, SequencePosition& examined) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.ParseRequest(ReadOnlySequence 1处的缓冲区Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException.Throw（RequestRejectionReason原因）在Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests [TContext]（IHttpApplication）上Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest（ReadResult result，Boolean＆endConnection） 1 application) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequestsAsync[TContext](IHttpApplication 1个申请）信息：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

Jonas走上了正确的道路，并帮助解决了ASP.NET Core Web应用程序遇到的类似情况。但是，在查看Kestrel服务器上的Microsoft文档之后，我发现如果使用ASP.NET Core 2.2 ，则需要对Jonas的方法稍作修改（由于@ cristi71000的评论）。大部分功劳仍应归功于@Jonas Wik，以向我们指出正确的方向。

他建议在创建和配置Web主机构建器时链接UseKestrel()帮助方法。但是，根据Microsoft ASP.NET Core 2.2文档，CreateDefaultBuilder()已经在后台调用UseKestrel()。当需要其他配置时，应该使用辅助方法ConfigureKestrel()来进一步配置Kestrel。更新Jonas对于ASP.NET Core 2.2的答案可能是这样的：

    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 (ASP.NET Core v2.1)

How to Use Kestrel in ASP.NET Core Apps (ASP.NET Core v2.2)

Answer 3

有时可能会发生这种情况，因为您的AD帐户位于许多安全组中。如果减少您所在的组的数量，则Windows auth标头的大小应减小，以便您发出请求。

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

通常将其报告为HTTP 400。

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

IIS部署的ASP.NET Core应用程序出现间歇性431请求标头过长的错误

3 个答案: