Sorry about the late post everyone. I had a long week and went to bed before making sure a post was queued. Hopefully you’ll forgive me.

I’m working on a project where I needed to generate a MIME type given a file name. Not only did I need to create a solution that worked, I also needed the solution to be compatible with PHP 4/5 and not require any additional software to be installed on the host. I thought this would be a simple matter of finding a PHP function that does this. Unfortunately, things were not as simple as this.

Problems with finfo_open

I found a very helpful PHP, Mime Types and Fileinfo post on Jelly and Custard. The “Mime Types in PHP 4.x” seemed to be exactly what I wanted. I quickly tried it out on my server, and it failed instantly with the following error:

Since I have PHP 5.2.6 running on my dev server, I was very confused since the post said that this was a “PHP 4.x” solution. I pulled up the PHP doc on the finfo_open function and was very surprised to see that the function is a PHP 5.3.0+ function. Fortunately, my version of PHP was just before this so that I could actually catch the error.

Turns out that the Jelly and Custard post points to another post, Installing PECL Modules, where instructions are given for installing the Fileinfo PECL Package. Installing this package allows versions prior to 5.3.0 to use the finfo_* functions via PECL.

This is not what I want. I’m working toward a solution that doesn’t require the installation of any additional software, and so far I’ve only seen solutions that require this. There has to be a better way.

Problems with mime_content_type

I then found the mime_content_type function. This looks better. However, PHP has marked this function as deprecated due to the PECL Fileinfo package. Relying on a deprecated function has numerous problems: it may throw warnings if used on versions of PHP that know the function is deprecated, most likely won’t receive any updates in the future, and could possibly be removed from future versions of PHP.

In addition to the deprecated issue, the mime_content_type function is laced with problems. In order to use the function the PHP on your system must have been built with the “--with-mime-magic” option. The function also relies upon the “mime_magic.magicfile” ini configuration to tell it where to find the magic file used to detect the MIME type of the file. This magic file may or may not exist/may or may not be readable.

Initial Testing

These problems led to interesting results when I tested it on my CentOS dedicated and Hostgator servers.

On my CentOS 5.2 dedicated server, I have PHP 5.2.6. The PHP build on this server was not built with the “--with-mime-magic” option, so it doesn’t have access to the mime_content_type function at all. In addition to this, since the version is just before 5.3 and I haven’t installed the Fileinfo PECL package, my dedicated server does not have access to either of the official PHP solutions without installing additional software.

On my Hostgator shared server, I have access to PHP 5.2.8. Unlike my dedicated server, this server’s PHP build was built with the “--with-mime-magic” option. “This is great,” I thought. I ran a test, and the mime_content_type function did indeed exist. Like my CentOS server, my Hostgator server does not have the Fileinfo PECL package and does not have PHP 5.3, so the finfo_* functions are no go.

I did some more testing on my Hostgator server and was disappointed to find that the mime_content_type function exists yet is completely worthless. I tested file after file ranging from simple text files, to HTML documents, to a variety of image types. Every single test failed to produce a MIME type. When I say “failed”, I don’t mean that the program crashed with an error. The failure was worse than this, it simply returned an empty string to every single request.

I found that my Hostgator server’s PHP is set up to use the “/usr/local/apache/conf/magic” file to do it’s MIME magic. However, this file is not able to be read by my user. This means that the version of PHP might as well not have been built with the “--with-mime-magic” option at all.

It seems clear to me by now that there will not be an easy solution to this problem.

Final Solution

What I need is a solution that will first try to use the Fileinfo functions since they are the current standard. It will then fall back to using the mime_content_type function if and only if the function exists. Since the function is deprecated and PHP versions don’t actually package the replacement functions natively until 5.3.0, I need to also protect the code against conditions where neither Fileinfo nor mime_content_type are available. The final fallback will be manually generating the MIME type based upon an array match.

Using the fallback is not desirable since I probably won’t be updating the MIME types in the array very often, if at all. However, having it is better than having the code completely fail for common, present day MIME types. Hopefully, the conditions necessary to rely upon this fallback will become more and more rare as time goes on.

In addition to checking for the existence of the functions I’ll try to use, I need to make sure that the methods tried actually produce results. If a method fails to produce a non-empty value, I’ll move on to the next method.

The Code

I got the original idea for this code from a comment by svogal on the PHP doc site. I modified it to match my desired final solution.

The code is far to large to post here. You can download it here.

The array that I built for the mime types is quite large. Since I have a /etc/mime.types file (which is standard in most distros and provided by the mailcap package), I simply used it to generate my array. I quickly built a Perl script that parses through the mime.types file and outputs a file containing the PHP code to create the array. This script makes it easy for me to update the array any time the mime.types file is updated.

