Возврат HTTP Post и Put 401 Неавторизованный на определенных рабочих станциях при аутентификации с использованием согласования на встроенной аутентификации Windows IIS

Question

У нас странное поведение на небольшом количестве рабочих станций (Windows 7). Наш клиент .NET взаимодействует с сервисом REST Api (веб-API 2), который размещен в IIS. Клиент использует System.Net.Http.HttpClient для доступа к Api и предназначен для .NET Framework 4.5.2. Api настроен на использование Windows Integrated Authentication (Negotiate, NTLM).

Когда клиент вызывает Api, используя HTTP GET/DELETE, все работает. Когда клиент вызывает Api, используя HTTP POST/PUT (данные отправляются через тело запроса). IIS отвечает с 401 Unauthorized.

Эта проблема исчезает:

• при работе с Fiddler прокси на клиентской рабочей станции.
• аутентификации IIS настроен на использование NTLM только

Я прошел через многочисленные блог-посты и статьи, но не нашел решения.

• Скрипач фиксирует мое приложение проверку подлинности http://www.telerik.com/blogs/help!-running-fiddler-fixes-my-app-
• Troubleshoot Kerberos https://blogs.msdn.microsoft.com/friis/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iisie/

SignalR показывает то же самое странное поведение. Клиент также связывается с услугой с помощью SignalR. Клиент может подключаться к концентратору и получать сообщения. Но получает 401 при попытке вызвать метод (вызов signalR выполняется с помощью POST). Поскольку клиент находится в Windows 7, он не поддерживает WebSockets. Такое же поведение происходит на обоих транспорте (события, отправленные сервером, длинный опрос). Это похоже на SignalR net45 gives 401 Unauthorized on specific user/machine combinations. Также исправление (использование Microsoft.AspNet.SignalR.Client.2.2.0 \ lib \ net40 \ Microsoft.AspNet.SignalR.Client.dll) из этого сообщения работает также и для SignalR.

Редактировать: SignalR net40 не использует HttpClient из System.Net.Http. Поэтому ошибка должна быть связана с библиотекой System.Net.Http.

Большое спасибо за любые предложения.

Answer 1

Возможные Обойти являются:

• Установите System.Net.ServicePointManager.Expect100Continue = false; перед созданием любого экземпляра HttpClient

• Отключить эту 100Continue на HttpClient

  var c = new HttpClient(); 
  c.DefaultRequestHeaders.ExpectContinue = false;