Jump to content

Recommended Posts

I've been having trouble with one of my download scripts i've been using for a while which prevents users from seeing the direct-link location of a file. It's a simple php script which has worked on and off on several servers in the past. I used to think that it "stopped" working because of an issue with my hosting account but now it's happening too often that I have to consider the script is doing something wrong and clogging something up on the server. So, first the script itself (relevent parts only, disregard syntax or undefined variables, assume its all there):

 

<?PHP

$file_name = "download.zip";
$filelocation   = "$rowx[FILE_URL]";  //fetches the file url from mysql database.
                
        header("Content-type: application/octet-stream\n");
        header("Cache-Control: must-revalidate, post-check=0, pre-check=0\n");
        header("Content-Transfer-Encoding: binary\n");
        header("Content-disposition: attachment; filename=\"$file_name\"\n");
        readfile("$filelocation");

?>

 

Simple, right? One thing the script never does is actually find the filesize and allow for a perctage download indicator. The download is always for an "unknown" size. This could be part of the problem. Also, I checked to make sure there was no mysql database issue (being open too long or whatnot) so i closed the connection at the end of the script. Problem persists.

 

My host advised me to increase the memory limits and cache in the php.ini file. It did absolutely nothing. Recently, when the problem came back on a new server. The host told me to upgrade to a dedicated IP, which I went ahead and did.The problem DID go away around this time, but I can't attribute it to the dedicated IP because they (the host) were likley mucking around the server around the same time and could have been flushing cache's and any number of things so I can't say what fixed it temporarily.

 

My suspicion is still that something in the script is causing a table on the server to fill up and perhaps its not being dumped as new data is being written, hence the terminated download. That's only a guess, however. I've been having this problem on and off for YEARS, so a big thanks in advance to anyone who can help even a little.

Link to comment
https://forums.phpfreaks.com/topic/275630-download-script-timing-out/
Share on other sites

Is $filelocation a local file, or a remote URL? Based on the naming, I am guessing the latter. Can you be more descriptive of how exactly the script fails? Does it end the download prematurely? Are there any PHP error messages if you look at the downloaded file in a text editor? Does the download not start at all?

 

Also you shouldn't have the \n at the end of your header() lines.

 

Try increasing the timeout using set_time_limit

Thanks for your reply. $filelocation refers to a local file hosted under the public_html directory in several subfolders.

 

The script fails by randomly terminating before it completes. For example, a 300mb file may terminate anywhere between, say, 25mb downloaded or 200mb downloaded as a general rule.

 

There are no error messages during execution of the script or upon termination. It just looks to the end user like the file downloaded fully and successfuly.

 

I tried changing the set_time_limit() option before (it was one of the early suggestions made by my host) however it made no difference.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.