Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
 Topic: CentOS / Apache / PHP force downloads headache |
|
| Author |
|
tonusmaximus
Joined: 23 Oct 2012
Posts: 1
|
 Posted: Thu 25 Oct '12 18:50 Post subject: CentOS / Apache / PHP force downloads headache |
 |
|
Hi all,
Apologies if this is not the correct place or if this had been covered but I could do with some advice if possible.
I have a VPS running the following :
3GB RAM, 20GB HDD, GenuineIntel, Intel(R) Xeon(R)CPU X3430 @ 2.40GHz
CentOS release 5.4 (Final)
Apache/2.2.3
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c
PHP 5.3.3 (cli) (built: Jun 27 2012 12:25:4
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
My goal is to create a simple site that indexes audio files to share across the web.
I have been using numerous free PHP/Ajax file management scripts to help with this but the big issue I have is that if a download is triggered over PHP (force download) I simply can not browse the rest of my site - the pages will just struggle to resolve yet when I cancel the download the page resolves instantly.
My host thought it may be the script as I can successfully navigate Plesk but I have since tried other ones and the results are the same.
If I change the PHP module from FastCGI to Apache in Plesk the issue stops for a few minutes but then kicks in again after about 20-30 minutes.
I know this is vague and I am still very noob with this stuff but will provide more info if possible but I am quite sure it is a httpd.conf/php.ini config issue.
Any help appreciated!  |
|
| Back to top |
|
cbj4074
Joined: 02 Nov 2012
Posts: 24
Location: United States
|
| Posted: Wed 07 Nov '12 16:59 Post subject: |
|
|
One must assume that there's a legitimate reason for which you are passing the file to the user-agent via PHP. Are users required to authenticate before downloading, or similar? If so, are you calling PHP's session_start() function before serving the file?
The only time I've observed the behavior you describe was when I failed to close the user's PHP session before sending the file to the user-agent. Unless you are calling session_write_close(), explicitly, before sending the file, this issue seems expected.
The PHP manual says of session_write_close():
| Quote: |
End the current session and store session data.
Session data is usually stored after your script terminated without the need to call session_write_close(), but as session data is locked to prevent concurrent writes only one script may operate on a session at any time. When using framesets together with sessions you will experience the frames loading one by one due to this locking. You can reduce the time needed to load all the frames by ending the session as soon as all changes to session variables are done.
|
Sound relevant? |
|
| Back to top |
|
|
|
|
|
|
