Store not available during download of large file

I'm using 1.5.5.1 with the stock theme.

When I make a test purchase and begin to download the attached file (1.2GB) the store stops responding from both the customer side and the admin side. The browser just sits there like it's waiting for a response from the server. All other sites are fully accessible via the browser without any noticeable slowdown. I've tried viewing the site from the customer side using another computer and it is fully accessible, so this only seems to affect the computer doing the actual downloading. Once the download is over, I get 500 Server Error on both frontend and backend. When I refresh the screens, everything returns to normal.

Is this how the store is supposed to work? This means my customer can't continue to browse my store while they are doing the download and then they get a "scary" error once it's complete. Or is there some setting I can make on my server that will prevent all this ugly behavior?

Thanks!

What are these: machine; operating system, version, service pack; browser, version; connection type, speed? Is an anti-viral or anti-malware program scanning or trying to update, or is a Java updater or Adobe updater commandeering "idle" time?

You may need to insert a small but conspicuous notice to leave the machine alone while downloading anything "big" enough to slow it visibly.

This behaviour is not exhibited when I download large files from anyplace else, thus it is not my machine; operating system, browser, connection type, speed, an anti-viral or anti-malware program scanning or trying to update, or a Java updater or Adobe updater commandeering "idle" time. In addition, all other tabs in the same browser navigating other sites (even other sites on my physical server) work fine and without delay.

Furthermore, it also happens on a different machine, OS, browser, etc...

I certainly hope it doesn't come down to requiring a message to the user that my store will be frozen for the duration of their download... How user-unfriendly is THAT?

The "not . . . from anyplace else" indicates your laptop or otherwise portable machine (until taken there) is suffering a difference in some combination of connection speed, signal strength, and provider throttling. The "all other tabs" that "work fine and without delay" indicate that the browser itself is "responding" well within any limitations of swapfile or ram (which would otherwise make switching tabs v. tedious).

