В основном это происходит потому, что веб-сайт говорит браузеру сделать это. Иногда это происходит потому, что разработчик веб-сайта решает, что им нужно такое поведение, например, распространенное на сайтах для обмена файлами. В других случаях это потому, что это вариант по умолчанию для любого программного обеспечения, которое они используют (например, программное обеспечение для форумов или блогов). Иногда это происходит потому, что разработчик сайта понятия не имеет, что они делают.
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, который бы регистрировал MIME-тип application/pdf и велел браузеру открывать эти типы встроенным с помощью плагина.
Конечно, после ряда проблем с безопасностью и производительностью, вызванных этими плагинами, основные поставщики браузеров решили включить свои собственные средства просмотра PDF, одновременно прекратив поддержку большинства плагинов. Единственное, что мы все еще видим, это Adobe Shockwave Flash, который обрабатывает application/x-shockwave-flash .
На самом деле для этого еще есть некоторые элементы управления, например, Preview in Firefox опция предварительного просмотра в Firefox все еще существует:
В прошлом это позволяло выбирать между несколькими плагинами, которые зарегистрировали этот тип. Например, список зарегистрированных типов для Flash:
Эти дни были и до того, как большая поддержка СМИ пришла с HTML5. Это были не просто PDF-файлы - ваш браузер не знал бы, как обрабатывать контейнер MP4 или видео H.264, не знал, как воспроизводить MP3-файлы и т.д., И т.д. Вы бы увидели плагины, предоставляемые медиапроигрывателями, такими как VLC или даже Windows Media Player, или веб-сайты встроили бы медиаплеер, встроенный во Flash.
