IE8 no descargará un archivo con un mimo/tipo personalizado con UAC habilitado

Tengo un servicio .net ejecutándose en la máquina local (Windows 7 x64, IE8, .net 3.5, C#) que devuelve un archivo al navegador en respuesta a una acción del usuario. Con Firefox o Chrome, el archivo se descarga correctamente y nuestra aplicación se inicia a través de un tipo de mime personalizado y todo está bien.IE8 no descargará un archivo con un mimo/tipo personalizado con UAC habilitado

Sin embargo, con IE8, recibo un cuadro de diálogo "no se puede descargar el archivo. No se puede abrir este sitio de Internet. El sitio solicitado no está disponible o no se puede encontrar. Vuelva a intentarlo más tarde".

Usando el violín, verifiqué que IE recibe la carga del servicio.

Si apago el UAC, IE descarga el archivo y ejecuta la aplicación asociada.

Apagar UAC no es una solución viable, ya que nuestros clientes lo habilitarán.

¿Cómo puedo obtener IE8 para iniciar la aplicación asociada con UAC habilitado?

EDIT:

Después de volver a registrar el tipo mime con una identificación programática como se describe here, puedo conseguir IE para abrir mostrar la opción "Abrir o Guardar" diálogo para la segunda vez que se solicita el enlace desde la barra de direcciones. ¿Por qué no funciona la primera vez?

Fuente

2010-01-25 Jeff Paquette

¿Es necesario el tipo MIME personalizado? ¿No bastaría 'application/octet-stream'? – Joey

Buena pregunta. Hasta donde sé, es cómo IE determina qué programa usar para iniciar una aplicación. Aquí se trata de un circuito cerrado, es nuestro archivo de datos y nuestro visualizador. ¿De qué otra manera lo haríamos? –

Si usa un tipo de mime genérico como application/octet-stream y una extensión de archivo personalizada que ha registrado con su visor (dentro de su instalador de visor), ¿IE (y todo lo demás) lo mostrará? –

que era capaz de resolver este problema hoy en día. Resulta que el código subyacente estaba configurando la propiedad CacheControl de la respuesta a HttpCacheability.NoCache. Eliminar esa línea de código resolvió el problema. La otra mitad del arreglo estaba registrando correctamente el tipo de mime y la extensión de archivo con un ProgId.

Desglose la respuesta a solo content-disposition: attachment; filename=xxx y una escritura binaria de los datos de cadena. IE mostró correctamente el cuadro de diálogo Abrir o Guardar, aunque el mime sniff informó el archivo como text/html (que realmente debería haber sido text/plain).

Agregué el encabezado de tipo de contenido y volví a probar, luego la opción nosniff y volví a probar y finalmente el control de caché. Entre cada prueba, reinicié la máquina virtual para asegurarme de que era un entorno de prueba prístino (es decir, nada en la memoria caché o precargado). Solo la línea de control de caché afectó el comportamiento de forma negativa.

Fuente

2010-02-09 04:30:29

From MSDN

Si Internet Explorer conoce el tipo de contenido especificado y no hay datos de Content-Disposition, Internet Explorer realiza una "examen de MIME," la exploración de los primeros 200 bytes del archivo para determinar si el la estructura del archivo coincide con cualquier tipo MIME conocido. Para obtener más información sobre el rastreo MIME, vea Detección de tipo MIME en Internet Explorer. Si el ojeado MIME detecta un tipo MIME conocido por Internet Explorer y el archivo ya no ha sido cargado por un mimefilter, Internet Explorer establece esa extensión de archivo antes de colocar el archivo en el caché local del navegador.

Por último, si no hay datos Content-Type o Content-Disposition y el MIME sniff no reconoce un tipo MIME conocido, la extensión de archivo se establece en la misma extensión que la URL utilizada para descargar el archivo.

Si el archivo está marcado como "content-disposition = attachment" en el encabezado HTTP, Internet Explorer trata el nombre del archivo de la URL como final y no lo cambia de nombre antes de colocarlo en la caché.

content-disposition = archivo adjunto es que la solución?!?

/Erling Damsgaard ApS DNS-TI

Fuente

2010-02-08 22:02:35 Famdam

No, eso no es, aunque parece que debería ser. –

Tuvimos este mismo problema incrustado en nuestra implementación ClickOnce de www.Qiqqa.com. Sospecho que tiene que ver con el "MIME Type sniffing" que IE hace cuando obtiene una aplicación/octet-stream, supongo que para proteger al usuario de cosas maliciosas.

De todos modos, para solucionar el problema, cambiamos el tipo de mime de nuestros archivos .deploy para que sean texto/normal, obviamente no es lo ideal, pero al mismo tiempo, no conozco un escenario en el que podamos tener un. implementar un archivo en nuestro servidor que un usuario buscaría fuera de ClickOnce.

Fuente

2010-10-20 19:58:55 Jimme

Para mí la solución a este problema estaba cambiando

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

 
Response.ContentType = "text/csv";

Fuente

2012-02-01 00:57:19 Maxx

necesita para asegurarse de que aparezca "no-store" en el encabezado antes de "no-cache". Ver esta publicación: http://blogs.msdn.com/b/ieinternals/archive/2009/10/03/internet-explorer-cannot-download-over-https-when-no-cache.aspx

Fuente

2013-09-10 21:32:18 LungFungus

esto a primera vista parece ser un golpe y una prueba; Pero funcionó para mí. Consulte también [La misma solución propuesta en el blog de MSDN] http://blogs.msdn.com/b/ieinternals/archive/2009/10/03/internet-explorer-cannot-download-over-https-when-no-cache. aspx? PageIndex = 2 –

IE8 no descargará un archivo con un mimo/tipo personalizado con UAC habilitado

Respuesta

Cuestiones relacionadas