type txt octet content application javascript google-chrome

javascript - txt - Recurso interpretado como Documento pero transferido con aplicación tipo MIME/zip



mime type pdf (12)

En el encabezado de su solicitud, ha enviado Content-Type: text/html que significa que desea interpretar la respuesta como HTML. Ahora, si incluso el servidor le envía archivos PDF, su navegador intenta comprenderlo como HTML. Ese es el problema. Estoy buscando para ver cuál es la razón. :)

Con Chrome 12.0.742.112, si redirijo los siguientes encabezados:

HTTP/1.1 302 Found Location: http://0.0.0.0:3000/files/download.zip Content-Type: text/html; charset=utf-8 Cache-Control: no-cache X-Ua-Compatible: IE=Edge X-Runtime: 0.157964 Content-Length: 0 Server: WEBrick/1.3.1 (Ruby/1.9.2/2011-02-18) Date: Tue, 05 Jul 2011 18:42:25 GMT Connection: Keep-Alive

Que si se sigue, devuelve el siguiente encabezado:

HTTP/1.1 200 OK Last-Modified: Tue, 05 Jul 2011 18:18:30 GMT Content-Type: application/zip Content-Length: 150014 Server: WEBrick/1.3.1 (Ruby/1.9.2/2011-02-18) Date: Tue, 05 Jul 2011 18:44:47 GMT Connection: Keep-Alive

Chrome no redirigirá ni cambiará la página anterior, solo informará la siguiente advertencia en la consola:

Recurso interpretado como Documento pero transferido con aplicación tipo MIME / zip.

El proceso funciona correctamente en Firefox, y también funciona bien en Chrome si abro una pestaña nueva y voy directamente a http://0.0.0.0:3000/files/download.zip . ¿Estoy haciendo algo mal, o es esto un error / peculiaridad de Chrome?

En mi caso, el nombre del archivo era demasiado largo y recibí el mismo error. Una vez acortado por debajo de 200 caracteres funcionó bien. (¿límite podría ser 250?)

Estaba experimentando el mismo problema con un administrador de descargas que creé. El problema que tuve fue que el nombre del archivo era demasiado largo y la extensión cortada.

Ejemplo: nombre de archivo: protocolos organizativos y otras cosas que son importantes.pd

<?php header("Content-Disposition: attachment; filename=$File_Name"); ?>

Solución: se aumentó el campo de la base de datos MySQL a 255 para almacenar el nombre del archivo y se realizó una verificación de longitud antes de guardar el blob. Si la longitud> 255 lo recorta a 250 y agrega la extensión de archivo.

Este problema volvió a aparecer en la versión de Chrome 61. Pero parece que está arreglado en Chrome 62.

Tengo una RewriteRule como a continuación

RewriteRule ^/ShowGuide/?$ https://<website>/help.pdf [L,NC,R,QSA]

Con Chrome 61, el PDF no se abría, en la consola se mostraba el mensaje

"Resource interpreted as Document but transferred with MIME type application/pdf: "

Intentamos agregar el tipo MIME en la regla de reescritura como se muestra a continuación, pero no fue de ayuda.

RewriteRule ^/ShowGuide/?$ https://<website>/help.pdf [L,NC,R,QSA, t:application/pdf]

Actualicé mi Chrome a la última versión 62 y comenzó a mostrar el PDF nuevamente. Pero el mensaje todavía está allí en la consola.

Con todos los demás navegadores, estaba / está funcionando bien.

Experimenté este problema al servir un archivo PDF (aplicación tipo MIME / pdf) y lo resolví configurando el encabezado Content-Disposition, por ejemplo:

Content-Disposition: attachment; filename=foo.pdf

Espero que ayude.

Lo he arreglado ... simplemente abriendo una nueva pestaña.

Por qué no funcionaba No estoy del todo seguro, pero podría tener algo que ver con la forma en que Chrome trata con múltiples descargas en una página, tal vez pensó que eran spam y simplemente las ignoró.

Me encontré con este mismo problema hoy con la versión de Chrome 30.0.1599.66 con mi aplicación node.js / express.js.

Los encabezados son correctos, express los establece correctamente automáticamente, funciona en otros navegadores como se indica, el atributo html 5 ''descargar'' no se resuelve, lo que resolvió está yendo a la configuración avanzada de Chrome y marcando la casilla "Preguntar dónde guardar" cada archivo antes de descargar ".

Después de eso, no se informó el error "Recurso interpretado como documento ...." como en el título de este problema, por lo que parece que nuestro código de servidor es correcto, es Chrome quien informa incorrectamente ese error en la consola cuando está configurado para guardar archivos a una ubicación de forma automática.

Me encontré con esto cuando asigné src = "image_url" en un iframe. Parece que iframe lo interpreta como un documento pero no lo es. Es por eso que muestra una advertencia.

No pude encontrar en ninguna parte solo una explicación del mensaje en sí misma. Aquí está mi interpretación.

Por lo que yo entiendo, Chrome esperaba algún material que posiblemente podría mostrar (un documento ), pero obtuvo algo que no pudo mostrar (o algo que se le dijo que no mostrara).

Esta es una cuestión de cómo se declaró el documento en el nivel de página HTML en href (ver el atributo de download en el mensaje de Roy) y cómo se declara dentro de la respuesta del servidor por medio de encabezados HTTP (en particular Content-Disposition ). Esta es una cuestión de contrato , en lugar de esperanza y expectativa.

Para continuar en el camino de Evan, lo he experimentado:

Content-type: application/pdf Content-disposition: attachment; filename=some.pdf

es inconsistente con:

<a href=''some.pdf''>

Chrome llorará Recurso interpretado como documento pero transferido ...

En realidad, la disposición del archivo adjunto solo significa esto: el navegador no interpretará el enlace, sino que lo almacenará en algún lugar para otros fines ocultos. Aquí arriba, falta la download junto a href , o Content-disposition debe eliminarse de los encabezados. Depende de si queremos que el navegador muestre el documento o no.

Espero que esto ayude.

Recibí este error porque estaba sirviendo desde mi sistema de archivos. Una vez que comencé con un servidor http, Chrome pudo resolverlo.

Tuve este problema en un proyecto de sitio web ASP. Agregar un encabezado "Content-Length" hizo que las descargas comenzaran a funcionar nuevamente en Chrome.