Questão Por que o Chrome às vezes faz o download de um PDF em vez de abri-lo? [duplicado]


Esta questão já tem uma resposta aqui:

Quando vou a determinados endereços de arquivos PDF, o Chrome baixa o PDF em vez de abri-lo usando o visualizador de PDF integrado. A página é então branca em branco.

Não há problema com minhas configurações do Chrome: eu experimento endereços de outros arquivos PDF e o Chrome se comporta como esperado (estou pronto para usar o visualizador de PDF integrado do Chrome). Mas toda vez que eu tento o mesmo endereço problemático, o Chrome faz o download do PDF e exibe uma página em branco.

Estou usando o Windows 10 e o Chrome Version 63.0.3239.84 (Official Build) (64-bit).

Minha URL problemática específica desta vez é Aqui (um resultado de pesquisa do Google).


107


origem




Respostas:


Basicamente, isso acontece porque o site informa ao navegador para fazer isso. Ocasionalmente, é porque o desenvolvedor do website decide que deseja esse comportamento, por exemplo, comum em sites de compartilhamento de arquivos. Outras vezes, é porque é uma opção padrão para qualquer software que esteja usando (por exemplo, fórum ou software de blog). Às vezes é porque o desenvolvedor do site não tem ideia do que está fazendo.


Content-Disposition

Isso geralmente é porque o site envia um Content-Disposition cabeçalho na resposta. Especificamente, ele pode enviar inline ou attachment.

inline é o padrão, se não especificado de outra forma, e significa que o navegador abrirá o arquivo na janela do navegador, se for possível.

attachment significa sempre baixar o arquivo, nunca tente abri-lo dentro do navegador.


Se você abrir as ferramentas de desenvolvedor do seu navegador, verá que esse link específico envia os seguintes cabeçalhos de resposta:

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

Isso diz ao navegador para sempre baixar (attachment) o arquivo, e para dar a ele o nome de arquivo padrão Schubert-Sonata-21-B-flat.pdf em vez de inferir a partir do URL. Além disso, ele diz ao navegador (corretamente) que é um application/pdf arquivo - mas desde que é um attachment o navegador ainda será o padrão para download.


Detalhes de manuseio em linha

Quando um Content-Disposition é inline (ou não especificado), o navegador tentará abrir o arquivo no visualizador incorporado padrão. Isso só funciona quando o navegador sabe que tipo de arquivo é, e o navegador sabe como abrir esse tipo.

Detecção de tipo

O tipo de arquivo pode ser especificado pelo servidor com um Content-Type cabeçalho. Por exemplo, os tipos inline mais comuns são text/html, application/javascript e text/css, compondo as três principais partes de um site moderno. Você também pode ter tipos mais esotéricos como application/pdf.

Outra possibilidade é o servidor ter especificado um Content-Type do application/octet-stream. Este é o tipo mais genérico, e diz ao navegador que o arquivo é apenas um dado arbitrário - ponto em que a única coisa que o navegador pode fazer é baixá-lo (em teoria - chegaremos a isso).

Quando um Content-Typenão é especificado pelo servidor (e às vezes até quando é), o navegador pode executar o que é conhecido como farejando para tentar adivinhar o tipo lendo o arquivo e procurando padrões.

Tipo de manuseio

Ao receber um arquivo com um inline ou disposição não especificada, o navegador precisa tentar abri-lo no navegador, se possível. Para fazer isso, ele analisa o tipo de arquivo e, se reconhecer o tipo, tentará abri-lo. A maioria dos navegadores abrirá text/ digite um visualizador de texto simples, tentará renderizar text/html como uma página da Web, pode aberto application/json em um visualizador especial com destaque de sintaxe, etc.

O tipo application/octet-stream foi tratado especialmente. Como é suposto ser o tipo mais genérico, denotando um fluxo arbitrário de bytes, não deve haver nenhum manipulador que possa ser aplicado a todos os arquivos desse "tipo". Por exemplo, no Firefox, isso se manifesta como uma incapacidade de definir o manipulador padrão para application/octet-stream.

Alguns sites também usam tipos não padrão. eu tenho visto application/force-download usado - que acaba sendo baixado porque o navegador não reconhece ou sabe o que fazer com o tipo, mas não gosta do manuseio especial que application/octet-stream faz.


Um pouco de aula de história

