IE8 wird keine Datei mit einem benutzerdefinierten Mime/Typ mit aktivierter Benutzerkontensteuerung herunterladen

Ich habe einen .net-Dienst auf dem lokalen Computer (Windows 7 x64, IE8, .net 3.5, C#), der eine Datei an den Browser zurückgibt als Reaktion auf eine Benutzeraktion. Mit Firefox oder Chrome wird die Datei ordnungsgemäß heruntergeladen und unsere Anwendung wird über einen benutzerdefinierten MIME-Typ gestartet und alles ist gut.IE8 wird keine Datei mit einem benutzerdefinierten Mime/Typ mit aktivierter Benutzerkontensteuerung herunterladen

Jedoch, mit IE8, erhalte ich einen Dialog "Datei kann nicht heruntergeladen werden. Kann diese Internetseite nicht öffnen. Die angeforderte Seite ist entweder nicht verfügbar oder kann nicht gefunden werden. Bitte versuchen Sie es später erneut".

Mit Fiddler habe ich überprüft, dass IE die Nutzlast von dem Dienst empfängt.

Wenn ich UAC abstelle, lädt IE die Datei herunter und startet die zugehörige Anwendung.

Die Deaktivierung von UAC ist keine praktikable Lösung, da unsere Kunden sie aktivieren können.

Wie kann ich IE8 veranlassen, die zugehörige Anwendung mit aktivierter Benutzerkontensteuerung zu starten?

EDIT:

Nach den Mime-Typ mit einer programmatischen id wie here Neuregistrierung, kann ich IE zu öffnen bekommen zeigen, die „Öffnen oder Speichern“ -Dialog zum zweiten Mal der Link aus der Adressleiste angefordert wird. Warum funktioniert es nicht das erste Mal?

Quelle

2010-01-25 Jeff Paquette

Ist der benutzerdefinierte MIME-Typ sogar notwendig? Wäre 'application/octet-stream' nicht ausreichend? – Joey

Gute Frage. Soweit ich weiß, bestimmt IE, welches Programm zum Starten einer Anwendung verwendet wird. Dies ist eine geschlossene Schleife hier, es ist unsere Datendatei und unser Betrachter. Wie sonst würden wir es tun? –

Wenn Sie einen generischen MIME-Typ wie application/octet-stream und eine benutzerdefinierte Dateierweiterung verwenden, die Sie in Ihrem Viewer registriert haben (im Installer des Viewers), wird IE (und alles andere) es dann anzeigen? –

konnte ich dieses Problem heute lösen. Es stellt sich heraus, dass der Codebehind die CacheControl Eigenschaft der Antwort auf gesetzt hat. Durch das Entfernen dieser Codezeile wurde das Problem behoben. Die andere Hälfte des Updates hat den Mime-Typ und die Dateierweiterung mit einer ProgId korrekt registriert.

Ich reduzierte die Antwort auf nur content-disposition: attachment; filename=xxx und ein binäres Schreiben der Zeichenfolge Daten. IE hat das Dialogfeld Öffnen oder Speichern korrekt angezeigt, obwohl der Mime-Sniff die Datei als Text/HTML gemeldet hat (was wirklich text/plain hätte sein sollen).

Ich habe den Inhaltstyp Header hinzugefügt und erneut getestet, dann die Option nosniff und erneut getestet und schließlich die Cache-Kontrolle. Zwischen den einzelnen Tests habe ich die VM neu gestartet, um sicherzustellen, dass es sich um eine einwandfreie Testumgebung handelt (dh es wurde nichts zwischengespeichert oder vorgeladen). Nur die Cache-Kontrollzeile beeinflusste das Verhalten negativ.

Quelle

2010-02-09 04:30:29

From MSDN

Wenn Internet Explorer den Content-Type kennt angegeben, und es gibt keine Content-Disposition-Daten, führt Internet Explorer einen "MIME sniff" Scannen der ersten 200 Bytes der Datei die bestimmen, ob Die Dateistruktur entspricht allen bekannten MIME-Typen. Weitere Informationen zum MIME-Sniffing finden Sie unter MIME-Typerkennung in Internet Explorer. Wenn der MIME-Sniff einen MIME-Typ erkennt, der dem Internet Explorer bekannt ist, und die Datei wurde noch nicht von einem Mimefilter geladen, legt Internet Explorer diese Dateierweiterung fest, bevor die Datei in den Cache des lokalen Browsers gestellt wird.

Schließlich, wenn keine Content-Type- oder Content-Disposition-Daten vorhanden sind und der MIME-Sniff einen bekannten MIME-Typ nicht erkennt, wird die Dateierweiterung auf dieselbe Erweiterung wie die zum Herunterladen der Datei verwendete URL gesetzt.

Wenn die Datei im HTTP-Header als "content-disposition = Anhang" markiert ist, behandelt Internet Explorer den Dateinamen aus der URL als final und benennt ihn nicht um, bevor er in den Cache gestellt wird.

content-disposition = Anhang ist das die Lösung?!?

/Erling Damsgaard DNS-IT ApS

Quelle

2010-02-08 22:02:35 Famdam

Nein, das ist es nicht, obwohl es so aussieht, wie es sein sollte. –

Wir hatten das gleiche Problem in unserer ClickOnce-Bereitstellung von www.Qiqqa.com eingebettet. Ich vermute, dass es mit dem "MIME Type Sniffing" zu tun hat, den IE macht, wenn er einen Application/Octet-Stream bekommt - ich schätze, um den Benutzer vor bösartigen Dingen zu schützen.

Wie auch immer, um das Problem zu lösen, haben wir den MIME-Typ unserer .deploy-Dateien in text/plain geändert - offensichtlich nicht ideal, aber gleichzeitig kenne ich kein Szenario, in dem wir eine haben könnten. Stellen Sie die Datei auf unserem Server so bereit, dass ein Benutzer nach außerhalb von ClickOnce stöbern würde.

Quelle

2010-10-20 19:58:55 Jimme

Für mich ist die Lösung für dieses Problem

veränderte

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

 
Response.ContentType = "text/csv";

Quelle

2012-02-01 00:57:19 Maxx

müssen sicherstellen, dass "no-store" in der Kopfzeile angezeigt wird, bevor "no-cache". Siehe diesen Beitrag: http://blogs.msdn.com/b/ieinternals/archive/2009/10/03/internet-explorer-cannot-download-over-https-when-no-cache.aspx

Quelle

2013-09-10 21:32:18 LungFungus

Dies scheint auf den ersten Blick ein Hit und Versuch zu sein; aber es hat für mich funktioniert. Siehe auch [Gleiche Lösung im MSDN-Blog vorgeschlagen] http://blogs.msdn.com/b/ieinternals/archive/2009/10/03/internet-explorer-cannot-download-over-https-when-no-cache. Aspx? PageIndex = 2 –

IE8 wird keine Datei mit einem benutzerdefinierten Mime/Typ mit aktivierter Benutzerkontensteuerung herunterladen

Antwort

Verwandte Themen