Why does Laravel's getMimeType() method identify a file as "application/octet-stream" when the file has the type attribute of "audio/mpeg"?

Question

I'm trying to upload a MP3 file to a Laravel application and have ran into an issue where even though the file has an attribute set to "audio/mpeg" it is uploaded as a "application/octet-stream" (.bin) file. When I try to die and dump the file on the server-side code with:

dd($request->file('file'));

I get:

UploadedFile {#187 ▼
  -test: false
  -originalName: "CUS12309821-20-AUG-2016-13-48-13.mp3"
  -mimeType: "audio/mpeg"
  -size: 47000471
  -error: 0
  path: "/private/var/folders/c7/6ws0lxy95dd_lhz1k067_zkc0000gn/T"
  filename: "phpyZCsbU"
  basename: "phpyZCsbU"
  pathname: "/private/var/folders/c7/6ws0lxy95dd_lhz1k067_zkc0000gn/T/phpyZCsbU"
  extension: ""
  realPath: "/private/var/folders/c7/6ws0lxy95dd_lhz1k067_zkc0000gn/T/phpyZCsbU"
  aTime: 2016-09-20 12:56:00
  mTime: 2016-09-20 12:56:00
  cTime: 2016-09-20 12:56:00
  inode: 4565593
  size: 47000471
  perms: 0100600
  owner: 501
  group: 20
  type: "file"
  writable: true
  readable: true
  executable: false
  file: true
  dir: false
  link: false
}

Look at how when I use this method, it does indeed say that the file attribute for mimeType is the correct "audio/mpeg" format. However when I call the getMimeType() method on the file after it's uploaded, I get:

"application/octet-stream"

Here's the code in the routed method:

/**
 * Store a newly created resource in storage.
 *
 * @param  \Illuminate\Http\Request  $request
 * @return \Illuminate\Http\Response
 */
public function store(Request $request)
{
    $file = $request->all();

    $filePath = Storage::putFile('file', $request->file('files'));

    dd($request->file('file')->getMimeType());

    $file['path'] = Storage::url($filePath);
    $file['size'] = Storage::size($filePath);
    $file['type'] = $request->file('file')->getMimeType();

    return $file;
}

This problem is seemingly unique in that I'm using the Laravel framework, where others with this problem are using vanilla PHP. Additionally, the excel file others may us may have reported itself as a application/octet-stream instead of an excel file. Finally, I believe this may be a issue with the guess() method, which is called by the getMethodType(). Someone with more Laravel experience could probably confirm this.

Barnes

Possible duplicate of Why am I getting mime-type of .csv file as "application/octet-stream"? – Hooknose

I disagree. I'm using the Laravel framework, where he's using vanilla PHP. Additionally, his excel file may have reported itself as a application/octet-stream instead of an excel file. Finally, I believe this may be a issue with the guess() method, which is called by the getMethodType(). Someone with more Laravel experience could probably confirm this. – Barnes

I just proved that this is a Laravel issue and not a PHP upload mechanism issue by creating a vanilla PHP upload form and uploading the file. The output from var_dump($_FILES) was: array(1) { ["fileToUpload"]=> array(5) { ["name"]=> string(15) "CUS12309821-20-AUG-2016-13-48-13.mp3" ["type"]=> string(10) "audio/mpeg" ["tmp_name"]=> string(66) "/private/var/folders/c7/6ws0lxy95dd_lhz1k067_zkc0000gn/T/phpf6cwMf" ["error"]=> int(0) ["size"]=> int(40340291) } } – Barnes

@Kirkland: I have a similar issue and my question is here: #65868917. How did you finally resolve your issue? Of course I could use the php functions instead of the Laravel validator, but this is not elegant at all. I rather would like to see that Laravel makes it right and no mistake. What do you think? – Anagnorisis

Answer 1

The UploadedFile object is ultimately extended from Symfony\Component\HttpFoundation\File\UploadedFile which get/sets the mimeType from The type of the file as provided by PHP.

To access that mimeType you would need to call $file->getClientMimeType()

