Basicamente, isso acontece porque o site diz ao navegador para fazê-lo. Ocasionalmente, é porque o desenvolvedor do site 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 eles estejam usando (por exemplo, software de fórum ou blog). Às vezes, é porque o desenvolvedor do site não tem ideia do que está fazendo.
Content-Disposition
Isso geralmente ocorre porque o site envia um Content-Dispositioncabeçalho na resposta. Especificamente, ele pode enviar um inlineou 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 puder.
attachment significa sempre baixar o arquivo, nunca tente abri-lo dentro do navegador.
Se você abrir as ferramentas de desenvolvedor do 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 instrui o navegador a sempre baixar ( attachment) o arquivo e a fornecer o nome de arquivo padrão, em Schubert-Sonata-21-B-flat.pdfvez de deduzi-lo da URL. Além disso, ele diz ao navegador (corretamente) que é um application/pdfarquivo - mas, como é attachmento navegador, o download ainda será o padrão.
Detalhes de manuseio em linha
Quando a Content-Dispositionestá embutido (ou não especificado), o navegador tenta abrir o arquivo no visualizador incorporado padrão. Isso funciona apenas quando o navegador sabe qual é o tipo de arquivo e sabe como abrir esse tipo.
Detecção de tipo
O tipo de arquivo pode ser especificado pelo servidor com um Content-Typecabeçalho. Por exemplo, os tipos em linha mais comuns são text/html, application/javascripte text/css, tornando-se as três partes principais de um site moderno. Você também pode ter tipos mais esotéricos como application/pdf.
Outra possibilidade é que o servidor tenha especificado um Content-Typede application/octet-stream. Esse é o tipo mais genérico e informa ao navegador que o arquivo é apenas um dado arbitrário; nesse momento, a única coisa que o navegador pode fazer é fazer o download (em teoria - vamos chegar a esse ponto).
Quando a Content-Typenão é especificado pelo servidor (e às vezes até quando), o navegador pode executar o que é conhecido como sniffing para tentar adivinhar o tipo lendo o arquivo e procurando padrões.
Manipulação de tipo
Ao receber um arquivo com uma inlinedisposição ou 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á qualquer text/tipo em um visualizador de texto simples, tentará renderizar text/htmlcomo uma página da web, poderá abrir application/jsonem um visualizador especial destacado por sintaxe , etc.
O tipo application/octet-streamfoi tratado especialmente. Como ele deve ser do 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 usaram tipos não padrão. Eu já vi application/force-downloadusado - que acaba como um download porque o navegador não reconhece ou sabe o que mais fazer com o tipo, mas não possui o tratamento especial que application/octet-streamfaz.
Um pouco de uma lição de história
Para ver como os PDFs são manipulados, podemos nos aprofundar um pouco na história da web. Veja, no passado, os navegadores não tinham idéia do que é um PDF. Então eles não puderam abrir. Mas já vimos PDFs sendo abertos nos navegadores muito antes de os visualizadores de PDF integrados, então como isso funcionou?
Antes, era possível estender a funcionalidade do navegador com muito mais controle do que o que você pode fazer com extensões / addons limitados atualmente. Esses eram conhecidos genericamente como plugins . No Internet Explorer, eles eram controles ActiveX; no Mozilla Firefox e, mais tarde, no Google Chrome, eram plugins NPAPI. Esses plug-ins eram capazes de fazer tudo o que qualquer outro programa podia e, além disso, podiam se registrar como manipulador de um tipo de arquivo específico que, de outra forma, não seria reconhecido pelo navegador. (Aliás, isso foi considerado um grande risco de segurança e o suporte a esses plugins poderosos foi diminuindo gradualmente ...)
Nos dias dos plug-ins, você instalava o Adobe Acrobat Reader, que instalava um plug-in ActiveX ou NPAPI que registrava o application/pdftipo MIME e dizia ao navegador para abrir esses tipos on-line usando o plug-in.
Obviamente, depois de vários problemas de segurança e desempenho causados por esses plug-ins, os principais fornecedores de navegadores decidiram incorporar seus próprios visualizadores de PDF enquanto eliminavam o suporte para a maioria dos plug-ins. O único que ainda vemos é o Adobe Shockwave Flash, que suporta application/x-shockwave-flash.
Na verdade, ainda existem alguns controles restantes para isso, por exemplo, no Firefox, a Preview in Firefoxopção ainda existe:
No passado, isso permitiria a escolha entre vários plugins que registravam esse tipo. Por exemplo, a lista de tipos registrados para o Flash:
Esses dias também foram antes de grande parte do suporte de mídia fornecido com o HTML5. Não eram apenas PDFs - seu navegador não teria idéia de como lidar com um contêiner MP4 ou vídeo H.264, como reproduzir um arquivo MP3, etc. etc. Você veria plugins fornecidos por players de mídia como o VLC ou mesmo o Windows Media Player, ou sites incorporariam um media player embutido no Flash.
Content-Type: application/octet-streammas isso é muito menos comum atualmente.