| Title | MIME Type Correction Mapping TAble |
| Detailed description | Not a full-blown solution, but an initial analysis of the problem and of how to reconcile the problematic MIME types given out by servers with the results from the file tool. |
| Solution Champion |  Andrew Jackson |
| Corresponding Issue(s) | |
| Tool/code link | none at present |
Tool Registry Link |
none at present |
| Evaluation | Any notes or links on how the solution performed |
MIME Mapping
The supplied data on server MIME types contained two types of error:
- The server type is not an officially registered MIME type.
- The server type is a real MIME type but does not match the content.
Most of the problems were of the former type. In particular, I learned that 'application/force-download' was being used to make IE download a PDF instead of viewing it inline. Also, the 'image/jpg' MIME type was being supplied, when the correct form is 'image/jpeg'. The solution in these cases is to make these commonly broken MIME types to the result from the file command.
This also works for the second case, except where the result from the 'file' command cannot be trusted. Unfortunately, the domain over which file is correct is not clear, although it does seem that plain text is problematic. See
n.b. also noticed a different where something served as text/xml is being identified as application/xml. This is a bit more subtle, as text/xml is now deprecated due to the fact that this implies charset=us-ascii and this may (usually will!) disagree with the encoding declared in the xml file itself.
Finally, it's worth noting that the open source shared-mime-info contains commonly mis-used MIME types and may help to resolve these issues. Also, note further that there is a fast implementation of the parser for this data file here: http://www.memecode.com/libsharedmime.php