Cuando voy a ciertas direcciones de archivos PDF, Chrome descarga el PDF en lugar de abrirlo utilizando su visor de PDF incorporado. La página aparece entonces en blanco.
No hay ningún problema con la configuración de Chrome: Pruebo con direcciones de otros archivos PDF y Chrome se comporta como es de esperar (lo tengo configurado para usar el visor de PDF integrado de Chrome). Pero cada vez que pruebo la misma dirección problemática, Chrome descarga el PDF y luego muestra una página en blanco.
Utilizo Windows 10 y Chrome Versión 63.0.3239.84 (compilación oficial) (64 bits).
Mi URL problemática específica esta vez es aquí (un resultado de búsqueda de Google).
Content-Disposition
Content-Disposition
en la respuesta. En concreto, puede enviar inline
o attachment
.
inline
es el valor por defecto si no se especifica lo contrario, y significa que el navegador abrirá el archivo dentro de la ventana del navegador si puede hacerlo.
attachment
significa descargar siempre el archivo, nunca intentar abrirlo dentro del navegador.Si abre las herramientas de desarrollo de su navegador, verá que ese enlace en concreto envía las siguientes cabeceras de respuesta:
Content-Disposition: attachment; filename="Schubert-Sonata-21-B-flat.pdf"
Content-Type: application/pdf
attachment
) el archivo, y que le dé el nombre de archivo por defecto de Schubert-Sonata-21-B-flat.pdf
en lugar de deducirlo de la URL. Además, indica al navegador (correctamente) que se trata de un archivo application/pdf
- pero como es un attachment
el navegador seguirá descargándolo por defecto.Cuando una Content-Disposition
es inline (o no especificada), el navegador intentará abrir el archivo en el visor incrustado por defecto. Esto sólo funciona cuando el navegador sabe qué tipo de archivo es, y el navegador sabe cómo abrir ese tipo.
El tipo de archivo puede ser especificado por el servidor con una cabecera Content-Type
. Por ejemplo, los tipos en línea más comunes son text/html
, application/javascript
y text/css
, que constituyen las tres partes principales de un sitio web moderno. También puede haber tipos más esotéricos como application/pdf
.
Otra posibilidad es que el servidor haya especificado un Content-Type
de application/octet-stream
. Este es el tipo más genérico, y le dice al navegador que el archivo es sólo datos arbitrarios - en este punto lo único que el navegador puede hacer es descargarlo (en teoría - llegaremos a eso).
Cuando un Content-Type
no es especificado por el servidor (y a veces incluso cuando lo es), el navegador puede realizar lo que se conoce como sniffing para intentar adivinar el tipo leyendo el fichero y buscando patrones.
inline
o no especificada, el navegador necesita intentar abrirlo dentro del navegador si es posible. Para hacer esto, mira el tipo de fichero, y si reconoce el tipo intentará abrirlo. La mayoría de los navegadores abrirán cualquier tipo text/
en un simple visor de texto, intentarán renderizar text/html
como una página web, podrían abrir application/json
en un visor especial de sintaxis resaltada, etc...
El tipo application/octet-stream
ha sido tratado de forma especial. Ya que se supone que es el tipo más genérico, denotando un flujo arbitrario de bytes, no se supone que haya ningún manejador que pueda aplicarse a todos los archivos de este "tipo". Por ejemplo, en Firefox, esto se manifiesta como una incapacidad para establecer el manejador por defecto para application/octet-stream
.
Algunos sitios web también han utilizado tipos no estándar. He visto usar application/force-download
- que termina como una descarga porque el navegador no reconoce o no sabe qué más hacer con el tipo, pero no disfruta del manejo especial que hace application/octet-stream
.Para ver cómo se manejan los PDF, podemos ahondar un poco en la historia de la web. En el pasado, los navegadores no tenían ni idea de lo que era un PDF. Así que no podían abrirlo. Pero hemos visto cómo se abrían los PDF en los navegadores mucho antes de que existieran los visores de PDF integrados.
Antes era posible ampliar la funcionalidad de los navegadores con mucho más control del que se puede tener hoy en día con extensiones/addons limitados. Se conocían genéricamente como plugins. En Internet Explorer, eran controles ActiveX; en Mozilla Firefox y más tarde en Google Chrome eran plugins NPAPI. Estos plugins eran capaces de hacer todo lo que podía hacer cualquier otro programa y, además, podían registrarse como gestores de un tipo de archivo específico que, de otro modo, no sería reconocido por el navegador. (Por cierto, más tarde se descubrió que esto suponía un enorme riesgo para la seguridad y el soporte para estos potentes plugins se fue retirando gradualmente...).
En la época de los plugins, se instalaba Adobe Acrobat Reader, que a su vez instalaba un plugin ActiveX o NPAPI que registraba el tipo MIME application/pdf
e indicaba al navegador que abriera esos tipos en línea utilizando el plugin.
Por supuesto, tras una serie de problemas de seguridad y rendimiento causados por estos plugins, los principales proveedores de navegadores decidieron incorporar sus propios visores de PDF y eliminar gradualmente la compatibilidad con la mayoría de los plugins. El único que aún vemos es Adobe Shockwave Flash, que maneja application/x-shockwave-flash
.
De hecho, todavía quedan algunos controles para esto, por ejemplo, en Firefox la opción Preview in Firefox
todavía existe:
Antes, esto permitía elegir entre varios plugins que registraban ese tipo. Por ejemplo, la lista de tipos registrados para Flash:
Aquellos días también fueron anteriores a la mayor parte del soporte multimedia que llegó con HTML5. No se trataba sólo de PDF: tu navegador no tenía ni idea de cómo manejar un contenedor MP4 o un vídeo H.264, ni de cómo reproducir un archivo MP3, etc., etc. Aparecían plugins de reproductores multimedia como VLC o incluso Windows Media Player, o los sitios web incrustaban un reproductor multimedia integrado en Flash.
He encontrado una explicación. Según una respuesta que encontré, parece que Chrome descargará un PDF si el tipo de contenido MIME no está configurado como application/pdf
sino como un "tipo MIME incorrecto o genérico", application/octet-stream
.
Además, "La mayoría de los servidores web envían recursos de tipo desconocido utilizando el tipo MIME por defecto application/octet-stream
. Por razones de seguridad, la mayoría de los navegadores no permiten establecer una acción personalizada por defecto para dichos recursos, obligando al usuario a almacenarlo en disco para poder utilizarlo."
Esto se debe a que la cabecera HTTP Content-Disposition
especifica que el archivo es un adjunto. Esto indica al navegador que descargue el archivo, en lugar de abrirlo directamente.
Existe un complemento para Chrome que puede anular este comportamiento La siguiente imagen procede de las herramientas para desarrolladores de Firefox: