В основному це відбувається тому, що веб-сайт говорить браузеру це зробити. Іноді це відбувається через те, що розробник веб-сайту вирішує, що вони хочуть такої поведінки, наприклад, звичайні на сайтах із обміном файлами. В іншому випадку це тому, що це стандартний варіант для будь-якого програмного забезпечення, яке вони використовують (наприклад, програмне забезпечення для форумів чи блогів). Іноді це тому, що розробник сайту не має уявлення, що вони роблять.
Content-Disposition
Це зазвичай тому, що сайт надсилає Content-Dispositionзаголовок у відповіді. В Зокрема, він може відправити або inlineабо attachment.
inline є типовим, якщо не вказано інше, і означає, що браузер відкриє файл у вікні браузера, якщо це зможе.
attachment означає завжди завантажувати файл, ніколи не намагайтеся відкрити його всередині браузера.
Якщо ви відкриєте інструменти для розробників веб-переглядача, ви побачите, що конкретне посилання надсилає такі заголовки відповідей:
Content-Disposition: attachment; filename="Schubert-Sonata-21-B-flat.pdf"
Content-Type: application/pdf
Це дозволяє браузеру завжди завантажувати ( attachment) файл і давати йому ім'я файлу за замовчуванням, Schubert-Sonata-21-B-flat.pdfа не робити його з URL. Крім того, він скаже браузеру (правильно), що це application/pdfфайл, але оскільки attachmentбраузер все ще за замовчуванням завантажує.
Деталі поводження з вбудованою обробкою
Коли а Content-Dispositionє вбудованим (або невизначеним), браузер спробує відкрити файл у вбудованому переглядачі за замовчуванням. Це працює лише тоді, коли браузер знає, що це за тип файлу, і браузер знає, як відкрити цей тип.
Виявлення типу
Тип файлу може бути визначений сервером із Content-Typeзаголовком. Наприклад, найбільш поширені вбудовані типи text/html, application/javascriptі text/css, складаючи три основні частини сучасного сайту. Ви також можете мати більше езотеричних типів application/pdf.
Інша можливість полягає в тому, як сервер вказано Content-Typeв application/octet-stream. Це найбільш загальний тип, і він повідомляє веб-переглядачу, що файл - це лише довільні дані, і тоді єдине, що може зробити браузер, - це завантажити його (теоретично - до цього ми дістанемося).
Коли Content-Typeсервер не визначається (а іноді навіть тоді, коли він є), браузер може виконувати те, що відомо, як нюхати, спробувати відгадати тип, читаючи файл і шукаючи шаблони.
Тип обробки
Отримавши файл із inlineневизначеним розпорядженням, браузеру потрібно спробувати відкрити його у веб-переглядачі, якщо це можливо. Для цього він дивиться на тип файлу, і якщо він розпізнає тип, він спробує відкрити його. Більшість браузерів відкриє будь-який text/тип у простому переглядачі тексту, спробує відобразити text/htmlяк веб-сторінку, може відкритись application/jsonу спеціальному переглядачі , виділеному синтаксисом тощо.
Тип application/octet-streamоброблявся спеціально. Оскільки він повинен бути самим загальним типом, що позначає довільний потік байтів, не повинно бути жодного обробника, який може застосовуватися до всіх файлів цього "типу". Наприклад, у Firefox це виявляється як неможливість встановити обробник за замовчуванням для application/octet-stream.
Деякі веб-сайти також використовували нестандартні типи. Я бачив application/force-downloadвикористаний - який закінчується як завантаження, тому що браузер не розпізнає і не знає, що ще робити з типом, але не користується особливою обробкою, яка application/octet-streamробить.
Трохи уроку історії
Щоб побачити, як обробляються файли PDF, ми можемо трохи заглибитися в історію веб-пошуку. Дивіться, раніше браузери не мали поняття, що таке PDF. Тож вони не змогли її відкрити. Але ми бачили, як PDF-файли відкриваються в браузерах задовго до того, як вбудовані переглядачі PDF були предметом, і як це працювало?
Раніше було можливо розширити функціональність браузера з набагато більшим контролем, ніж те, що ви можете зробити з обмеженими розширеннями / аддонами в наші дні. Вони були загалом відомі як плагіни . В Internet Explorer вони були елементами управління ActiveX; в Mozilla Firefox та пізніших Google Chrome вони були плагінами NPAPI. Ці плагіни здатні робити все, що може будь-яка інша програма, і можуть додатково зареєструвати себе як обробник для певного типу файлів, який в іншому випадку може бути не розпізнаний браузером. (До речі, пізніше це було виявлено величезний ризик для безпеки, і підтримка цих потужних плагінів поступово відпадала ...)
У дні плагінів ви б запустили і встановили Adobe Acrobat Reader, який потім встановив би плагін ActiveX або NPAPI, який би реєстрував application/pdfтип MIME і наказав браузеру відкривати ці типи вбудовано за допомогою плагіна.
Звичайно, після низки проблем із безпекою та продуктивністю, викликаними цими плагінами, основні виробники браузерів вирішили включити свої власні переглядачі PDF, припиняючи підтримку більшості плагінів. Єдиний, який ми все ще бачимо, це Adobe Shockwave Flash, який обробляє application/x-shockwave-flash.
Насправді для цього ще є деякі елементи управління, наприклад, у Firefox Preview in Firefoxопція все ще існує:
Раніше це дозволило б вибрати між декількома плагінами, які реєстрували цей тип. Наприклад, список зареєстрованих типів для Flash:
Ці дні також були перед багатьма медіа-підтримками, що надходили з HTML5. Це не лише PDF-файли - ваш веб-переглядач не мав би уявлення, як обробляти контейнер MP4 або відео H.264, не має ідеї, як відтворювати MP3-файл тощо, тощо. Ви побачили б плагіни, надані медіаплеєрами, такими як VLC або навіть Windows Media Player або веб-сайти вбудовували б медіаплеєр, вбудований у Flash.
Content-Type: application/octet-streamале це набагато рідше в ці дні.