In times like these, the official HTTP specification is always helpful. From RFC 2616 7.2.1 (my emphasis added):
Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".
The cause of your issue is that the server accepting the file upload does not itself know what type of file has been uploaded. Why? Because it relies on the the HTTP message which sent the file to specify a Content-Type
header to determine the exact mime-type. The browser has likely not sent a Content-Type
header and the server has assumed application/octet-stream
as per the official HTTP specification excerpt above. It's also possible that the client uploading the file opted not to determine the mime type of the file it was uploading and sent the Content-Type: application/octet-stream
header itself.
Now, when we consider this in conjunction with the PHP manual entry regarding POST file uploadsdocs, we see the following:
$_FILES['userfile']['type']
The mime type of the file, if the browser provided this information. An example would be "image/gif". This mime type is however not checked on the PHP side and therefore don't take its value for granted.
So as you can see, even if $_FILES['userfile']['type']
is specified, it only corresponds to the Content-Type
header sent by the client. This information can easily be faked and should not be relied upon. If you need to be sure that the uploaded file is of a specific type, you'll have to verify that yourself.
upload_max_filesize
setting in php.ini you will getapplication/octet-stream
instead of expected mime – Skilken