You can download my Perl script here. Simply run “perl generateMimeTypes” from the command line to build the array. The array code is put in a file called mime_type_var.code.

Examples

Simple Use

The code is fairly simple to use. Simply include or require the code in your own script and then call the get_file_mime_type function by passing the file’s path as the parameter.

This produces the following output:

Note that PHP’s more advanced functions have the ability to dig into the content of the file to identify the MIME type, so if your system can make use of those functions and the file is not a JPEG image, the results could vary.

Using the debug Parameter

I’ve also provided a debug parameter that allows you to also get information on what method was used to get the MIME type. This may be helpful if you need to determine how sure you are that the detected MIME type is accurate. When the debug parameter is used, an associative array will be returned with a mime_type key and a method key.

This produces the following output:

The possible methods are: fileinfo, mime_content_type, from_array, and last_resort. The first two should be self-explanitory. from_array means that the resulting MIME type was pulled from the array built into the function. last_resort means that the type could not be identified which results in a generic MIME type of “application/octet-stream” being used.

Conclusion

Frankly, I’m disappointed in the solutions provided by PHP to detect MIME types. I have access to a very stable, highly-regarded shared host and an extremely powerful, up-to-date dedicated host, neither of which have the ability to use either of the PHP solutions to detect MIME types without adding additional software.

I don’t remember which version of PHP my dedicated box started with, but I did upgrade to 5.1.6 using the standard repository back in October. I was only able to update to 5.2.6 by using the Utter Ramblings repository by Jason Litka. True, I could compile and install 5.3 or the PECL package myself, but I produce software for people who don’t have a clue what a compiler is, let alone what repositories or PECL extensions are.

It’s things like this that make development a pain. I could always just be a jerk of a developer, have the line “requires PHP 5.3+”, and tell all people that can’t run the software to check the requirements. However, I think that my job is to make the end-user’s life easier, not more complicated.

Hopefully others that have had woes dealing with this situation can make use of my code, and we can all just wait a few years until the majority of hosts have a PHP version that supports these calls natively.

It looks like there is a big networking problem over at The Planet. Hostgator, which hosts this blog and is hosted by The Planet, is suffering terribly from this problem. My uptime with Hostgator is so high, that Pingdom tracks my site at 100% uptime since it doesn’t track beyond 99.99% uptime. So, this has to be causing lots of stress for the engineers at both companies.

I first noticed this problem when working on a site that is hosted at Hostgator. The site completely failed to load and pings failed 50% of the time.

From what I can tell one of the primary switches that handles large loads for The Planet either failed, froze up, or is under extremely high of traffic loads. At first, my site wasn’t effected, but it seems like they are quickly shunting traffic away from the troubled switch, which is causing the other switches to be under greater stress. This has allowed some of the failed sites to respond after abnormally-long load times, but also has the side effect of causing the previously unaffected sites, such as mine, to degrade in performance as well.

I have been incredibly impressed with The Planet through my years of experience with their dedicated systems. Similarly, I have had nothing but the best experiences with Hostgator, which is why I still host my blog on their system despite having a personal dedicated server.

Best of luck to the network engineers as they get this problem sorted, and welcome to 2009.

Update

It looks like the problem is much bigger than I originally believed. It’s possible that a regional switch around the Dallas/Fort Worth area went down. So far, I’ve found that Layered Tech, The Planet, Rackspace, and most of the sites that I know are hosted in that region are either completely inaccessible or extremely slow to respond.

The problem seems to be getting better curently with many of the previously inaccessible sites now coming back up. Hopefully the problem has been resolved.

Update #2

I contacted The Planet, and the guy gave me two responses to my questions about the outage: “no” and “ok”. Not exactly helpful. I then tried to have a live chat with Layered Tech (who I have had great hosting experience with, so this isn’t knocking their service), but I just ended up sending off an email apparently. I contacted Rackspace (another great host who gets my recommendation), and I got a very helpful person who didn’t have any information on the outage but quickly started engaging me in a sales discussion (Tomas S, you sure do a good job with keeping on the sales talk). I then contacted Hostgator via live chat and was immediately given information that a cable provider was having large-scale outages that mostly centered around southern California but also was causing problems for the DFW area. The support person also indicated that the cable provider was slow to provide details and updates.

So, amazingly, the small fish out of all the companies I contacted not only had the fastest response but also was on the ball in terms of having and providing information about an issue that affects me.

Thinking back on each of the live chats offered, Hostgator was the only one that actually seemed to use the Live Chat for more than just sales. Once again, Hostgator proves that they truly do have great service and support.