Why debian doesn't recognize the audio/ogg mime type?
Всем привет! Столкнулся с проблемой, связанной с mime типами внутри моего докер контейнера. Использую в контейнере имедж python3:latest, который использует внутри себя buildpack-deps:jessie. Мне нужно проверять на входе в апи майм тайп файла. Но почему то файловая система в контейнере распознает миме тип файла как application/octet-stream, в то время, как моя хост машина распознает файл с его исходным миме типом - audio/ogg. Такое происходит именно с файлами типа audio/ogg. Я пытался найти ответ на данный вопрос, но тщетно. Перепробовал много чего - обновлял библиотеку миме типов, пытался добавить свой миме тип для audio/ogg - ничего не помогло.
В документации дебиана написано, что он сетит application/octet-stream миме тип по умолчанию, но я не могу пропускать такой файл в бд и хранить его на сервере... А миме тип audio/ogg важен. Какие могут быть варианты решения данной проблемы? #needyourhelp
если все так важно.. и время идет - попробуйте все тоже самое на ubuntu*... думаю не зависимо от результата, у вас появится букет новых вариантов для понимания
ps и да - как уже дважды сказано - и fs, и db - до фонаря ваши mime types
pps * - если это применимо к контейнерным образам - не забудьте экстразы подтянуть в юбунте, те что с проприетарными кодаками (гугл в помощь, инфы море)
При чем здесь http сервер? Директория хост машины синкается с директорией внутри контейнера - кладу туда файл с хоста, у файла на хосте mime-type=audio/ogg, внутри докер контейнера получаю информацию о файле - mime-type=application/octet-stream.
В итоге, файловая система имеет отношение и при чем прямое. Есть бд всех поддерживаемых миме типов. Я просматривал файлы, написанные на perl, которые и определяют миме тип файла при попадении в систему, но к сожалению - это ничего мне не дало.
Idobrodushniy,
еще раз - типы MIME это часть HTTP-протокола. И только так.
единственное, что может помочь определить MIME средствами файловой системы - это расширение файла.
awesomer, ты пришел сюда и не решаешь в целом проблемы вопроса, а утверждаешь то, в противоположном чему я абсолютно уверен. Не вижу смысла в этом споре, т.к. не вижу здесь стремления помочь в поиске ответа. По какой тогда причине происходит вот это ? " Директория хост машины синкается с директорией внутри контейнера - кладу туда файл с хоста, у файла на хосте mime-type=audio/ogg, внутри докер контейнера получаю информацию о файле - mime-type=application/octet-stream. "
Или директория может по хттп синкается ?
При чем здесь http сервер? Директория хост машины синкается с директорией внутри контейнера - кладу туда файл с хоста, у файла на хосте mime-type=audio/ogg, внутри докер контейнера получаю информацию о файле - mime-type=application/octet-stream.
если вы получаете файл по http - то MIME-тип вместе с файлом вам отдает сервер.
если вы получаете файл напрямую с диска (с файловой системы), то MIME-тип определяет ваше приложение.
если, как вы утверждаете, вы получаете непосредственно из файловой системы - то значит в докере или вне докера - используются разные таблицы соответствия.
в некоторых случаях приложение может использовать для этого общесистемную таблицу, где расширениям файлов сопоставлен тип. в некоторых случаях приложение делает это по своей внутренней таблице.
ты пришел сюда и не решаешь в целом проблемы вопроса, а утверждаешь то, в противоположном чему я абсолютно уверен. Не вижу смысла в этом споре, т.к. не вижу здесь стремления помочь в поиске ответа. По какой тогда причине происходит вот это ?
ну если ты считаешь что все знаешь - значит ты уже решил проблему.
Директория хост машины синкается с директорией внутри контейнера - кладу туда файл с хоста, у файла на хосте mime-type=audio/ogg, внутри докер контейнера получаю информацию о файле - mime-type=application/octet-stream. "
Или директория может по хттп синкается ?
еще раз - в третий раз:
в классической файловой системе нет типов MIME в принципе
максимум что там есть близкое - это расширение имени файла. именно оно и берется за основу, когда приложение пытается определить MIME автоматически.
есть специализированные вещи, типа "облачные хранилища" - S3, OpenSwift. Там ты когда кладешь файл, вместе с файлом можешь записать и тип MIME. и работает это все именно по http.
в классических файловых системах такого нет.
однако некоторые приложения могут использовать общесистемные таблицы соответствий между MIME и расширениями файлов
Filename suffixes: The system-wide mapping from file suffixes to MIME types is set in /etc/mime.types.
именно это я и написал.
filename suffix - это и есть "расширение файла" по-русски.
а /etc/mime.types - это и есть "общесистемная таблица соответствий расширения файла и типа MIME"
Окей, но в этой таблице есть ogg суфикс и файл имеет это расширение. Один и тот же файл, две разные ОС - разный результат. Файл не проходит никоим образом через http от момента проверки mime type на хосте и до момента попадения файла в систему контейнера.
Idobrodushniy,
ну во первых по вашей же ссылке есть еще и упоминание не об общесистемной таблице соответствий, а о таковой таблице у пользователя.
во вторых далеко не каждый софт использует эти таблицы, тот же Python содержит внутри себя в стандартной библиотеке свою собственную таблицу соответствий.
я использую вызов из консоли докера и из консоли хоста одной и той же команды - "file -i filename"
это совершенно неважно.
поздравляю вас! вы столкнулись с ситуацией, которая позволит вам понять - зачем нужен докер!
смысл докера как раз в том, чтобы изолировать подобные непредсказуемые ситуации.
какие-то вещи в вашей системе (хосте) и внутри докера - различаются.
после того, как вы поборете в докере - есть хорошая гарантия, что проблема более не повториться, если вы будете и в дальнейшем использовать это приложение только в докере. причем уже не важно где именно будет физически расположен этот контейнер.
awesomer, т.к. по вашим словам не fs не os не имеет отношения к миме, то по логике вещей, я должен буду просматривать миме тип по файлу, который лежит в системе в виде мап-таблицы. НО, также, предварительно команда file читает сам файл, где она находит так называемые "magic sniffs", какую то определенную последовательность байт, которая соответствует определенному миме типу, разве не так ? Соответственно, я читаю сам файл. Если бы мэтчинг миме типа был только по расширению файла - не было бы смысла в такой валидации.
НО, также, предварительно команда file читает сам файл, где она находит так называемые "magic sniffs", какую то определенную последовательность байт, которая соответствует определенному миме типу, разве не так ?
гипотетически такое может быть. но форматов файлов очень много. и предусмотреть автоматическое определение типа файла по его содержимому - непросто.
этого можно ожидать только от очень узкоспециализированных приложений.
например, просмотрщик картинок может автоматически определять JPEG/PNG/TIFF по содержимому.
но в общем случае - это невозможно. так как нет какого-то стандарта - где хранить в файле эту "магическую сигнатуру".
в общем случае используется именно расширение файла. внутрь файла для определения MIME никто не лезет.
awesomer, да, но в таком случае, выходит, что файл совершенно точно провалидировать абсолютно невозможно. Потому что можно засетить абсолютно любой суффикс для файла.
да, но в таком случае, выходит, что файл совершенно точно провалидировать абсолютно невозможно. Потому что можно засетить абсолютно любой суффикс для файла.
этого и не надо.
как только ты попытаешься отображать в виде картинки MP3-файл, содержащий на самом деле музыку - ты тут же получишь "ошибку декодирования JPEG". И никак не сможешь его отобразить, даже если MIME тебе однозначно укажет, что там JPEG.
Idobrodushniy, если речь об Amazon S3, то протокол передачи и получения файла позволяет явно указывать MIME. С именем хранимого в S3 файла тип MIME не связан.
Определение mime-типа никак не зависит от файловой системы. Браузер, например, определяет mime тип лишь по расширению файла. Ещё стоит посмотреть настройки веб-сервера.
Средний