Para ver como os PDFs são manipulados, podemos nos aprofundar um pouco no histórico da web. Veja, no passado, os navegadores não tinham ideia do que é um PDF. Então eles não puderam abri-lo. Mas vimos PDFs sendo abertos em navegadores muito antes de os visualizadores de PDF internos serem uma coisa, então, como isso funcionava?

Costumava ser possível estender a funcionalidade do navegador com muito mais controle do que o que você pode fazer com extensões / complementos limitados nos dias de hoje. Aqueles eram mais genericamente conhecidos como plugins. No Internet Explorer, eles eram controles ActiveX; no Mozilla Firefox e, mais tarde, no Google Chrome, eles eram plugins NPAPI. Esses plug-ins eram capazes de fazer tudo o que qualquer outro programa pudesse fazer e, além disso, poderiam se registrar como um manipulador de um tipo de arquivo específico que, de outra forma, não seria reconhecido pelo navegador. (Incidentalmente, isso foi mais tarde encontrado para ser um enorme risco de segurança e suporte para esses plugins poderosos foi gradualmente caiu ...)

Nos dias de plugins, você iria instalar o Adobe Acrobat Reader, que instalaria um plugin ActiveX ou NPAPI que registraria o application/pdf Tipo MIME e diga ao navegador para abrir esses tipos em linha usando o plugin.

É claro que, após vários problemas de segurança e desempenho causados ​​por esses plug-ins, os principais fornecedores de navegador decidiram incorporar seus próprios visualizadores de PDF ao mesmo tempo em que eliminavam o suporte à maioria dos plug-ins. O único que ainda vemos é o Adobe Shockwave Flash, que lida com application/x-shockwave-flash.

Ainda há alguns controles restantes para isso, por exemplo no Firefox o Preview in Firefox opção ainda existe:

Screenshot of option

No passado, isso permitia a escolha entre vários plugins que registravam esse tipo. Por exemplo, a lista de tipos registrados para o Flash:

Screenshot of registered types

Esses dias também foram anteriores ao suporte de mídia que acompanha o HTML5. Não foram apenas PDFs - seu navegador não teria idéia de como lidar com um contêiner MP4 ou vídeo H.264, nem idéia de como reproduzir um arquivo MP3, etc., etc. Você veria plugins fornecidos por players de mídia como o VLC. ou até mesmo o Windows Media Player ou sites incorporariam um media player construído em Flash.


135



Ocasionalmente, isso também acontece quando o servidor define Content-Type: application/octet-stream mas isso é muito menos comum nos dias de hoje. - Michael Hampton
A razão pela qual os valores "inline" e "attachment" são usados ​​é porque o Content-Disposition foi originalmente especificado para o email MIME, onde esses valores são muito mais apropriados :) - hobbs
@hobbs: Quase um estudo de caso em terminologia específica de domínio em tecnologia reutilizável quando algo mais abstrato serve ^ _ ^ - Lightness Races in Orbit


Eu encontrei uma explicação. De acordo com um resposta que encontrei, parece que o Chrome baixará um PDF se o tipo de conteúdo MIME não estiver definido application/pdf mas sim um "tipo MIME incorreto ou genérico", application/octet-stream.

além disso, "A maioria dos servidores da Web envia recursos do tipo desconhecido usando o padrão application/octet-stream Tipo MIME. Por motivos de segurança, a maioria dos navegadores não permite definir uma ação padrão personalizada para esses recursos, forçando o usuário a armazená-lo em disco para usá-lo. "


23



Na verdade - essa lógica substitui a disposição do conteúdo e, portanto, é importante lembrar. - Lightness Races in Orbit
@LightnessRacesinOrbit Não tanto sobrepor a disposição como ele dá ao navegador um tipo que não pode fazer nada com (exceto o sniffing) diferente de salvar no disco. Concedido, o efeito visível é o mesmo. - Bob
@Bob: Ok, sim, essa é uma interpretação justa - Lightness Races in Orbit


Isto é devido ao HTTP Content-Disposition cabeçalho especificando que o arquivo é um anexo. Isso instrui o navegador a baixar o arquivo, em vez de abri-lo diretamente.

Há um complemento do Chrome que pode substituir esse comportamento. A imagem a seguir é das ferramentas de desenvolvedor do Firefox:

HTTP request as seen in the Firefox development tools


20



Posso perguntar se existe também um add-on similar do Firefox? - davyjones
@davyjones Você pode. Para que você não precise perguntar se há um complemento do Firefox, Aqui um é. - wizzwizz4
Esse plugin não parece mais funcionar - Paul Slocum