Browsers, HTTP Headers and File Downloads

Posted by Mattias Sandström on February 26, 2009

Many of the products from Tangix are web-based where the user runs the product in his/her web-browser. Web-browsers comes in many different flavors and have many different quirks that we as  developers must handle and take care of. Most problems that Tangix have been experiencing are related to handling downloading of dynamically created files. The concept is pretty straight-forward - the user clicks a link, the server generates the contents and the browser should then download the file - how can that be so hard?!?

The answer is - HTTP Headers! Headers are lines of information that are added by the server before the actual page-content is sent. Headers are normally invisible to the end-users but they influence the behaviour of the browser, specifically Microsoft Internet Explorer.

In Tangix HelpDeskPRO we have had reports of users having problems downloading the attachments to the requests. Normally when the user clicks an attachment, the browser should present a dialogue where the user may select where the download should be saved. When there is a problem, this fails and the user is presented with an error message that makes no sense:

So what’s going on? Well, this error message is triggered by the browser because the headers send by the server is not expected by the browser! The server is not sending the correct headers thus causing the browser to display this error message. Typically such messages includes the name of the PHP-script, in this example “getcertfile.php” and not the name of the intended file to download.

Over the years we have noticed that the implementation of HTTP Headers are prone to be changed between versions of the browsers (Internet Explorer 6 and 7) and also sometimes between patches of the product. Interestingly, we have not had such problems with the other browsers on the market...

Programming the server-side, this has led us to do some research and we have came up with the following code that handles the differences between Internet Explorer 6 and 7:

if(@isset($_SERVER['HTTP_USER_AGENT']) &&
    strpos($_SERVER['HTTP_USER_AGENT'],'MSIE 7')) {
    $filename = str_replace(" ", "%20", $filename);
}


if (isset($_SERVER['HTTP_USER_AGENT']) &&
    strpos($_SERVER['HTTP_USER_AGENT'],'MSIE 7')) {
    header("Cache-Control: public, must-revalidate", true);
    header("Pragma: hack", true);
    header("Content-Type: application/octet-stream", true);
    header("Content-Length: " .(string)(strlen($tmp)) , true);
    header('Content-Disposition: attachment; filename="'. $filename .'"', true);
    header("Content-Transfer-Encoding: binary\n", true);
}
elseif(isset($_SERVER['HTTP_USER_AGENT']) &&
    strpos($_SERVER['HTTP_USER_AGENT'],'MSIE 6')) {
    header("Pragma: public", true);
    header("Content-Type: application/octet-stream", true);
    $filename = mb_convert_encoding($filename, "ISO-8859-1", "UTF-8");
    header("Content-Disposition: attachment; filename=\"" . $filename . "\"", true);
}
else {   
    header("Content-Disposition: attachment;filename=\"" . $filename . "\"", true);
    header("Content-type: application/octet-stream", true);
}

header("Content-Length: " . strlen($fileContents), true);
echo $fileContents;

The above snippet of code handles Microsoft Internet Explorer 6 and 7, setting the correct HTTP Headers and properly encodes the filename for the different browsers. Notably is the Pragma directive that causes some magic within Internet Explorer to properly display the download dialogue for the file.

Internet Explorer, Flash AMF and SSL
Moving into the realms of Flex development and AMF communication, a new problem was discovered where Microsoft Internet Explorer differs from other browsers...
The Flex application developed worked fine in Firefox using HTTP and HTTPS but when Internet Explorer switched from HTTP to HTTPS strange errors were found... The server is running PHP with the Zend_AMF component.

After a bit of research, it was found that the headers are once again the culprit, specially together with PHP’s Session handling. Even though the Flash Player Plug-in runs internally in Internet Explorer, the cookies are not automatically made available to the Flash Player Plug-in unless the server implicitly specifies the session_cache_limiter before the session is initiated by PHP!

The following snippet of code did the magic with Zend_AMF, Internet Explorer and HTTPS:

session_cache_limiter("public");
session_name("SessionIdentifier");
session_start();
header("Cache-Control: cache, must-revalidate");
header("Pragma: public");

We are now keeping our fingers crossed that future versions of the browsers will not break anything....