note 47948 modified in function.header by danbrown

Interesting one this - I have a client who is selling MP3's online. To protect his files, they are obsucrely named, with that name being stored in the Postgresql backend. When the user clicks an MP3 to download, we wrote a script that would dump the file contents and rename etc. to allow the user to download but not guess other files names. Now, testing was done in Firefox, everything worked just ducky, loaded 'er up in IE. Nada. "File could not be cached..." error and the browser just hung waiting for the transfer to begin. After tinkering, reading these pages, trying the inline/image trick, trying all kinds of things I went on a hard search on Google. Nothing I treid seemed to work. The following code did not work in IE: <?php // append .mp3 onto he file name $name = addslashes(str_replace(" ", "_", $name).".mp3"); // make sure this thing doesn't cache header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Cache-Control: no-store, no-cache, must-revalidate"); header("Cache-Control: post-check=0, pre-check=0", false); header("Pragma: no-cache"); // create the necessary MP3 headers, this will type the page as MP3 and force download $len = filesize("/path/client/mp3/".md5("prefix_$id")); header("Content-type: audio/mpeg;\r\n"); header("Content-Length: $len;\r\n"); $head = "Content-Disposition: attachment; filename=\"$name\";\r\n"; header($head); // hash the id to create the correct path $realpath = "/path/client/mp3/".md5("prefix_$id"); // spit out the contents of the MP3 file to the browser readfile($realpath); ?> As a last resort, I moved the whole system off the SSL to test some other issues (server & platform) The problem ended up being that the file download was taking place on a Secure Socket Layer. https://somedomain/download_mp3.php rendered the code invalid. Removing the s, to make http://somedomain/download_mp3.php (I know this is not the best way of maintaining security, but after paying for files, people would be pretty upset if they didn't download!) works like a charm. I have not found out why this problem occurs yet, I've emailed Microsoft and told them about this (rather stupid) oversight on their part - who does testing over there any way!!! I am assuming that the way IE handles certificates and codec processing is not implemented correctly. So, I hope this helps - if you're having problems forcing http headers in order to force downloads, content-types, if you're using SSL, try checking your code on non-SSL.... --was-- Interesting one this - I have a client who is selling MP3's online. To protect his files, they are obsucrely named, with that name being stored in the Postgresql backend. When the user clicks an MP3 to download, we wrote a script that would dump the file contents and rename etc. to allow the user to download but not guess other files names. Now, testing was done in Firefox, everything worked just ducky, loaded 'er up in IE. Nada. "File could not be cached..." error and the browser just hung waiting for the transfer to begin. After tinkering, reading these pages, trying the inline/image trick, trying all kinds of things I went on a hard search on Google. Nothing I treid seemed to work. The following code did not work in IE: <? // append .mp3 onto he file name $name = addslashes(str_replace(" ", "_", $name).".mp3"); // make sure this thing doesn't cache header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Cache-Control: no-store, no-cache, must-revalidate"); header("Cache-Control: post-check=0, pre-check=0", false); header("Pragma: no-cache"); // create the necessary MP3 headers, this will type the page as MP3 and force download $len = filesize("/path/client/mp3/".md5("prefix_$id")); header("Content-type: audio/mpeg;\r\n"); header("Content-Length: $len;\r\n"); $head = "Content-Disposition: attachment; filename=\"$name\";\r\n"; header($head); // hash the id to create the correct path $realpath = "/path/client/mp3/".md5("prefix_$id"); // spit out the contents of the MP3 file to the browser readfile($realpath); ?> As a last resort, I moved the whole system off the SSL to test some other issues (server & platform) The problem ended up being that the file download was taking place on a Secure Socket Layer. https://somedomain/download_mp3.php rendered the code invalid. Removing the s, to make http://somedomain/download_mp3.php (I know this is not the best way of maintaining security, but after paying for files, people would be pretty upset if they didn't download!) works like a charm. I have not found out why this problem occurs yet, I've emailed Microsoft and told them about this (rather stupid) oversight on their part - who does testing over there any way!!! I am assuming that the way IE handles certificates and codec processing is not implemented correctly. So, I hope this helps - if you're having problems forcing http headers in order to force downloads, content-types, if you're using SSL, try checking your code on non-SSL.... http://php.net/manual/en/function.header.php