IE8 не будет загружать файл с настраиваемым типом/типом с включенным UAC

У меня есть служба .net, запущенная на локальной машине (Windows 7 x64, IE8,.net 3.5, С#), которая возвращает файл в браузер в ответ на действие пользователя. Используя firefox или chrome, файл загружается правильно, и наше приложение запускается через пользовательский тип mime, и все хорошо.

Однако с IE8 я получаю диалоговое окно "невозможно загрузить файл". Не удается открыть этот интернет-сайт. Запрошенный сайт либо недоступен, либо не может быть найден. Повторите попытку позже ".

Используя скрипт, я проверил, что IE получает полезную нагрузку от службы.

Если я отключу UAC, IE загрузит файл и запустит соответствующее приложение.

Отключение UAC не является жизнеспособным решением, так как наши клиенты смогут его активировать.

Как я могу заставить IE8 запускать связанное приложение с включенным UAC? ​​

EDIT:

После перерегистрации типа mime с программным идентификатором, как описано здесь, я могу открыть IE, чтобы открыть диалоговое окно "Открыть или Сохранить" для ВТОРОГО времени ссылка запрашивается из адресной строки. Почему он не работает в первый раз?

ОТВЕТЫ

Ответ 1

Я смог решить эту проблему сегодня. Оказывается, что codebehind устанавливал свойство CacheControl ответа на HttpCacheability.NoCache. Удаление этой строки кода решило проблему. Другая половина исправления правильно регистрировала тип mime и расширение файла с помощью ProgId.

Я удалил ответ только на content-disposition: attachment; filename=xxx и двоичную запись строковых данных. IE правильно отображает диалоговое окно "Открыть" или "Сохранить", даже несмотря на то, что mime sniff сообщил о файле как text/html (который действительно должен был быть текстовым/обычным).

Я добавил обратно заголовок типа контента и повторно протестировал, затем опцию nosniff и повторно протестировал и, наконец, элемент управления кешем. В промежутке между каждым тестом я перезагрузил виртуальную машину, чтобы убедиться, что это была первозданная среда тестирования (т.е. Ничего не кэшировано или не было предварительно загружено). Лишь строка управления кешем отрицательно влияла на поведение.

Ответ 2

Из MSDN

Если Internet Explorer знает указанный тип контента и нет данных Content-Disposition, Internet Explorer выполняет "MIME sniff", сканируя первые 200 байт файла, чтобы определить, соответствует ли файловая структура любым известным типам MIME. Дополнительные сведения о прослушивании MIME см. В разделе Обнаружение типа MIME в Internet Explorer. Если MIME sniff обнаруживает тип MIME, известный в Internet Explorer, и файл уже не был загружен mimefilter, Internet Explorer устанавливает это расширение файла перед тем, как поместить файл в кеш локального браузера.

Наконец, если нет данных Content-Type или Content-Disposition, а sniff MIME не распознает известный тип MIME, расширение файла устанавливается в том же расширении, что и URL-адрес, используемый для загрузки файла.

Если файл помечен как "content-disposition = attachment" в заголовке HTTP, Internet Explorer рассматривает имя файла из URL как окончательный и не переименовывает его, прежде чем помещать его в кеш.

content-disposition = attachment заключается в том, что решение?!?

/Эрлинг Дамсгаард DNS-IT ApS

Ответ 3

У нас была та же самая проблема, встроенная в наше развертывание ClickOnce www.Qiqqa.com. Я подозреваю, что это связано с "флиртом типа MIME", который IE делает, когда он получает приложение/октет-поток - я думаю, чтобы защитить пользователя от вредоносных материалов.

В любом случае, чтобы решить проблему, мы изменили тип mime наших файлов .deploy на текст /plain - явно не идеальный, но в то же время я не знаю сценарий, в котором у нас может быть .deploy файл на нашем сервере, который пользователь просматривал бы за пределами ClickOnce.

Ответ 5

Для меня решение этой проблемы менялось

Response.ContentType = "application/vnd.ms-excel";

к

Response.ContentType = "text/csv";