I have no experience with the Apache2 filter. On the few servers I use Apache2 on I use the handler SAPI and it works fine there as far as I can tell. lerdorf.com is running Apache-1.3 with the standard PHP Apache1 SAPI. No special setup on it. I have no idea why your Perl thing is doing something different on that link. I'm not a Perl guy. At a much higher level, it is a really bad idea to trigger any sort of long-running thing from a web request. It is way too expensive to either fork, or simply tie up an Apache process after the request in order for it to sit around and perform some sort of cleanup or cache operation. You are much better off doing these sorts of things out of band through a cron job or some sort of dedicated lightweight daemon designed explicitly for the task. The Apache process is quite heavy and should be used to handle short dynamic requests. For anything else, there are better tools for the job out there. -Rasmus Liang ZHONG wrote: > Sorry for bothering again, but I did not mention the other environment > on which I tested, since it has an access control to outsider. I saved > the info page to: http://liang.ns2user.info/php/info-train06.htm. The > php runing on as apache 2.0 filter module. And the resutl of the > experiment is same as the CGI SAPI one. > > Could you please also take a look for this php configration? I also like > to have a look at how the environment looks like of > http://lerdorf.com/red.php, if you think it is OK. > > Another question confruse me a lot is why the browser and perl code > behave differently in the return respond to the same link > http://lerdorf.com/red.php ? > > The user clients of our project are mainly harvesters which are written > in perl (like the one in my previous email). So I really hope the perl > code can work out an example then I will be able to find out a workable > configuration. > > I really appreciate all kindly help from you. > > Liang > > > >> Liang ZHONG wrote: >> > The php configuration is: http://liang.ns2user.info/php/info.php. I >> have >> > no read permission of those httpd.conf files so do not know how apache >> > configured. >> >> That shows PHP is running as a CGI. As a CGI PHP has very little >> control over anything. It is completely at the mercy of the web server >> to do everything. That's likele the source of your problem. You need a >> better server with PHP running as an Apache module. >> >> -Rasmus > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
