embedding pdfs fail for some users using Firefox

[Robert Lyon]

This looks to be related to mimetypes that handle pdfs

The default mimetype, Portable Document Format (PDF) is:

 application/pdf

However users are able to upload pdfs that end up with all manner of mimetypes, following is a list of saved mimetypes where the oldextention was 'pdf':

 "application/pdf"
 application/x-pdf
 application/force-download
 application/x-forcedownload
 application/x-msdownload
 application/x-octet-stream
 application/download
application/x-download
 application/zip
 application/octet-stream
 application/x-unknown
 application/octetatream
 image/jpeg
 application/x-filler
 application/x-itunes-itlp
 binary/octet-stream
 application/x-msdownload
 application/download
 image/png
 text/html
 application/binary

Some of them may simply be people putting wrong extension on their non .pdf file but the majority will be misdiagnosed pdfs.

This is probably due to the php finfo function not being able to check correctly
https://bugs.php.net/bug.php?id=61940
so Mahara is going by what the browser tells it and by looking at the list browsers lie.

An example why browsers may be giving wrong info:

The application/force-download content-type is from a user action.
The user opened an URL that used this content-type to be sure that the browser displayed a file download dialog instead of displaying it inline with a PDF plugin. The user selected "save this decision" and the wrong content-type was saved in mimetypes.rdf.

so the question is what to do?

[Robert Lyon (robertl-9)]

I should mention that list of dud pdf mimetypes is from mahara.org - 4% of the pdf files there have the wrong mimetype recorded against them. So the problem is bigger than one person/isolated case but not too huge an issue

[Aaron Wells (u-aaronw)]

I've opened a separate bug to talk about the issue of mimetype detection generally: https://bugs.launchpad.net/mahara/+bug/1249858