Recently, during phpBMS development, a common problem came out again in our code. Apparently, Internet Explorer has problems when feeding different file types (e.g. .pdf, .gif, and .jpg) to an IE browsers via php. We have several potential problems, and I wanted to document how we handled them:
Mime Type – Shmime Type
Older versions of IE (5.5 for example) had a hard time interpreting file types, sometimes ignoring the mime-type sent in the headers. If I had a php file titled PDFinvoice.php which sent a PDF file, along with appropriate headers identifying it as such, IE seemed to ignore them and look only at the extension in the URL. The result was PDF being displayed inline in the browser, in all it’s binary goodness – Ulk!
The Solution
We added a URL variable to trick IE into thinking it was a PDF. The URL would look something like this:
PDFinvoice.php?ext=.pdf
And had some success in IE properly displaying the pdf. If you have other URL variables, make sure that ext variable is always on the end so that the total URL ends with the extension of the desired file type.
Caching
Caching is the bane of my web-application existence. I cannot tell you how many times I have made a change to phpBMS only to have my web browser not load the latest JavaScript file, or CSS in conjunction with the page itself. The problem is compounded when users set weird caching options (always use cache) that some browsers provide. I hope to assemble a separate post on the dangers and pitfalls of working with different browsing cache problems in the future.
This particular caching problem was not limited to IE, but it certainly was most prevalent in Internet Explorer. Depending on how caching was setup and what “zone” IE thought the site was in, generated PDFs were being cached so that a PDF for one invoice displayed an older cached version.
The Solution
We added another URL variable that was unique by just including a time stamp. The PHP code looks something like this:
echo 'PDFinvoice.php?t='.mktime().'&ext=.pdf';
so that the result URL looks a little like this:
PDFinvoice.php?t=1193314923 &ext.pdf
This seemed to throw all but the most stubborn caching options so that each invoice PDF is generated and displayed properly.
Session headers
That’s right, sending session cookie (or other cookie) information followed by content-type headers can throw off IE. What’s more, it’s resulting output is inconsistent at best. Sometimes we would get no output (blank page) other times it would spit out the raw file, and still other times it would work, or work with weird caching problems.
To solve this problem, we used the following PHP command before we started the session:
session_cache_limiter(‘private’);
The cache limiter defines which cache control HTTP headers are sent to the client. These headers determine the rules by which the page content may be cached by the client and intermediate proxies. For some reason IE needs to have the cache set to private in order to correctly read the content-type headers pushed by PHP.
At first I thought that a cache limiter set to ‘nocache’ was the ideal solution, but alas, that throws IE for an even worse loop.
Always remember to test web applications on as many prominent browsers as you can – it’s good practice. When doing so remember, that you will probably get the most wonky behavior out of IE.
