Неизвестный тип файла MIME?

143

Должен ли я указывать тип MIME, если загруженный файл не имеет расширения? Другими словами, существует ли общий тип MIME по умолчанию?

Шимми Вайцхандлер
источник

Ответы:

187

Можно использовать application/octet-streamдля неизвестных типов.

RFC 2046 утверждает в разделе 4.5.1:

Подтип «поток октетов» используется для обозначения того, что тело содержит произвольные двоичные данные.

Бомба
источник
3
Фактически, согласно RFC, вы не должны отправлять информацию о типе с неизвестными данными. RFC-2046 определяет только известные типы, но RFC-7231 говорит вам, как обрабатывать неизвестные типы.
Сампо Саррала - codidact.org
@SampoSarrala Я читаю RFC-7231 немного иначе: «Если поле заголовка Content-Type отсутствует, получатель МОЖЕТ либо принять тип носителя« application / octet-stream »([RFC2046], раздел 4.5.1), либо изучить данные, чтобы определить их тип ". Я интерпретирую это так, как мы должны либо отправлять NO Content-Type, либо мы можем безопасно отправлять application / octet-stream по умолчанию, если мы не хотим, чтобы клиенты играли в игры на угадывание с проверкой содержимого.
Jpnh,
1
@Jpnh Да, верно. Заголовок Content-Type не должен присутствовать, если он неизвестен. Можно также отправить application / octet-stream, который в основном сообщает клиенту, что « вы не хотите отображать его прямо сейчас, но вместо этого сохраните эти байты в файл ». Это заставляет веб-клиенты предлагать сохранение файла. Вариант 1 == Ничего не знаю об этом файле. Вариант 2 == Содержимое файла нельзя описать с помощью mime или его следует сохранить только на диск. На практике верным будет любой вариант. Я должен был выбрать лучшую формулировку, чтобы избежать путаницы.
Сампо Саррала - codidact.org
4
«Произвольные двоичные данные» не являются «неизвестными». Используя application / octet-stream, вы сообщаете браузеру, что тип контента известен, это не текст или изображение, а произвольные двоичные данные, и в результате должны быть загружены в файл и, возможно, выполнены. Помимо того, что это ошибка, это дыра в безопасности, особенно с учетом едва заметных современных менеджеров загрузки. Правильный ответ - отсутствие заголовка типа содержимого. Если вы не знаете, что это за файл, браузер может знать его, поэтому дайте ему угадать, особенно если ему известен контекст использования (изображение, документ, сценарий, ...)
FF_Dev 01
@FF_Dev Я уверен, что это чушь. «Произвольные двоичные данные» не подразумевают «исполняемый»; нет причин, по которым браузер (или менеджер загрузок) должен считать application/octet-streamфайл исполняемым. И даже если браузер будет сознательно загрузить исполняемый файл, он не «возможно выполнить» без пользователя с просьбой; простая загрузка исполняемого файла не означает, что я хочу, чтобы он был запущен прямо сейчас. Если действительно есть браузер, который может application/octet-streamавтоматически запускать файлы при загрузке, сообщите нам, какой и как воспроизвести это поведение. Прямо сейчас я тебе не верю.
Марк Эмери
41

Ресурсы RFC:

Мы должны использовать RFC-7231 (семантика и контент HTTP / 1.1) в качестве ссылки вместо RFC-2046 (типы мультимедиа), потому что вопрос явно касался HTTP Content-Type.

Также RFC-2046 не дает четкого определения неизвестных типов, но RFC-7231 определяет.

Короткий ответ:

Не отправляйте MIME-тип для неизвестных данных.
Чтобы быть более ясным: вообще не используйте заголовок Content-Type.

Ссылки:

RFC-7231
Протокол передачи гипертекста (HTTP / 1.1): семантика и контент
3.1.1.5. Тип содержимого

Отправителю, который генерирует сообщение, содержащее тело полезной нагрузки, СЛЕДУЕТ
сгенерировать поле заголовка Content-Type в этом сообщении, если только
предполагаемый тип мультимедиа вложенного представления неизвестен
отправителю.

