Ошибки файла манифеста кеша приложения с аутентификацией Windows / NTLM

Question

Как браузеры реализуют запросы для файлов манифеста Application Cache и отличается ли это от того, как запрашиваются другие файлы?

Я спрашиваю, потому что вижу поведение, которого не ожидаю при использовании аутентификации Windows / NTLM вIIS 7. Ситуация такова, что у меня есть сайт с определенным файлом манифеста.При анонимной аутентификации все работает как положено - сайт загружается и доступен в автономном режиме.

Когда я отключаю анонимную проверку подлинности Windows и включаю ее, сайт будет нормально загружаться после проверки подлинности, но в консоли (в Chrome или на iPad 2) я вижу ошибку, из-за которой невозможно получить файл манифеста.

На iPad ошибка в том, что не удалось получить файл кэша приложения.В Chrome характерна ошибка «Ошибка кэша приложения: сбой манифеста (401)».Я вижу код ответа 401 в журналах веб-сервера в обоих случаях.

Почему такое поведение кажется неожиданным, если запросы ко всем другим ресурсам (CSS, JavaScript, изображения) все работают как положено.Кроме того, я могу просмотреть свой файл .appcache, и он загружается.

Может кто-нибудь объяснить, что происходит?

Кто-нибудь еще сталкивался с этим и нашел решение?

Answer 1

Не уверен, что это все еще актуально, но у меня тоже есть эта проблема.

Поскольку мой сайт отправляет запросы AJAX, после загрузки страницы меня запрашивают учетные данные для выполнения запроса. Как только это произошло, запуск applicationCache.update() приводит к корректному обновлению кэша приложения.

Поэтому, в качестве обходного пути, возможно, попробуйте сделать запрос AJAX к чему-либо, чтобы у пользователя запрашивались учетные данные, затем вызовите applicationCache.update().

Answer 2

Я знаю, это старый вопрос, но у меня возникла та же самая проблема, которая привела меня сюда.

мои настройки:
сервер - IIS8
аутентификация - windows
анонимная аутентификация - включена(сделал это так, чтобы я мог получить свой динамический манифест независимо от аутентификации, мне пришлось затем декорировать все остальные контроллеры с [Authorize])

При вышеупомянутой настройке приложение будет правильно кешироваться, однако при загрузке изкэша, если было обновление в манифесте, некоторые разделы не извлекались (например, авторизованный контент), потому что пользователь не был «залогинен» и, следовательно, не смог выполнить обновление целиком.

Мое решениедолжен был добавить вызов ajax к авторизованному ресурсу, таким образом, когда пользователь был в сети, ему было предложено войти в систему, что означает, что при следующем обновлении кэша они снова авторизуются.

Answer 3

Я тоже столкнулся с этой проблемой.Точно так же, как вы описали, но я использую базовую аутентификацию на Apache.Я собираюсь сделать файл mainfest общедоступным.