Cuando voy a ciertas direcciones de archivos PDF, Chrome descarga el PDF en lugar de abrirlo usando su visor de PDF incorporado. La página está en blanco blanco.

No hay ningún problema con mi configuración de Chrome: pruebo las direcciones de otros archivos PDF y Chrome se comporta como se esperaba (lo tengo configurado para usar el visor de PDF incorporado de Chrome). Pero cada vez que intento la misma dirección problemática, Chrome descarga el PDF y luego muestra una página en blanco.

Estoy usando Windows 10 y Chrome Version 63.0.3239.84 (Official Build) (64-bit).

Mi URL problemática específica esta vez está aquí (un resultado de búsqueda de Google).

Básicamente, esto sucede porque el sitio web le dice al navegador que lo haga. Ocasionalmente, es porque el desarrollador del sitio web decide que quiere este comportamiento, por ejemplo, común en los sitios para compartir archivos. Otras veces, es porque es una opción predeterminada para cualquier software que estén usando (por ejemplo, software de foro o blogging). A veces es porque el desarrollador del sitio no tiene idea de lo que están haciendo.

Content-Disposition

Eso suele ser porque el sitio envía un Content-Dispositionencabezado en la respuesta. Específicamente, puede enviar inlineo attachment.

inline es el valor predeterminado si no se especifica lo contrario, y significa que el navegador abrirá el archivo dentro de la ventana del navegador si es posible.

attachment significa descargar siempre el archivo, nunca intente abrirlo dentro del navegador.

Si abre las herramientas de desarrollador de su navegador, verá que ese enlace en particular envía los siguientes encabezados de respuesta:

Content-Disposition: attachment; filename="Schubert-Sonata-21-B-flat.pdf"
Content-Type: application/pdf

Esto le dice al navegador que siempre descargue ( attachment) el archivo y que le dé el nombre de archivo predeterminado en Schubert-Sonata-21-B-flat.pdflugar de inferirlo de la URL. Además, le dice al navegador (correctamente) que es un application/pdfarchivo, pero como es un attachmentnavegador, el navegador seguirá descargando de forma predeterminada.

Detalles de manejo en línea

Cuando a Content-Dispositionestá en línea (o no especificado), el navegador intentará abrir el archivo en el visor incrustado predeterminado. Esto solo funciona cuando el navegador sabe qué tipo de archivo es, y sabe cómo abrir ese tipo.

Detección de tipo

El servidor puede especificar el tipo de archivo con un Content-Typeencabezado. Por ejemplo, los tipos más comunes son la línea text/html, application/javascripty text/css, que constituyen las tres partes principales de una página web moderna. También puede tener más tipos esotéricos como application/pdf.

Otra posibilidad es que el servidor haya especificado una Content-Typede application/octet-stream. Este es el tipo más genérico, y le dice al navegador que el archivo es solo información arbitraria; en ese momento, lo único que puede hacer el navegador es descargarlo (en teoría, llegaremos a eso).

Cuando Content-Typeel servidor no especifica a (y a veces incluso cuando lo está), el navegador puede realizar lo que se conoce como rastreo para tratar de adivinar el tipo leyendo el archivo y buscando patrones.

Manejo de tipo

Al recibir un archivo con una inlinedisposición no especificada, el navegador debe intentar abrirlo dentro del navegador si es posible. Para hacer esto, observa el tipo de archivo y, si reconoce el tipo, intentará abrirlo. La mayoría de los navegadores abrirán cualquier text/tipo en un visor de texto simple, intentarán representarlo text/htmlcomo una página web, podrían abrirse application/jsonen un visor resaltado con sintaxis especial , etc.

El tipo application/octet-streamfue manejado especialmente. Como se supone que es el tipo más genérico, que denota una secuencia arbitraria de bytes, no se supone que haya ningún controlador que pueda aplicarse a todos los archivos de este "tipo". Por ejemplo, en Firefox, esto se manifiesta como una incapacidad para establecer el controlador predeterminado para application/octet-stream.

Algunos sitios web también han utilizado tipos no estándar. Lo he visto application/force-downloadusado, lo que termina como una descarga porque el navegador no reconoce o no sabe qué hacer con el tipo, pero no disfruta del manejo especial que application/octet-streamsí lo hace.

Para ver cómo se manejan los archivos PDF, podemos profundizar un poco en el historial web. Ver, en el pasado, los navegadores no tenían idea de qué es un PDF. Entonces no pudieron abrirlo. Pero hemos visto que los PDF se abren en los navegadores mucho antes de que los visores de PDF integrados fueran una cosa, entonces, ¿cómo funcionó?

Solía ​​ser posible ampliar la funcionalidad del navegador con mucho más control que lo que puede hacer con extensiones / complementos limitados en estos días. Esos eran más genéricamente conocidos como complementos . En Internet Explorer, eran controles ActiveX; en Mozilla Firefox y luego en Google Chrome, eran complementos NPAPI. Estos complementos eran capaces de hacer todo lo que cualquier otro programa podía, y además podían registrarse como un controlador para un tipo de archivo específico que de otro modo no sería reconocido por el navegador. (Por cierto, luego se descubrió que era un gran riesgo de seguridad y el soporte para estos poderosos complementos se fue eliminando gradualmente ...)

En los días de los complementos, irías e instalarías Adobe Acrobat Reader, que luego instalaría un complemento ActiveX o NPAPI que registraría el application/pdftipo MIME y le diría al navegador que abra esos tipos en línea usando el complemento.

Por supuesto, después de una serie de problemas de seguridad y rendimiento causados ​​por estos complementos, los principales proveedores de navegadores decidieron incorporar sus propios visores de PDF y eliminar la compatibilidad con la mayoría de los complementos. El único que aún vemos es Adobe Shockwave Flash, que maneja application/x-shockwave-flash.

En realidad todavía hay algunos controles sobrantes para esto, por ejemplo, en Firefox la Preview in Firefoxopción todavía existe:

En el pasado, esto habría permitido elegir entre múltiples complementos que registraron ese tipo. Por ejemplo, la lista de tipos registrados para Flash:

Esos días también fueron anteriores a la gran cantidad de soporte de medios que vino con HTML5. No se trataba solo de archivos PDF: su navegador no tendría idea de cómo manejar un contenedor MP4 o video H.264, ni idea de cómo reproducir un archivo MP3, etc., etc. Vería complementos provistos por reproductores multimedia como VLC o incluso Windows Media Player, o los sitios web incorporarían un reproductor multimedia integrado en Flash.

Encontré una explicación. Según una respuesta que encontré , parece que Chrome descargará un PDF si el tipo de contenido MIME no está configurado application/pdfsino 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 application/octet-streamtipo MIME predeterminado . Por razones de seguridad, la mayoría de los navegadores no permiten establecer una acción predeterminada personalizada para dichos recursos, lo que obliga al usuario a almacenarlo en el disco para usarlo".

Esto se debe a que el encabezado HTTPContent-Disposition especifica que el archivo es un archivo adjunto . Esto le indica al navegador que descargue el archivo, en lugar de abrirlo directamente.

Hay un complemento de Chrome que puede anular este comportamiento. La siguiente imagen es de las herramientas de desarrollador de Firefox: