While setting some svn properties at work, we wondered about the correct MIME type for .php files.
Looking around in the various magic MIME type detection lists on our unix machines and the official IANA MIME type list , the options we came up with were:
MIME type rules
Since there is no official MIME type registered at IANA, only an extension type (x- prefixed) can be used - which means that text/php and application/php are not suitable:
Any unregistered file type should be listed with a preceding x-, as in application/x-foo (RFC2045 5.1), or a x., as in application/x.foo (RFC4288 4.3). Any non x-prefixed type should be registered with IANA and listed at the above address. Any other behavior is a MIME standards violation!
Ubuntu's magic MIME database - used by the file command - spits out text/x-php:
$ file -i update-file.php update-file.php: text/x-php; charset=us-ascii
Debian's mime-support package, also shipped by Ubuntu, lists application/x-httpd-php for .php and application/x-httpd-php-source for .phps files in /etc/mime.types. This two types are - in my eyes - more for internal Apache/webserver use since PHP is not only usable within a http daemon.
Use of the "text" top-level type for this kind of content is known to be problematic.
- but fails to state why that is so. I guess this is because security problems arise since browsers try to display every text/ MIME type as HTML.
Looking at the officially assigned text/ types makes clear that there is not a single programming language source file type in the club. (HTML is, as the name implies, a markup and not a programming language - which is why text/html does not count .)
Using application/x-php as MIME type for .php files is not without pain.
A type beginning with text/ indicates that the contents of the file are human readable. I can open it and get a grip of what's going on inside, even if I do not understand everything when I don't know the specific language the file is in. I can use text utilities on it: cat, grep, sed, diff - you name it. It must not even be myself that uses the tools; it can be an application or a shell script I wrote that detects I'm working with a text file and use the appropriate tools.
Files with a type beginning with application/ on the other hand can be trusted to be machine readable only. Using application/java-vm for .class files is totally fine since only a computer can read it - as well as application/zip and application/vnd.oasis.opendocument.spreadsheet.
One tool that fails badly with application/x-php is the aforementioned svn: It detects text files as I described, by using the MIME type's media part. Setting the MIME type of a .php file to application/x-php leads to the problem that it handles PHP files as binary, thus not diffing them - making diffs in PHP projects unusable. We had to go back to text/x-php in our svn repositories.
And exactly that's the problem: How is a programmer supposed to detect if a file is human readable and can be displayed? With IANA dictating realities that drift toward application/ types, the MIME type is no indicator anymore.
Putting programming languages under the application group has statistical significance and is also backed by previous IANA decisions. So it seems it's inevitable to use application/x-php as MIME type for .php files - but it makes a developer's life harder.