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:
- text/php
- text/x-php
- application/php
- application/x-php
- application/x-httpd-php
- application/x-httpd-php-source
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!
Linux distributions
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.
IANA considerations
What's left are text/x-php and application/x-php. I personally prefer text/* for user readable plain text files, which is why I was sceptical about application/x-php at first. Then I saw that in 2006, IANA officially assigned application/javascript for JavaScript code files - and not text/javascript. The RFC states:
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.
A similar reasoning was used when applying for the JSON MIME type that was officially assigned in RFC 4627:
When asked about why not "text/json", Crockford seems to have said JSON is not really javascript nor text and also IANA was more likely to hand out application/* than text/*.
Other languages
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 .)
The list of application/ types on the other hand contains types like application/ecmascript and application/javascript, both programming languages. Further, even Debian puts several programming languages into the application group: application/x-ruby, application/x-sh and application/x-tcl.
Downsides
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.
The same problem arises when using the official application/javascript type. The associated bug report suggests to put a number of application/ types on the "this is a text file" list.
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.
Conclusion
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.