Is that really our position on the issue, anyway? The PHP core is perfectly stable on Apache 2 -- It's just a few extensions that cause trouble... We should probably be saying that instead of just rejecting Apache 2 entirely.

But if we do that then we can expect much more useless bugreports, so the current statement is safe, we just need to clarify it.

This was already discussed in #27323.

But Derick, what do you think that needs to be changed in the documentation?
I may add whatever you decide that's worth change.

I read 27323.

As a admin I plead ignorant to apache2 at the moment. I resolved to worry about it one the apache group were pushing it as the best.

Last week I hit the apache website - curious as to where they were up to and found that their site indicates that apache2 is the best option. Their download pages say "apache2 is the best available version" and "also available apache1.3"

I bring this up as 27323 and the apache group obviously have a difference of opinion on apache2, perhaps the difference is only when apache2 is running threaded? In which case perhaps php and apache2 would be OK in production on non threaded apache2 servers? Which of course should be reflected in the documentation :)

:) Stewart

We are not talking about just Apache2 here.  We are talking about Apache2+an MPM+PHP+3rd Party Libs.  The folks at apache.org are only concerned with Apache2 itself, and for serving up static files it is better than Apache1 in many respects.  However we have to worry about a lot more stuff here.  In fact, we couldn't care less about serving up static files.  The main issues as I see them are:

1. Thread safety issues.
   - It is very difficult to track down threading problems and we don't have decent tools to help us.
   - The thread safety of many 3rd party libraries are unknown quantities and can depend on the OS, libc and even compile flags.
   - Many distributions seem to ship with the Worker MPM as the default and that is the MPM that gets the most attention.  This is a hybrid multi-process, multi-threaded MPM.

2. You can eliminate the threading problem by running the prefork MPM which effectively makes Apache2 behave just like Apache1 in the way it forks processes and serves one request  at a time per process.  Issues here:
   - Apache2 itself is rather fringe still.  It has approximately a 5% marketshare vs. 65% for Apache1 at the time of this and out of that I would guess the majority are running the Worker MPM.  So we are talking about a fringe MPM in a fringe server.  This means it has not had anywhere near the attention from people running large production web server farms that it needs for me to comfortably say that this is a solid piece of code with all the kinks worked out.
   - The benefits of moving to Apache2+prefork are questionable.  The new filter API would be one of the benefits, but it still has some issues and by default we run PHP as a handler, not a filter currently.  You can optionally run it as a filter but people have had problems with that.

Until such a time when enough clueful PHP people think there are enough realworld useful features in Apache2-prefork or even Apache2-threaded to actually sit down and bang away at PHP and the majority of the PHP extensions under Apache2.  Or if enough regular users report back that they tried it and had absolutely no problems then we will change our reccomendation, but for the time being I don't think that we in good faith can tell users that Apache2+PHP is something they should be putting into production.  

Ahhh enlightenment :)

That gives me alot of info as to the issues with apache2 and php and why php is considered bad.

Added to that the PHP group seem to be facing a chicken and the egg scenario. Alot of sites probably will not shift to PHP (I know my servers won't be) until php is considered safe for apache2. So I guess in large respects apache2 could stay fringe for php deployments.

My...recent eagerness...to see apache2 and php in production started with subversion being released..among other things. 

Seems to be a real chicken and egg scenario the php group is faced with. apache2 is fringe. Once apache2 has a higher market share, then more people will probably code and get php to work well with apache2. But considering the popularit of apache2+php, apache2 probably won;t increase market share significantly until either php and apache2 are considered safe for a production environment or apache1.3 is dropped by the apache group.

Anyway back to this bug report. Much of what was said in the previous post gave me sufficient information to give me enlightenment. I am sure it would for others as well. Perhaps that could be included in the docs?

Cheers - and thanks for the enlightening,

Stewart

I suppose it is a bit of a chicken and egg situation with the one exception that we have a nicely working chicken already.

Also note that you do not need Apache2 for SubVersion.  You can use the standalone svnserve instead.  See http://lxnt.info:8888/book/book.html#svn-ch-5-sect-4.2

Reading the first comment your probably right the chicken itself is fine just some of the feathers need fixing (e.g. some extentions abnd their libs being the issue not core PHP) - at least thats just info from reading the first reponse to this bug report.

Thanks for the tip on subversion. Will look into that this week.

I for one would much prefer to use php on apache 2.  One of the main reasons for this is that just about every linux distro known to man won't install apache 1.3 for me anymore.  I have to manually install it and manually do all of the updates or look to a 3rd party to get package files for whatever distro I happen to be installing on.

It would be much nicer if I could just use the version of apache that came with the distro and use the standard update tools to do security/version updates.  It seems like there is no really good reason not to except "well it's no better and nobody really wants it."  I'll bet that a lot more people would start running php on apache2 once it became stable.

Is there anyway to make it so that php will only run on the prefork MPM so that you can at least say that php is stable under those conditions?  It seems like that would satisfy the people who want to use php on apache 2 but not force you to deal with the thread safety issues for now.

It's true that we have a fully evolved 'Chicken' under Unix. However, under Windows, it's still in its pre-chicken state. A2 deals with that. It's what the APR is all about, dealing with poor POSIX conformance under windows.  

In my experience it does work better than A1 with PHP4, but persuading people of that is hard because of the notice the PHP developers have put up.  

<rant> Remember some people *have* to run MS Windows-- the decision out of their hands. And that is quite apart from the fact that there are (shriek! heresey!) situations where it is more appropriate than Unix.</rant>

unable to get apache2.0.49 work with php4.3.6 and use php as a static library, only the dso version works :-(

Can we have adjusted the information on the PHP apache 2 manual page http://www.php.net/manual/en/install.apache2.php) from:

> *Warning*
>
> Do not use Apache 2.0 and PHP in a production environment 
> neither on Unix nor on Windows.

To something more clear. This line has been the death to many to try Apache 2. The statement should be more along the lines of "Some PHP modules are not fully tested for running in the default multithreaded environment of Apache 2. Core functions should be safe for this environment. To be extra careful, it is recommended to run Apache 2 in prefork mode which should avoid problems as it runs similar to Apache
1.3.x in this mode." Something along the lines of this and then for there to be a list of modules tested / check and not tested which could have problems. A comment was made:

"The PHP core is perfectly stable on Apache 2 -- It's just a few extensions that cause trouble... We should probably be saying that instead of just rejecting Apache 2 entirely."

This single ambigous line of "Do not use..." is not productive.

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

Some extensions are not stable, anyone care to comment on which extensions are stable.

Greg Magnusson
Cyborg Spiders Web Development

This needs to be in the faq and linked to from the apache2 installation docs.

It is already linked from the new installation chapter.

The link has been in language-snippets.ent (within the warn.apache2.compat entity) for over five weeks, the manual was built a week ago, yet the change doesn't show up.  This is not good.

For those wanting to see the faq:
http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2

The language-snippets.ent problem now exists in bug #29353

Can we add a link to the new Installation Chapter - Apache 2 info to the Apache 2 install info in http://www.php.net/manual/en/install.apache2.php ? Also, the answer to the question in the install chapter still seems to be disappointingly not recommending Apache 2 in a prefork mode. Why is this the case? The only negative issue I've heard of Apache 2 / PHP is in threading mode. If that mode is not used, why can it not be the recommended or atleast a recommended platform. Is there any other reasoning behind trying to stick with Apache 1.3?