Large File Download Issue Workarounds (Downloads stopping at a certain point)

[wzp]

Are you trying to do a download, without the use of any other download plugins, just the download feature built into the browser?

What browsers (including version) have you tried?

Have you tried any of the other “download methods” listed under WP eStore -> Settings -> Addon Settings -> Download Manager Related -> Download Methods ?

[jesssse]

Im using a simple php script which conceals the location of a download file, I was hoping to use this method to overcome the download size issue, I know it wouldn’t be as secure but thought I’d try it.

So WP-estore’s encrypted link sends the user to a masked url- the php file at the url links to a masked file which it forces to browser to download.

At the moment the only way I can get it to work it send it to a html file that then loads the php, but url is exposed.

Hope that makes sense.

It really is a great product, I hope I can get it work for large files.

Thanks.

[wzp]

@jesssse

Under the WP eStore -> Settings -> Addon Settings -> Download Manager Related settings, have you tried the different download methods?

[wzp]

@jesssse

WARNING — Running with scissors (highly technical information) ahead…

It occurred to me in my sleep (yeah, I’m like that) that since a 600mb file takes a considerable amount of time to transfer; the problem may be that your provider is terminating the download script, because they have restricted the use of the set_time_limit() function:

http://php.net/manual/en/function.set-time-limit.php

At the start of every download, eStore issues a set_time_limit(0) call. However, because it is a void return, there is no way to determine if the call was successful; other than to see if the script successfully completes.

To determine if eStore completed executing its scripts without being terminated, please enable the debugging logs. Attempt a download and then look in the “download_manager_debug.log” file. The normal sequence of messages should include a “dispatching DL method” entry, followed by some kind of DL completed entry. If the script was terminated by PHP, the last entry should be just the “dispatching DL method” message. If the script completed without being terminated by PHP, the last entry should be some message of download success or failure message.

[wzp]

@jesssse

WARNING — More running with scissors (highly technical information) ahead…

You can try executing this script to test if the set_time_limit() is being ignored by your provider. I know it works under PHP 5.2 and up, but have not tested on other versions.

<?php

echo ‘Default Maximum Script Execution Time is = ‘.ini_get(‘max_execution_time’).”;

set_time_limit(0);

echo ‘Maximum Script Execution Time is now = ‘.ini_get(‘max_execution_time’).”;

?>

When executed from the browser, the output should look something like:

Default Maximum Script Execution Time is = 60

Maximum Script Execution Time is now = 0

Caveat… it is unknown whether of not, if the set_time_limit() is being restricted, if PHP will still set the requested value and then simply “ignore it.” Only the previously suggested checking of the debug files is a sure way to determine if the script was killed off by PHP.

Now, I am going back to sleep, lol…

[jesssse]

Thats awesome, thank you, I will report back and let you know how it goes.

[jesssse]

Many thanks, here are the findings….

Log’s last line shows:- [11/05/2010 8:52 PM] – Status : Dispatching DL method = 1

Running the php script reveals:-

Default Maximum Script Execution Time is = 30Maximum Script Execution Time is now = 0

Looking forward to more running scissors, I’m following so far. knives?

Thanks.

Jesse.

[wzp]

Ok, here is what we know…

At some point, large files are causing the download script to be terminated in mid transfer.

You’ve probably looked at the code in the download.php file already, for method #1, and have seen the great lengths we’ve gone through to catch all possible errors that might occur.

The test script reveals that PHP “thinks” we have overridden the script timer, but the log files tell a different story — that something on the server is terminating the script.

I’ll have to research this some more, but I don’t think any extra scripting on your part will correct the problem, because it is something external to PHP that is causing the scripts to terminate.

[jesssse]

OK, so the main thing I need, to be able to start using this plugin (in work around mode)

is to change the way the pay-per-view option opens a link, at the moment it is opening any file

I link to, as a text document, so if I link to a zip file to download, it just opens it as jumbled text.

Is there a way for force a download using this masked workaround option.

Any help would be much appreciated, if I can start selling using this, not so secure, method,

it will get me by until the encrypted links method can be adjusted to handle large files.

Many thanks again.

Jesse.

[wzp]

@jesssse @timprebble @scottonstott @ToneManufacture @sayWhat and anyone else who has large test files…

Disclaimer: No promises, but we’d like you to tryout a change we made last night to one of the download methods.

1. Download version 4.6.3 of eStore:

https://support.tipsandtricks-hq.com/automatic-update-request

2. Install the update:

http://www.tipsandtricks-hq.com/ecommerce/wordpress-estore-installation-and-usage-guide-31

3. If you are using the plugin’s downloads folder to store you files, remember to delete the ,htaccess file after the update (because it gets replaced).

4. WP eStore -> Settings -> Addon Settings -> Download Manager Related

a. Automatic URL Conversion Preference -> Do Not Convert

b. Download Method -> Method 7, cURL

Note: If you don’t see Method 7 it means the cURL library is not installed on your server. Also, please write down your current settings in case you decide to go back to what you previously were using.

5. Update/Save the new settings.

6. Please try it out and report back. Tell us the size of the file(s) used and the results.

[wzp]

Well, for those who want to know why downloads terminate in mid transfer, I was able to “catch” this at the end of an 80 MB test file that aborted at the 50 MB mark…

<html><head>

<title>200 OK</title>

</head><body>

OK

<p>The server encountered an internal error or

misconfiguration and was unable to complete

your request.</p>

<p>More information about this error may be available

in the server error log.</p>

---

<address>Apache Server at yoursite.com Port 443</address>

</body></html>

[wzp]

Well, after going through several hundred Google results, the best reason for why downloads are being terminated has something to do with the ModSecurity module in Apache.

[wzp]

Okay, here is the definitive answer… at least for Apache users.

Both the “#1 Default” and “#7 cURL” download methods will work for any size file, with cURL being preferred because it uses less PHP execution time per megabyte. However, many may have noticed that after about 5 minutes or so the download is mysteriously terminated. Running a Unix style “strings” command on the terminated download usually reveals a “200 OK” or “500 Internal” error message.

The answer on Apache servers can be found in the httpd.conf file…

# Timeout: The number of seconds before receives and sends time out.

Timeout 300

Even though eStore overrides the PHP script execution timer, if any download takes more than the configured number of seconds; Apache will terminate the download script.

I suspect the same thing applies to IIS and other servers as well.

Now I can rest in peace, knowing what was happening!

P.S. It is unclear if the timeout is in “real” or “processor” seconds. Use of a dedicated server may give different results than shared or grid hosting.

[jesssse]

Hey,

Many thanks for giving this your attention, I will install the new version and test it.

I’ve been using the plugin on my site and limiting the download sizes to around 50MB,

I haven’t have any fail as yet but I would like to use much larger file sizes, so hopefully this version will do the trick.

Again, thanks for your time.

[jesssse]

ok, after testing for a while, I haven’t had any failed downloads as of yet, which is great news.

The problem I having is the email containing the links to downloads isn’t getting sent out to the buyer.

I have physical products as well as downloads, the physical products get a confirmation email without fail,

its just the downloads email that doesn’t seem to work. I have the newest version of estore.

Thanks in advance.

[Author]

Posts