However in the Symfony docblock for the function it suggests:

The client mime type is extracted from the request from which the file was uploaded, so it should not be considered as a safe value.

For a trusted mime type, use getMimeType() instead (which guesses the mime type based on the file content).

In your case however $file->getMimeType() which should be trusted and guesses the mime type from the contents, however it returns something as if it cannot determine the mime type, being "application/octet-stream"

Additional information

To help you decide. Basically getClientMimeType() would return the mime type that was set by the browser.

The getMimeType call guesses the mime type using two different techniques that I can see:

1. Using a binary mime type technique looking at the output of the following command file -b --mime %s 2>/dev/null if it is supported.

2. The second technique is using the finfo_open command if it does exist inside php.

If both 1. and 2. exists on your system, from what I see 2. will take preference, and 1. will be the fallback.

I personally would favour the results from getMimeType() for security. However, it would be another interesting question to ask "How reliable is browser mime type detection, and what techniques are used" :-)

Updated example

I include an example for you.

For me doing a check on a "DropboxInstalled.dmg", here are my results:

1. using file -b --mime DropboxInstaller.dmg from a commandline (terminal) returns application/octet-stream

2. using finfo_open functionality

$finfo = new \finfo(FILEINFO_MIME_TYPE);
echo $finfo->file('./DropboxInstaller.dmg');

returns application/x-iso9660-image

Nygaard

Very interesting! I'm still thinking through what you've mentioned, I think it's ultimately going to be the answer though. I would like to ask what you think about the risks associated with using the getClientMimeType() method. So long as the file extension and mime type meet, and it's marked as non-executable, what risks do you thing would be exist? – Barnes

I will rather add to my answer instead of an unformatted comment. – Nygaard

If this needs to be it's own new question, let me know. As a middle ground alternative between these two, what do you think about using ID3 tags? – Barnes

You might get more mileage if it was its own question. You do not mention your platform, and if you have managed to seen which guessing method your platfrom would default to. You can look inside vendor/symfony/http-foundation/File/MimeType/MimeTypeGuesser.php and add some debug messages. I would think that the guessing would be accurate. Not sure of your specific use case but if you wanted to double check regarding an mp3 specifically, if the guesser returns octet-stream for the file and it has ID3 data then there is a pretty good chance it is a mp3. – Nygaard

for me it is throwing FileNotFoundException inside the guess method in the MimeTypeGuesser instance, any ideas? Also, I understand your post but still doesn't make sense to me, it is up to laravel to solve the problem of deciding the mimetype and not to automatically set it to octet-stream (for example by calling the getMimeType() method when instantiating a UploadedFile object) – Sayers

I'm facing similar issues with uploading of Adobe Illustrator files (.ai). AI files are recognized as PDF so the client mime type = "application/postscript" but mime type returns "application/pdf". That's not only it, but using Laravel's storage, it also saves the file into a .pdf instead of the original .ai. My only solution right now is to overwrite the extension. It is really a headache when it automatically changes the file extension based on mime type. – Digitiform

Answer 2

I was having this issue with Laravel 5.4. I fixed by setting post_max_size and upload_max_filesize in my php.ini to a higher value.

After that, I actually had to do a hard restart of OSX before it would actually reflect in the application properly.

Tambourine

You certainly did not need to do "hard restart" you simply did not restart apache (or you did try to restart but did restart the stock one). – Bohaty

@Bohaty I don’t use apache. I use Nginx. I restarted both the PHP service and Nginx. It still didn't apply. Hence my comment about an explicit hard restart. – Tambourine

Did you mean php-fpm? I set up plenty servers (and work from/on OS X myself) and I have never heard of "need to hard reset" because service does not accept new configuration. Sure its weird. It all works now, so its irrelevant I guess. Anyway your "answer" does not answer the OP's question. – Bohaty

Answer 3

I got this error with application/octet-stream in my Laravel 9 app when the files I was uploading were too big.

What fixed it for me was setting these two settings (increasing the limits) in the .ini file:

post_max_size = 128M
upload_max_filesize = 128M

Geotropism