Download of iso from shopping cart stops and fails downloading at 1 GB

[bscho]

I am trying to let a customer download an iso file.

He got a internal server error.

How do I set it up?

In the attributes it has download and text. The download is marked as green.

I do not understand what the text is. I delete it and it comes back again.

Do I have to have a text file as well?

I do not understand the buttons delete the file from the server. I put that to no but it keeps returning to yes.

I see the same button in the product as well as the attributes. How do I set these up?

[lat9]

A .iso file is usually pretty big. Have you checked your /logs directory? A "Server Error" normally results in a myDEBUG*.log file being created there that describes the particulars of the error's cause.

[bscho]

I have it working now to a point.

I had to chmod 444 the files this was the reason. However the files are 1.3GB and 1.8GB iso

The download fails for both at 1GB it looks like there is a download limit of 1GB and need to know wher to change it if possible.

Have you any ideas?

I can not find the logs you are talking about. The logs on the site only show my activities and on the server I cannot open them.

With filezilla I click and try to edit them but nothing comes up?

[lat9]

For those log files, you need to point FileZilla at the site's /logs sub-directory (it's at the same directory-level as the /includes and /YOUR_ADMIN sub-directories).

What are your store's Configuration settings for:

1. Attribute Settings::Enable Downloads
2. Attribute Settings::Download by Redirect
3. Attribute Settings::Download by streaming

[DrByte]

Adding to lat9's question, keep the following in mind:

- download-by-streaming relies on a PHP process to read the file in small increments (4K chunks) and serve those out as a stream of data until done. It's intended to bypass memory limits imposed by your server config especially when dealing with very large files. It also increases the max duration time of the download to 25 minutes (if your server's PHP hasn't been configured to disallow that).
If download-by-streaming is cut off at exact 1GB (converted to bytes) then it would suggest that the server filesystem is refusing to give the data to PHP after that size. If the size is some random amount different than exactly 1GB then it suggests a timeout or network interruption.

- download-by-redirect creates a symlink, and then your visitor is redirected to that symlink so that Apache/Nginx serves the file directly, independent of PHP. In that case if it's terminating at exactly 1GB (converted to bytes) then maybe something in your Apache configuration needs attention (ie: maybe Apache has a setting?)?
-- note also that sometimes the symlink approach can be problematic if several people buy and download the same thing at the same time, because there's some garbage-collection that cleans up old symlinks, and if that happens during someone's download it could terminate at an unpredicted spot, and without any notification.
Your Apache/Nginx logs may give you more insights about download-by-redirect downloads. You won't find those in PHP logs.

[bscho]

1. True
2. True
3. False

[bscho]

Adding to lat9's question, keep the following in mind:

- download-by-streaming relies on a PHP process to read the file in small increments (4K chunks) and serve those out as a stream of data until done. It's intended to bypass memory limits imposed by your server config especially when dealing with very large files. It also increases the max duration time of the download to 25 minutes (if your server's PHP hasn't been configured to disallow that).
If download-by-streaming is cut off at exact 1GB (converted to bytes) then it would suggest that the server filesystem is refusing to give the data to PHP after that size. If the size is some random amount different than exactly 1GB then it suggests a timeout or network interruption.

- download-by-redirect creates a symlink, and then your visitor is redirected to that symlink so that Apache/Nginx serves the file directly, independent of PHP. In that case if it's terminating at exactly 1GB (converted to bytes) then maybe something in your Apache configuration needs attention (ie: maybe Apache has a setting?)?
-- note also that sometimes the symlink approach can be problematic if several people buy and download the same thing at the same time, because there's some garbage-collection that cleans up old symlinks, and if that happens during someone's download it could terminate at an unpredicted spot, and without any notification.
Your Apache/Nginx logs may give you more insights about download-by-redirect downloads. You won't find those in PHP logs.

It fails always at 1 GB no matter which download I use 1.3GB or 1.8GB

I take it that I should do redirect. Well I have set that as true.

I have spoken to my provider who says I need to take another 10 GB space to fix the problem.

I find that sometimes instead of starting downloading it gives the message:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at [email protected] to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

I then started cleaning up the site to free space to see if this was true.

It now is doing not downloading at all and giving the Internal Server Error all the time all the time.

I still cannot read the logs on the server I try to read them with Filezilla clicking on the log folder which has a ? mark and click edit but I see nothing. Normally things open up in geany.

I take it there is no limitation of the size of the file in the shopping cart?

Do you think the provider is right it is because of not enough webspace?

Thanks for your help.

[DrByte]

1. "Internal Server Error" is a generic message because it's usually not safe to publicly display "actual cause of the problem" in the browser.
Thus, you must look at the server's messages to understand what actually happened.
As lat9 mentioned, (if the error is occurring after the first 15% of Zen Cart code loads (and it's rare that the error happens earlier than that, then) the logging of errors will show up in the /logs/myDebug-xxxxxxxx.log files.
For those other 15% you'll find them in the server's own logs, which can usually be accessed via cpanel, or whatever your hosting company offers as a control panel.

2. out-of-disk space? Haha, no, that's probably not the problem, unless they've actually limited your account to a storage limit lower than what your files are actually consuming. But if you're out of allowed disk space then you're probably also getting tons of other errors too, and probably would start getting database errors when trying to save new customers and new orders or edit products, and wouldn't be able to upload new files.
That said, it's always a good idea to delete files you don't need on the server. That includes cleaning up the /logs/ directory!

No, Zen Cart doesn't impose any limitations on download file sizes.

3. "cannot read the logs on the server".
If you can't open/read any "specific" file, then that's odd. Try downloading it instead of opening it for viewing. Then view it from your PC instead.
If you can't open the logs *folder*, then that suggests a permissions issue. Maybe your server uses an older permission style that blocks "you" from accessing files that got generated by the PHP/Web user? Your hosting company can help set permissions properly for what they require.
It's also possible that the logs folder is massive in size because of all kinds of other errors being recorded, and filezilla can't "open" the folder because there's too many files "in" there? Alternatives would be the hosting company's cpanel file manager, or the command-line if you have that sort of access and know how to use it. If it's because there are 10s of thousands of files in there, you might want to ask your hosting company to rename the /logs/ folder to logs-old, and then you can upload a new /logs/ folder from a fresh copy of Zen Cart (there are a couple files in there by default, which just prevent unauthorized snooping, so you should be sure to copy those in). Then trigger your "problem" again, and see what log files get generated, and go from there.

4. download-by-redirect.
This requires that the /pub/ folder exists and is writable by PHP. It too contains some protection files by default.