Я подозреваю, что на самом деле вы видите не какое-то поведение "автоматической повторной попытки", а аутентификацию NTLM с запросом-ответом . По своей природе вам нужно будет добавить дополнительный туда-обратно к первому запросу на соединение. Аутентификация должна выглядеть следующим образом:
- Клиент запрашивает ресурс, защищенный проверкой подлинности NTLM.
- Сервер ответит 401 несанкционированным и укажет механизмы, которые он поддерживает (в данном примере, NTLM).
- Клиент запрашивает ресурс с начальным сообщением аутентификации NTLM (сообщение «тип 1»), которое содержит домен пользователя и имя пользователя, а также возможности клиента.
- Сервер отвечает 401 несанкционированным и вызовом NTLM (сообщение «тип 2»).
- Клиент вычисляет ответ на запрос сервера, а затем запрашивает ресурс с окончательным сообщением аутентификации NTLM (сообщение «тип 3»).
- Сервер отвечает соответствующим кодом - если аутентификация не удалась, это будет 401, если аутентификация прошла успешно, это будет успех, не найден и т. Д.
Так что да, вы будете использовать некоторые дополнительные ресурсы для проверки подлинности NTLM (во всяком случае, через обычную проверку подлинности.) Обратите внимание, однако, что NTLM проверяет подлинность соединения , а не запроса . Таким образом, последующие запросы по одному и тому же поддерживаемому HTTP-соединению не требуют повторной аутентификации. Это уменьшает бремя характера «вызов-ответ».
Наконец, обратите внимание, что большинство веб-браузеров, поддерживающих NTLM или SPNEGO, подготовлены для этого и будут использовать функцию «ожидать / продолжить». Таким образом, они не будут отправлять данные POST (например) в начальном соединении, пока не будут аутентифицированы и не получат HTTP-продолжение от сервера, что также должно уменьшить нагрузку.