简体   繁体   中英

IIS Deployed ASP.NET Core application giving intermittent 431 Request headers too long error

I am working on an ASP.NET Core application which consumes a GraphQL endpoint via RestSharp to retrieve the data. This is an intranet type application, deployed on a Windows 2016 IIS Server and we are utilizing Windows Authentication. The problem we are encountering is that a certain user, who belongs to a large number of active directory groups is getting intermittent 431 Request headers too long errors.

I have attempted the following:

  1. I am setting the IISDefaults in the startup.cs for both the application and service:

     services.AddAuthentication(IISDefaults.AuthenticationScheme); 
  2. I am passing UseDefaultCredentials in the RestRequest

     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. Set the registry entries for MaxFieldLength and MaxRequestBytes to the max allowed.

Log from stdout:

info: Microsoft.AspNetCore.Server.Kestrel[17] Connection id "0HLIABLA41UKH" bad request data: "Request headers too long." Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Request headers too long. at Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException.Throw(RequestRejectionReason reason) at 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 buffer, SequencePosition& consumed, SequencePosition& examined) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest(ReadResult result, Boolean& endConnection) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication 1 application) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequestsAsync[TContext](IHttpApplication 1 application) info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]

This was resolved by setting the MaxRequestHeadersTotalSize Kestrel option. This defaults to 32768.

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

Unfortunately I do not yet have enough reputation to comment on @Jonas Wik's answer, so I have to post it as an answer. Jonas is on the right track and helped solved the similar situation that I was having with an ASP.NET Core web application. However, after reviewing the Microsoft docs on the Kestrel server, I found that Jonas' method needs to be modified slightly to be the most complete answer. Most of the credit should go to him for pointing us all in the right direction.

He suggests chaining the UseKestrel() helper method when creating and configuring a web host builder. However, according to the Microsoft docs, CreateDefaultBuilder() is already calling UseKestrel() behind the scenes. When additional configuration is needed, the helper method ConfigureKestrel() should be used to further configure Kestrel. Updating Jonas' answer would look like this:

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

Full disclosure: I have done both and do not notice a difference or any adverse side-effects. However, it's best to stay in line with their documented practices to ensure nothing goes off the rails in future development!

How to Use Kestrel in ASP.NET Core Apps

This can sometimes happen because your AD account is in a lot of security groups. If you reduce the number of groups you are in, your Windows auth header should reduce in size, allowing you to make the request.

If you can't leave any of the security groups you are in, you'll have to use the other answer's method.

This is often reported as HTTP 400.

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

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM