Развернутое IIS приложение ASP.NET Core дает прерывистую 431 Ошибка заголовка запроса слишком длинная

Question

Я работаю над приложением ASP.NET Core, которое использует конечную точку GraphQL через RestSharp для извлечения данных. Это приложение типа интрасети, развернутое на сервере IIS Windows 2016, и мы используем проверку подлинности Windows. Проблема, с которой мы сталкиваемся, заключается в том, что определенный пользователь, который принадлежит к большому количеству активных групп каталогов, получает прерывистый 431 Запрос заголовков слишком длинные ошибки.

Я попытался сделать следующее:

1. Я устанавливаю IISDefaults в startup.cs как для приложения, так и для службы:

   services.AddAuthentication(IISDefaults.AuthenticationScheme);
   

2. Я передаю UseDefaultCredentials в 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. Установите для записей реестра для MaxFieldLength и MaxRequestBytes максимально допустимое значение.

Журнал из стандартного вывода:

info: Microsoft.AspNetCore.Server.Kestrel [17] Идентификатор соединения "0HLIABLA41UKH" неверные данные запроса: "Слишком длинные заголовки запроса". Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: запрос заголовков слишком длинный. в Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException.Throw (причина RequestRejectionReason) в Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TakeMessageHeaders (буфер чтения, последовательности и последовательного использования, проверенного последовательного выражения, последовательности последовательностей, проверенных последовательностей и последовательностей) в Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest (результат ReadResult, Boolean & endConnection) в Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.Proteques запросов * 1 заявка) информация: Microsoft.AspNetCore.Hosting.Internal.WebHost [1]

Answer 1

Иногда это может произойти, потому что ваша учетная запись AD находится в большом количестве групп безопасности.Если вы уменьшите количество групп, в которые вы входите, ваш заголовок аутентификации Windows должен уменьшиться в размере, что позволит вам сделать запрос.

Если вы не можете покинуть ни одну из групп безопасности, в которых вы находитесь, вы 'Вам придется использовать метод другого ответа.

Это часто сообщается как HTTP 400.

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

Answer 2

К сожалению, у меня пока недостаточно репутации, чтобы комментировать ответ @Jonas Wik, поэтому я должен опубликовать его в качестве ответа.Йонас находится на правильном пути и помог решить ту же ситуацию, что и я, с веб-приложением ASP.NET Core.Однако, просмотрев документы Microsoft на сервере Kestrel, я обнаружил, что метод Jonas нужно немного изменить, чтобы получить наиболее полный ответ.Большая часть заслуг должна идти ему за то, что он направил нас всех в правильном направлении.

Он предлагает использовать цепочку вспомогательного метода UseKestrel() при создании и настройке компоновщика веб-хостинга.Однако, согласно документам Microsoft, CreateDefaultBuilder() уже вызывает UseKestrel() за кулисами.Когда требуется дополнительная настройка, для дальнейшей настройки Kestrel следует использовать вспомогательный метод ConfigureKestrel().Обновленный ответ Джонаса будет выглядеть следующим образом:

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

Полное раскрытие: я сделал и то, и другое, и не замечаю разницы или каких-либо неблагоприятных побочных эффектов.Тем не менее, лучше придерживаться их документированной практики, чтобы гарантировать, что ничто не сойдет с пути в будущем развитии!

Как использовать Kestrel в основных приложениях ASP.NET

Answer 3

Эта проблема была решена путем установки параметра MaxRequestHeadersTotalSize Kestrel. По умолчанию это 32768.

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