The "also happens on a different" setup and location narrows it to the server. Check php download-related and upload-related similar settings, if you can change them. The original "500 Server Error on both frontend and backend" that refreshes expunged indicate something wrong in a configuration (yours, not server's) or in a server timeout. The latter can be settable (if you are allowed there).

If customers are told, then at least they'll know what to do (wait).

Another option is to send them somewhere else unfrozen while a file downloads.

Thanks for your responses, Butte.
By "any other place", I meant that my browser can download large files from any other site without the referring site being frozen out. Don't most download routines send to another tab/window for the process to complete instead of leaving the user in the same window? It's clear that OC was written to only support downloads of smaller files, which would complete in time to return the user back to the browser, but with large files it's useless.

I have tried this with multiple browsers and multiple machines and they all show the store frozen during download.

There is no constraint on my server end for file download size. I strongly feel this is an issue with OC and how it feeds the file info to the browsers over http - perhaps something to do with the header().

I'll send you a private message so you can try a download at your end.

I'll check that in a couple of minutes. Meanwhile, an additional wrinkle occurred to me overnight, there could be a "script won't complete" running, which ordinarily Firefox will show by an alert box which takes a while to appear and then a while longer to respond to kill and don't ask again, and which other browsers may not even show, and that could spring even from browser plug-ins (some versions of some of them get in the way from the background, and most people will have them). A separate downloader script could be used for large (or all) files.

Anybody else have any ideas how to resolve this problem?

I just reviewed the PM and e-mail of Apr 11+12 to refresh my memory. We both encountered the ongoing lag, with several machines between us, varied RAM, varied connecton speeds, etc., plural browsers, no effective difference in outcome, won't download the gb class file.

I consistently got 500: "Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. More information about this error may be available in the server error log. [. . .] Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request."

That would owe not to OC but instead to something as simple as a mistaken .htaccess file or php.ini settings that the server just does not like, or as potentially complex as Apache's own config or the the vpn and os. The server error could trace to Apache or deeper to vpn rather than deeper even to the underlying os. However, those setups and settings should be relatively easy even if time-consuming to troubleshoot.

Possible even if iffy Bingo. Linux distributions are somewhat less sensitive to this than are Windows versions, but both vary, along the way down or up through versions and tweaks, in whether and how well under what circumstances they can handle or even see files larger than certain ceiling sizes. I'd pause to double-check the os and vps or vpn [if any there be] versions and whitepapers. Versions of Apache won't be causing the problem, although the Apache configuration directives could be problematical relative to Apache's own context in os, vpn, and php. Versions of php.exe could be causing it, relative at least to php.ini directives.

Hi Butte,
Check out the thread I linked to below. It really seems to point to OC not sending the download to a forced "file save" in the browser. Like one of the posters, I have no problem with large files downloaded via other applications on my server, just OC. They all pop-up a "file save" window. This is what OC should do.

http://forum.opencart.com/viewtopic.php?t=36746

There ARE a couple of (rather pricey) download extensions that I can purchase which have fixed this bug as part of their download package, but really I can't see paying a bunch of money for all the extra features when I just want OC to offload the downloads of large files.

Houston, we do have Bingo. It evidently is, at least in pertinent part, an Apache setting, in .htconfig and alternatively in .htaccess, for the non-standard Apache module mod_xsendfile (add and enable it). The tradeoff (in not having or having the non-standard Apache module) is between php and Apache controlling large downloads, with respective overload and routine memory requirements, relating to the server (notwithstanding what other programs do with or on it), and beyond the scope of download extensions which would not in and of themselves add much of anything to the non-standard module without deploying it themselves. Thank you, cheepnis, for the link, with its own link to http://codeutopia.net/blog/2009/03/06/s ... e-and-php/ for instructions, but whose own download link isn't working (search web for the module, it'll be somewhere, probably even in compiled versions), and, of course, a compiler can be found. (That entire thread is useful.) Absolutely make a backup of .htconfig before you even open it, then make stepwise backups as you make any changes, so as not to drive yourself batty with undo and redo in your pure text editor (ONLY a pure text editor for .htconfig). You'll find in there a maze of instructions and directives and hypertouchy syntax. You can zip straight to the module section with the editor's own Find, just to put in the new lines,

# enable xsendfile
XSendFile On

# enable sending files from parent dirs
XSendFileAllowAbove On

and then you can pore over the file to see what else you can make it do. You'll enjoy the effort and learn quite a bit by it.

For practicalities, you'll have seen these, but for others Xsecret and Qphoria added these
http://forum.opencart.com/viewtopic.php?t=36746#p177135
http://forum.opencart.com/viewtopic.php ... 46#p263149
on code, and my minor note speaks to compiling at
http://forum.opencart.com/viewtopic.php ... 06#p415106

Minor Edit above, you'll see why.

Thanks Butte, I'll give this a shot when I get some free time (in-laws coming to town tomorrow :-O )

Do you expect Xsecret's edits to catalog/controller/account/download.php would be all I need to perform once xsendfile is compiled and activated? I wish I knew how to make that edit (assuming it works) into a vqmod, so I don't have all this hacked code everywhere.

How do you think the paid download extensions resolved this (since they wouldn't require xsendfile)?

I suppose it gives you a viable reason for escaping them for a little while. I'd look over Xsecrets' and Qphoria's edits, I think the latter might be the simpler one, but a backup will keep the original safe and sound. Try to think of it as customized, not as hacked; the whole thing is changed from subversion to the next, albeit with general rather than custom changes in mind, and custom changes expressly accommodate immediate installation needs. Even vqmod approaches have version sensitivities, and must eventually be revised even though meanwhile they don't need careful transplants to the next subversion. Meanwhile, vqmod syntax is fairly straightforward in finding and standing in for sections of core, so that would be doable without undue headache in order to use the edits. I doubt that any of the fee download extension "goes there" where Apache is center stage when "the hook" hauls php to the side, and that can't be done by vqmod without resorting to Apache itself. Using the Apache module circumvents changing anything in OC, the huge download is simply yanked out of php's mitts. I'll take a look, maybe tonight, at module xsendfile and suitable compilers (the idea is basic, get the source, get current compiler good for Apache version and processor, compile it, slip the compiled into place, change .htconfig or .htaccess, proceed at will), as well as my own Apache .htconfig[(s) on several servers] (made decisions, don't remember what all of them were).

Okay, here we go. It's actually not daunting.

Part I . . .

(1) Apache apxs is Apache-resident compiler is a perl script;
if not part of original package use a devel package;
see http://www.bullfreeware.com/affichage.php?id=1539 but download rpm package at:
http://www.bullfreeware.com/download/bi ... .1.ppc.rpm
open it just as any other compressed .zip, .rar, .arj, .gz, .bz2, .tar and, .rpm files
see file list included at:
http://www.openmamba.org/distribution/d ... devel.i586
then pluck apxs, put it in Apache's own /bin/

(2) choose module for operating system (win binary or linux packages) at:
https://tn123.org/mod_xsendfile/
links are these:

mod_xsendfile.c
SHA256: 8e8c21ef39bbe86464d3831fd30cc4c51633f6e2e002204509e55fc7c8df9cf9
download is:
https://tn123.org/mod_xsendfile/mod_xsendfile.c#hash

(sha256:8e8c21ef39bbe86464d3831fd30cc4c51633f6e2e002204509e55fc7c8df9cf9)

Source tarball (gz): mod_xsendfile-0.12.tar.gz
SHA256: 9078ec28697d672a7f8aa3a19180109c1ccf73dc6aa335e856d1129344566b7e

Source tarball (bz2): mod_xsendfile-0.12.tar.bz2
SHA256: 6184d3f7535b34f08ea4e665b55498d5f76673d2a816cf2ee3eaae203c2d780b

Win32 binaries: mod_xsendfile-0.12.zip
SHA256: 75e6a8af00112a7262880e5e6823d02f14b6e84fed8305fa0351a428d1c1529e
download is:
https://tn123.org/mod_xsendfile/mod_xse ... 2.zip#hash

(sha256:75e6a8af00112a7262880e5e6823d02f14b6e84fed8305fa0351a428d1c1529e)

GitHub repository: http://github.com/nmaier/mod_xsendfile
Beta version: version 1.0 beta1

(3) compile module:
apxs -cia mod_xsendfile.c

(4) load module: loads the named module from the modules subdirectory of the ServerRoot
LoadModule module filename
LoadModule module mod_xsendfile.so
in Linux with putty.exe either:
sudo ln -s /etc/apache2/mods-available/xsendfile.load /etc/apache2/mods-enabled
or:
sudo a2enmod xsendfile

(5) When the module mod_xsendfile.so is compiled and installed, it'll wind up in Apache's own /modules/

(6) Restart apache

(7) in .htaccess add these TWO lines in this sequence:
XSendFile On
XSendFileAllowAbove on

(8) references, in unmitigated Apache-speak:
http://httpd.apache.org/docs/2.2/programs/apxs.html
http://httpd.apache.org/docs/2.2/mod/mod_so.html
http://httpd.apache.org/docs/2.2/mod/

(9) other references, mitigated Apache-speak made easy:
http://www.devshed.com/c/a/Apache/Build ... ant-It/12/

(10) references, module overview, instructions, configurations, links (some specifically speaking to Debian, RedHat,
or other Linux), for Apache2 xsendfile module:
https://tn123.org/mod_xsendfile/
http://www.screenage.de/blog/2008/02/22 ... h-apache2/
http://codeutopia.net/blog/2009/03/06/s ... e-and-php/
http://www.qc4blog.com/?p=547

Part II . . .

There is no such thing as a bad nap.