В этом разделе ясно сказано, что вы можете не указывать его, если вы этого не знаете наверняка. Он также сообщает, что получатель мог предположить, что тип - это приложение / октет-поток, но дело в том, что это также может быть что-то еще.

Что же тогда изменилось?

RFC-2046
4.5.1. Подтип октетного потока

Рекомендуемое действие для реализации, которая получает объект
"application / octet-stream", - просто предложить поместить данные
в файл с отменой любого Content-Transfer-Encoding или, возможно,
использовать его в качестве ввода для указанного пользователем процесс.

И, как уже было сказано выше:

RFC-7231
3.1.1.5. Тип содержимого

Если поле заголовка Content-Type отсутствует, получатель МОЖЕТ либо принять тип мультимедиа «приложение / октет-поток»
([RFC2046], раздел 4.5.1), либо проверить данные, чтобы определить их тип.

Вывод:

Если вы определяете его как «application / octet-stream», вы говорите, что знаете, что это «application / octet-stream».

Если вы не определяете его, вы говорите, что не знаете, что это такое, и оставляете решение на усмотрение получателя, и получатель может затем проверить, ходит ли он как утка и ...

Сампо Саррала - codidact.org
источник
1
Этот ответ заслуживает одобрения, поскольку он единственно верный. Кроме того, использование "application / octet-stream" по умолчанию делает большинство загрузок через браузер, что является дырой в безопасности, учитывая почти невидимые современные менеджеры загрузки.
FF_Dev 01
1
Это правильно для HTTP, но вопрос касается MIME в целом, а не HTTP. В электронной почте, например, правила совершенно другие. См. Также обсуждение предлагаемого дубликата stackoverflow.com/questions/12539058/…
tripleee
Я дал толчок по той же причине, однако я согласен с FF_Dev. Если намерение не является «приложением / октетным потоком» и запускать загрузку, существует потребность в «приложении / неизвестном». Было бы неплохо, если бы браузеры не пытались загрузить файл, если «Content-Disposition» не был установлен, но слишком много веб-сайтов беспорядочно загружают файлы, не задавая их имена для использования. Особенно банки.
justdan23
14

Я предпочитаю application/unknown, но результат будет точно такой же, какapplication/octet-stream

Лада
источник
17
Есть ли стандарт, позволяющий использовать application / unknown вместо application / octet-stream?
Хендрик Бруммерманн
3
Благодарность! application / unknown работает отлично, octet-stream выдает ошибку в chrome в моем образце png-файла!
fnkr
10
Зачем использовать файл .png как application/octet-streamили application/unknown? Есть причина, по которой они изобрели image/png.
Aidiakapi
10
@ jenson-button-event Это не имеет ничего общего с изобретением колеса. Тип MIME определяет ваше намерение. Если вы знаете, что то, что вы отправляете, должно быть изображением png, передайте эту информацию. Если байты случайно представляют собой jpeg, ваше приложение может предупредить вас, что это недопустимый png и что у вас есть ошибка где-то еще. Кроме того, не все приложения столь же надежны и отказоустойчивы, как браузер. Они предназначены для исправления ошибок программиста, но это далеко не единственная цель. Браузер - не единственное приложение, использующее типы MIME.
Aidiakapi 03
2
Какая у вас ссылка? неизвестный тип не предоставляет никакой информации о содержимом или состоянии файла, или даже если он является двоичным или текстовым, он слишком неясен для производственного кода, может быть приемлемым для небольшого проекта, поскольку, если mimetype файла не имеет обработчик в ОС, по сути, это загружаемый двоичный файл, а неизвестный тип - это известный дескриптор в ОС Windows, которому вы можете назначить действие (например, открытие неизвестных файлов с помощью блокнота). Хотя это плохая практика, вы можете использовать неизвестный тип в сочетании с этим, чтобы пропустить любое выполнение: /