Fondamentalmente, questo accade perché il sito web dice al browser di farlo. Occasionalmente, è perché lo sviluppatore del sito web decide di voler questo comportamento, ad esempio comune sui siti di condivisione di file. Altre volte, è perché è un'opzione predefinita per qualsiasi software in uso (ad es. Forum o software di blog). A volte è perché lo sviluppatore del sito non ha idea di cosa stiano facendo.
Content-Disposition
Questo di solito perché il sito invia Content-Dispositionun'intestazione nella risposta. In particolare, può inviare inlineo attachment.
inline è l'impostazione predefinita se non diversamente specificato e indica che il browser aprirà il file all'interno della finestra del browser se è in grado di farlo.
attachment significa scaricare sempre il file, non tentare mai di aprirlo all'interno del browser.
Se apri gli strumenti di sviluppo del tuo browser, vedrai che quel particolare link invia le seguenti intestazioni di risposta:
Content-Disposition: attachment; filename="Schubert-Sonata-21-B-flat.pdf"
Content-Type: application/pdf
Questo dice al browser di scaricare sempre ( attachment) il file e di assegnargli il nome file predefinito Schubert-Sonata-21-B-flat.pdfanziché dedurlo dall'URL. Inoltre, dice al browser (correttamente) che si tratta di un application/pdffile, ma dal momento che è un attachmentbrowser il download sarà comunque predefinito.
Dettagli di gestione in linea
Quando a Content-Dispositionè inline (o non specificato), il browser tenterà di aprire il file nel visualizzatore incorporato predefinito. Funziona solo quando il browser conosce il tipo di file e il browser sa come aprire quel tipo.
Rilevazione del tipo
Il tipo di file può essere specificato dal server con Content-Typeun'intestazione. Ad esempio, i tipi più comuni sono in linea text/html, application/javascripte text/css, che costituiscono le tre parti principali di un sito web moderno. Puoi anche avere più tipi esoterici come application/pdf.
Un'altra possibilità è che il server abbia specificato un Content-Typedi application/octet-stream. Questo è il tipo più generico e dice al browser che il file è solo un dato arbitrario - a quel punto l'unica cosa che il browser può fare è scaricarlo (in teoria - ci arriveremo).
Quando a Content-Typenon è specificato dal server (e talvolta anche quando lo è), il browser può eseguire ciò che è noto come sniffing per provare a indovinare il tipo leggendo il file e cercando schemi.
Tipo di gestione
Alla ricezione di un file con una inlinedisposizione o non specificata, il browser deve tentare di aprirlo all'interno del browser, se possibile. Per fare ciò, esamina il tipo di file e se riconosce il tipo tenterà di aprirlo. La maggior parte dei browser aprirà qualsiasi text/tipo in un semplice visualizzatore di testo, proverà a eseguire il rendering text/htmlcome pagina Web, potrebbe aprirsi application/jsonin uno speciale visualizzatore evidenziato dalla sintassi , ecc.
Il tipo è application/octet-streamstato gestito appositamente. Dal momento che si suppone che sia il tipo più generico, che indica un flusso arbitrario di byte, non si suppone che ci sia alcun gestore che possa essere applicato a tutti i file di questo "tipo". Ad esempio, in Firefox, questo si manifesta come incapacità di impostare il gestore predefinito per application/octet-stream.
Alcuni siti Web hanno utilizzato anche tipi non standard. Ho visto application/force-downloadusato - che finisce come un download perché il browser non riconosce o sa cos'altro fare con il tipo, ma non gode della speciale gestione che application/octet-streamfa.
Un po 'di lezione di storia
Per vedere come vengono gestiti i PDF, possiamo approfondire un po 'la cronologia web. Vedi, in passato i browser non avevano idea di cosa fosse un PDF. Quindi non potevano aprirlo. Ma abbiamo visto che i PDF venivano aperti nei browser molto prima che i visualizzatori PDF integrati fossero una cosa, quindi come funzionava?
In passato era possibile estendere le funzionalità del browser con un controllo molto maggiore di quello che si può fare con estensioni / componenti aggiuntivi limitati in questi giorni. Quelli erano genericamente conosciuti come plugin . In Internet Explorer, erano controlli ActiveX; in Mozilla Firefox e successivamente Google Chrome erano plugin NPAPI. Questi plugin erano in grado di fare tutto ciò che qualsiasi altro programma poteva, e potevano anche registrarsi come gestori per un tipo di file specifico che potrebbe altrimenti non essere riconosciuto dal browser. (Per inciso, questo è stato successivamente scoperto essere un enorme rischio per la sicurezza e il supporto per questi potenti plugin è stato gradualmente eliminato ...)
Ai giorni dei plug-in, avresti installato Adobe Acrobat Reader, che avrebbe quindi installato un plug-in ActiveX o NPAPI che avrebbe registrato il application/pdftipo MIME e avrebbe detto al browser di aprire quei tipi in linea usando il plug-in.
Naturalmente, dopo una serie di problemi di sicurezza e prestazioni causati da questi plug-in, i principali produttori di browser hanno deciso di incorporare i propri visualizzatori di PDF eliminando gradualmente il supporto per la maggior parte dei plug-in. L'unico che vediamo ancora è Adobe Shockwave Flash, che gestisce application/x-shockwave-flash.
In realtà ci sono ancora alcuni controlli rimanenti per questo, ad esempio in Firefox l' Preview in Firefoxopzione esiste ancora:
In passato, ciò avrebbe consentito la scelta tra più plugin che registravano quel tipo. Ad esempio, l'elenco dei tipi registrati per Flash:
Quei giorni erano anche molto prima del supporto mediatico fornito con HTML5. Non erano solo PDF: il tuo browser non avrebbe idea di come gestire un contenitore MP4 o video H.264, non avesse idea di come riprodurre un file MP3, ecc., Ecc. Vedresti plug-in forniti da lettori multimediali come VLC o anche Windows Media Player, oppure i siti Web incorporerebbero un lettore multimediale incorporato in Flash.
Content-Type: application/octet-streamma è molto meno comune in questi giorni.