I believe that you must normally restart apache for php.ini changes to take affect. The fact that the changes show up in phpinfo() may or may not indicate that the changes are actually in effect. If your ISP has not restarted apache, you may want to ask them to do so in order to save yourself a lot of head aches. If that is not the problem, then read on.
In your initial request you mentioned that you suspected that HTTP_KEEP_ALIVE was suspect and you asked for information on how to change that environmental variable. The HTTP_KEEP_ALIVE setting in apache controls how long the server wait for a second request on a single connection before closing the connection. This setting is typically set to something like 15 seconds and would not affect the behavior of your script. If you look at your phpinfo() under the apache heading you will notice a row called "Timeouts". There are two settings listed here. The first is "Connection" which is typically 300 and the second is keep-alive which is typically 15. If your ISP has 300 set for keep-alive then you may want to advise them to change it because it leaves unused connections open for 5 minutes clogging up memory and child processes. I suspect, however, that it is the "Connections" setting that is set to 300. If that is the case then your ISP can open httpd.conf and edit the line that says: timeout 300 and change it to a larger number. They could also change this setting to "0" which means there is no timeout. That could also cause problems, however, because abandoned connections could tie up system resources. This may solve your problem, but I dount it. This timeout setting controls the amount of time that apache waits for three things: 1. The total amount of time it takes to receive a GET request. 2. The amount of time between receipt of TCP packets on a POST or PUT request. 3. The amount of time between ACKs on transmissions of TCP packets in responses. In other words, as long as data is flowing apache will not timeout. I have a script that automatically generates 20MB word files and apache has no problem keeping the connection alive for the 30 minutes it takes to download the data over a slow connection despite the fact that "Timeout" is set to 300. If your php.ini settings are indeed correct, it may well be that apache is timing out for some reason, but if that is the case it is caused by one of the three reasons above. The first reason is not the issue because you are not using the GET method. The third reason is not the issue because ACKs are sent by the receiving host rather than the sender, so apache is not expecting ACKs. That leaves only the second reason: The amount of time between receipt of TCP packets on a POST or PUT request. If this is the problem, it would indicate that your browser has stopped sending packets for more than 300 seconds. If you have not done so, you may wish to monitor the data flow to determine if this is the case. If so, then your browser is timing out for some reason unrelated to apache or php and you may want to try another browser. If this is not the problem then you have me stumped. Fred Fred <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Did you read my post? I did all of that *before* I posted my question. > > Anyone else have a suggestion? > > TIA > > Fred > > On Wed, 05 Dec 2001 05:16:38 -0500, Mirek Novak wrote: > > > fred wrote: > > > >> After all of this, and you give me the wrong answer. If you read the > >> PHP manual, you will see that set_time_limit falls defaults to > >> max_execution_time, which I already have set to 2400, so your answer is > >> irrelevant. That is not controlling HTTP_KEEP_ALIVE, which is > >> defaulting to 300 seconds somewhere - probably httpd.conf. > >> > >> Now who is lazy? > > > > it was ONE question to google.com: +"large file uploads" +php results > > in > > http://www.phpbuilder.com/forum/read.php3?num=2&id=137901&loc=0&thread=11834 0 > > > > -X- > > > > > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]