Members App: Secure Downloads: Downloads fail (timeout?)

It's more likely to be your PHP max upload size and PHP max form post size. Are you able to edit your server's php.ini (or equivalent) file? You'll need to up these allowances to cover the biggest file you're likely to transfer (1.2GB is equivalent to 1200M). Hopefully that'll fix it :)

Also, check your form template has the right group declared in the perch:input's accept="" attribute. These are grouped in perch/config/filetypes.ini and all you have to do is declare the header that's in square brackets. e.g.

<perch:input type="file" id="file" label="File" accept="image pdf office" />

That one got me good and proper last week! Good luck :)

Hello Martin,

Thank you for the suggestions!

The files are uploaded to the secure buckets via FTP, so there is no issue with max upload size or Perch templates.

It's an issue during download, as if the connection was reset after about 5 minutes (tested with Chrome and Safari latest). I suspect a PHP timeout issue, and wonder if some of you have been able to offer large files for download.

Hello Drew,

Here is the server's error log:

Tue Jan 27 17:32:42 2015] [error] [client xxx.xxx.xx.xxx] [host redacted.com] (104)Connection reset by peer: FastCGI: comm with server "/homez.xxx/redacted/www/services/download.php" aborted: read failed, referer: https://redacted.com/en/services/
[Tue Jan 27 17:32:42 2015] [error] [client xxx.xxx.xx.xxx] [host redacted.com] Handler for fastcgi-script returned invalid result code 1, referer: https://redacted.com/en/services/

It's very basic:

<?php

    // Remove the PHP time limit to avoid timeouts during download
    // (Doesn't solve the issue)
    //ini_set('max_execution_time',5400);
    //set_time_limit(0);

    // Language detection
    //include('../lib/locale.php');

    // Perch
    include('../cms/runtime.php');

    // config
    $bucket_name = 'active';
    $url_param   = 'file';

    // By default, deny downloads unless we've proved the member is allowed this file.
    $allow_download = false;

    // Check if member is logged in
    //if (perch_member_logged_in()) {
    //     $allow_download = true;
    //}

    if (perch_member_has_tag('active')) {
        $allow_download = true;
    }

    if ($allow_download) {

        perch_members_secure_download(perch_get($url_param), $bucket_name);

    }

    exit;
?>

and the services page calling the download script has links such as this one:

<a href="<?php if (perch_member_has_tag('active')) { ?>/services/download.php?file=/fw1617/ACW17_PRINTS.zip<?php } else { echo "#"; } ?>" target="_blank" download="download" class="download-link"><?php echo _("Prints"); ?></a>

In theory, how large could the downloadable files be? Have you been able to offer 1GB downloads successfully? Trying to figure if the issue is with server settings (timeout, memory) or the download script.

I've got a file transfer system (both uploads and downloads) that works with up to 2GB. I had some help setting up the server but I remember there being something that was set on the server to allow the large downloads, just not exactly what… I'll ask my server friend and get back to you if we're able to work out/remember what we did.

Thanks Martin, that's encouraging! Curious to know which setting/rule had to be added to prevent the issues we're experiencing.

Clutching at straws a wee bit but could it be something to do with this?: https://dembol.org/blog/mod_cband/

I doubt it as we are way below the bandwidth quota (the website hasn't launched yet), and it fails after 5 minutes only.

We have no access to php.ini as it's a shared server.

I've got a dedicated virtual server set up to handle the site, so maybe there was something there that got it working.

How about hosting the uploads on something like S3? I think you may have to upgrade Perch to Runway, but it would probably be cheaper overall than moving to a new server.

Thank you Martin and Drew.

The issue was caused by the hoster which killed scripts taking more than 300 seconds to run (max execution time).

We circumvented the problem by creating a symlink to the file in a randomly-named directory within the "www" root and letting the browser download the file directly (no PHP "streaming"). The symlink is then deleted via cron after a few minutes to avoid sharing of download links.

Our solution was inspired by this script https://mrbluecoat.blogspot.com/2013/09/useful-php-force-download-script.html