Pada dasarnya, ini terjadi karena situs web memberi tahu browser untuk melakukannya. Kadang-kadang, itu karena pengembang situs web memutuskan mereka menginginkan perilaku ini, misalnya umum di situs berbagi file. Di lain waktu, itu karena itu adalah opsi default untuk perangkat lunak apa pun yang mereka gunakan (misalnya perangkat lunak forum atau blogging). Terkadang karena situs dev tidak tahu apa yang mereka lakukan.
Content-Disposition
Itu biasanya karena situs mengirimkan Content-Dispositionheader di respons. Secara khusus, dapat mengirim inlineatau attachment.
inline adalah default jika tidak ditentukan, dan berarti browser akan membuka file di dalam jendela browser jika bisa.
attachment artinya selalu mengunduh file, jangan pernah mencoba membukanya di dalam browser.
Jika Anda membuka alat pengembang browser Anda, Anda akan melihat bahwa tautan tertentu mengirimkan tajuk respons berikut:
Content-Disposition: attachment; filename="Schubert-Sonata-21-B-flat.pdf"
Content-Type: application/pdf
Ini memberi tahu browser untuk selalu mengunduh ( attachment) file, dan memberikannya nama file default Schubert-Sonata-21-B-flat.pdfdaripada menyimpulkannya dari URL. Selain itu, ia memberi tahu browser (dengan benar) bahwa itu adalah application/pdffile - tetapi karena itu attachmentperamban akan tetap default untuk diunduh.
Detail penanganan inline
Ketika a Content-Dispositioninline (atau tidak ditentukan), browser akan mencoba untuk membuka file di viewer bawaan bawaan. Ini hanya berfungsi ketika browser tahu jenis file apa itu, dan browser tahu cara membuka tipe file itu .
Jenis deteksi
Jenis file dapat ditentukan oleh server dengan Content-Typeheader. Misalnya, tipe inline yang paling umum adalah text/html, application/javascriptdan text/css, membentuk tiga bagian utama dari situs web modern. Anda juga dapat memiliki tipe esoterik yang lebih disukai application/pdf.
Kemungkinan lain adalah server telah ditentukan Content-Typedari application/octet-stream. Ini adalah tipe yang paling umum, dan ini memberi tahu browser bahwa file tersebut hanya data acak - di mana satu-satunya hal yang dapat dilakukan browser adalah mengunduhnya (secara teori - kita akan membahasnya).
Ketika a Content-Typetidak ditentukan oleh server (dan kadang-kadang bahkan ketika itu), browser dapat melakukan apa yang dikenal sebagai sniffing untuk mencoba menebak jenisnya dengan membaca file dan mencari pola.
Jenis penanganan
Setelah menerima file dengan inlinedisposisi yang tidak ditentukan, browser perlu mencoba membukanya di dalam browser jika memungkinkan. Untuk melakukan ini, ia melihat jenis file, dan jika ia mengenali jenisnya ia akan mencoba membukanya. Sebagian besar browser akan membuka text/jenis apa pun dalam penampil teks sederhana, akan mencoba merendernya text/htmlsebagai laman web, mungkin dibuka application/jsondi penampil khusus yang disorot sintaksis , dll.
Jenis application/octet-streamini ditangani secara khusus. Karena itu seharusnya menjadi tipe yang paling umum, yang menunjukkan aliran byte yang sewenang-wenang, seharusnya tidak ada penangan yang dapat berlaku untuk semua file dari "tipe" ini. Misalnya, di Firefox, ini bermanifestasi sebagai ketidakmampuan untuk mengatur penangan default untuk application/octet-stream.
Beberapa situs web juga menggunakan jenis yang tidak standar. Saya telah melihat yang application/force-downloaddigunakan - yang berakhir sebagai unduhan karena browser tidak mengenali atau tahu apa lagi yang harus dilakukan dengan jenisnya, tetapi tidak menikmati penanganan khusus yang application/octet-streamdilakukannya.
Sedikit pelajaran sejarah
Untuk melihat bagaimana PDF ditangani, kita dapat mempelajari sedikit sejarah web. Lihat, di masa lalu, browser tidak tahu apa itu PDF. Jadi mereka tidak bisa membukanya. Tetapi kita telah melihat PDF dibuka di browser jauh sebelum pemirsa PDF bawaan adalah hal yang penting, jadi bagaimana cara kerjanya?
Dulu dimungkinkan untuk memperluas fungsionalitas browser dengan kontrol yang jauh lebih banyak daripada apa yang dapat Anda lakukan dengan ekstensi / addon terbatas hari ini. Itu yang paling umum dikenal sebagai plugin . Di Internet Explorer, mereka adalah kontrol ActiveX; di Mozilla Firefox dan kemudian Google Chrome mereka adalah plugin NPAPI. Plugin ini mampu melakukan apa saja yang bisa dilakukan oleh program lain, dan juga dapat mendaftarkan diri sebagai penangan untuk jenis file tertentu yang mungkin tidak dikenali oleh browser. (Kebetulan, ini kemudian ditemukan sebagai risiko keamanan yang sangat besar dan dukungan untuk plugin yang kuat ini secara bertahap dijatuhkan ...)
Pada hari-hari plugin, Anda akan pergi dan menginstal Adobe Acrobat Reader, yang kemudian akan menginstal plugin ActiveX atau NPAPI yang akan mendaftarkan application/pdfjenis MIME dan memberitahu browser untuk membuka jenis-jenis inline menggunakan plugin.
Tentu saja, setelah sejumlah masalah keamanan dan kinerja yang disebabkan oleh plugin ini, vendor browser utama memutuskan untuk menggabungkan pemirsa PDF mereka sendiri sementara menghapus dukungan untuk sebagian besar plugin. Satu-satunya yang masih kita lihat adalah Adobe Shockwave Flash, yang menangani application/x-shockwave-flash.
Sebenarnya masih ada beberapa kontrol sisa untuk ini, misalnya di Firefox Preview in Firefoxopsi masih ada:
Di masa lalu, ini akan memungkinkan pilihan antara beberapa plugin yang mendaftarkan jenis itu. Misalnya, daftar jenis yang terdaftar untuk Flash:
Hari-hari itu juga sebelum banyak dukungan media yang datang dengan HTML5. Bukan hanya PDF - browser Anda tidak akan tahu bagaimana menangani wadah MP4 atau video H.264, tidak tahu cara memutar file MP3, dll., Dll. Anda akan melihat plugin yang disediakan oleh pemutar media seperti VLC atau bahkan Windows Media Player, atau situs web akan menyematkan pemutar media bawaan Flash.
Content-Type: application/octet-streamtapi itu jauh lebih jarang terjadi hari ini.