This file I uploaded separately:
http://www.cityofdanville.org/filestore/August_25_-_Public_Services...


This file was uploaded through Concrete:
http://www.cityofdanville.org/index.php/download_file/-/view/420/...


More information:
We have 2 buildings. Testing internally, inside our main building where the server is located, the file downloads file.

At our remote building (with a t1 to our main building), the file stops midway.

As I stated, visitors have emailed me telling me the same. It seems the faster the connection you have to the server, the less likely it is to stop in the middle.

--

AN IDEA: I was previously using 5.3.1 and noticed that in that version, the download wasn't forced (rather, with Adobe Reader installed, I could view the PDF in my browser).

Could this be related? Possibly the wrong file-size being sent in the download header?

I'm guessing this could have something to do with the php or apache timeouts, maybe?

I've already checked Apache timeouts - it's set at the default 300 seconds. Usually the download stops after about 20 seconds. Also this would happen on both Concrete-managed files and my manual upload of files if it was Apache.

I didn't realize PHP had it's own timeouts. I'll check the config and post back. Thanks for the tip.

Thanks Tony - I think this is a bug (or at least SHOULD be a bug).

I increased the max_execution_time variable in php.ini and the problem went away. This *should* be a bug because the file download is typically independent of the script running. To me without digging into the code, appears that the script is continuing to run while the file is downloading. When the limit is reached, the download cancels as well.

when you use a script to stream a file download because you want to add some security checks, you're using php and not just a simple file download.

you therefore have to care about max_execution_time (or avoid using a script to download files)

Duh, I didn't put think before I posted. Thanks for the smackdown :)

maybe this isn't a bug, but we could probably still add something so that this problem doesn't happen with other people. i don't see anything wrong with adding max_execution_time with some really long timeout to that download script. suppose this could be done as a global variable, like DOWNLOAD_MAX_TIME. thoughts?

I really think the user should be redirected to the file instead of streaming. I've noticed a definite slowdown due to this.

Let the script do the security check - but then forward on to the correct file. I know this isn't "real" security, but the file is at least masked.

Out of the box there's no access restriction to the files directory unless done manually.

We'll think about this. I could see this being the default behavior, with a config constant setup to force it to the more secure mode (which is currently the default). Obviously, if files are outside the webroot, they will have to continue to stream through.