Apache HTTP Server 1.3.31 Released

efranco writes "Apache Software Foundation had released today a new version of the 1.3.x Apache webserver branch. How long this branch will last? Despite the interesting new features introduced in the 2.0.x branch, it seems that the branch 1.3.x is still the most used around the world." Errr, is PHP playing nicely with Apache 2 yet?

Comments

Don't bother looking or anything

[Oriumpor]

For apache 2.0, GOOGLE says it does

Re:Don't bother looking or anything

[Anonymous Coward]

No. It says "Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows."

Re:Don't bother looking or anything

[justMichael]

No. It says "Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows."

That document is also almost 9 months old, to the day: Last updated: Sat, 09 Aug 2003.

I have numerous sites running apache2 and PHP and have had no problems.

The only issue I have is no mod_throttle, and I'm not the guy to try and port it to the 2.x API ;)

Re:Don't bother looking or anything

[Kethinov]

I ran Apache2 on my iBook for months without issues with PHP. I eventually pulled it though because performance was slower than 1.3.x.

Re:Don't bother looking or anything

[Anonymous Coward]

I've had problems with Apache 2.0, mod_deflate, and PHP not playing nice, that I didn't have with 1.3 and mod_gzip in a similar setup.

I set up mod_deflate to only handle content-types of "text/plain" and "text/html", but in a PHP message board I use that stream files(attachments) and specifies the content-type, mod_deflate compresses the content, even when it shouldn't(gzipped files, for example).

I did implement a workaround, which involved using PHP's built-in output compression support, and only using mod_deflate on static files(and SSI documents).

Re:Don't bother looking or anything

[Sharth]

The problem with using php and apache2 is quite simple. most of the mpms that apache2 uses (any but prefork i think) are threaded. non-threaded code doesn't play nice with threaded code. so.... The new zend stuff in php makes it completly thread safe so that works fine. The problem is that some of the modules distributed by php.net and some (maybe most) 3rd party modules are not thread-safe, and under-high load, can cause stuff to crash and what not.

Re:Don't bother looking or anything

[Anonymous Coward]

w00t u r teh geniouss!!

did yuo raed tihs onnteh kur0shim??

Re:Don't bother looking or anything

[Dysan2k]

Which ones, though? Is there a list somewhere that states which modules are currently not thread-safe? I'd like to see PHP become fully threadable and play nice with Apache2.. how many years have they had to fix that now?

Re:Don't bother looking or anything

[Inominate]

PHP4/5 is fine to use with Apache2.0, However not all PHP extensions are thread-safe, and probably never will be. So if you use any non-default extensions, those libraries may, or may not work correctly under apache2.0

1.3.31?

[platipusrc]

I generally run the latest version of major software that I use, and I use Apache's httpd. The version I'm running today is 1.3.29. Did they skip 1.3.30, or was it a silent buggy release...or is the story a typo?

Re:1.3.31?

[Anonymous Coward]

RTFA! "1.3.30 was not released"

Re:1.3.31?

[bofkentucky]

1.3.30 was had a windows specific bug-fix to 1.3.29 if IIRC.

Re:1.3.31?

[Anonymous Coward]

He lied. They died.

Threads

[kompiluj]

Apache 2.0.x is tuned with multithreading in mind, whereas 1.3.x is not. This is root of problems with PHP which libraries are not all thread-safe. It also means that in order to fully benefit from Apache 2 you must have OS with multithreading support. Linux 2.6, FreeBSD 5-CURRENT or (cough!) MS Windows NT (2k, XP, 2003, etc.) or MacOS X (this one I'm not quite sure about - but it has Mach kernel so probably yes) or Solaris.

Re:Threads

[Bistronaut]

Apache 2.x can be run in multi-threaded mode, but it can still do multiprocess just as well (if not better) than 1.3.x.

The multi-thread capabilities of Apache 2 in no way detract from its multi-process capabilities. You can run in just multi-thread mode, just multi-process mode or any balance between the two that you want. The multi-thread capabilities were added to address performance problems on platforms that were not very efficient at spawning new processes (Windows and others).

If there are still some PHP libraries that are not thread-safe (and you need those libraries), just don't run in multi-threaded mode. If you're on Linux, that's probably what you were doing anyway. (If you're on Windows - well, why the hell are you running a production server on Windows?)

Of course, there are valid reasons to stick with 1.3.x. For example:

• No real point in transitioning existing installations - 1.3.x is probably good enough that it's not worth the hassle to change to 2.x.
• Your vendor is behind the times (I found that Debian's support for 2.x isn't as good as it is for 1.3.x yet).
• I'm sure there is a third reason I can't remember.

In general, I follow the "2.x is default for new installations" philosophy.

Re:Threads

[GoRK]

Don't forget to add that the multithreading was also added to support easier/quicker/better data sharing among request handlers. Stuff like mod_perl is *really* taking advantage of this now. It also facilitates management of virtual hosts from both a resource and a security standpoint. You can have a seperate process for each vhost running in its own security context and resource limited (cpu, bandwidth, etc.) easily and then configure per-process thread/request limits for each virtual host.

Debian (testing/unstable) support for 2.0 is as good as any distro's IMO, but of course there is little to no support for it 'out of the box' on woody, and unless you go for backports.org stuff, it's kind of hard to trust some of the 3rd party deb repositories for this kind of thing.. So still it's a problem with Debian, but nothing other than what has plagued debian for all time -- releases that are actually too infrequent.

Re:Threads

[Anonymous Coward]

Third reason: a lot of modules (mod_perl, mod_php, others) haven't been updated to "production quality" for apache2.

mod_perl is still 1.99_something (beta), and has been for a while. A lot of projects (Mason, Bricolage, etc.) and modules need to be ported forward and thoroughly vetted. A lot of things have changed under the hood, and tons of new things are possible, but it's most of it is under development or in "beta".

Re:Threads

[Electrum]

If there are still some PHP libraries that are not thread-safe (and you need those libraries), just don't run in multi-threaded mode.

Or use FastCGI.

Re:Threads

[cscx]

Debian (testing/unstable) support for 2.0 is as good as any distro's IMO,

Werd. I am using Apache2 w/ mod_perl2, PHP, and ASP (which relies on mod_perl). Works great!

PHP?

[brunson]

I've been using PHP with Apache2 for months now.

Re:PHP?

[bzant]

I agree, I am using 2.0.x with PHP 4.3.4 and MySQL 4.1 and have seen no problems. Now my apps are pretty basic so that might be why it all runs, but has been solid for 5 months now.

Re:PHP?

[QuantumSpritz]

In terms of instability and such, I'd be far more worried about MySQL 4.1 than Apache 2 - especially as the compatibility issues haven't been completely nailed out (Connector/J, etc)

php works fine

[B00yah]

on my sites, along with virtually every other plug-in and feature I need.

Re:php works fine

[Anonymous Coward]

Too bad all the animations make your site unreadable.

PHP works fine with Apache 2.0

[FattMattP]

Errr, is PHP playing nicely with Apache 2 yet?

Yep, and it always has as long as you use the prefork MPM which is the default which you compile Apache. That makes Apache 2 service requests in the same manner as 1.3. Where people have problems is when you use PHP with the worker MPM which uses threads. Although the PHP core is supposed to be thread safe the developers can't guarantee that other PHP modules will be. Stick with the prefork MPM and you'll be A-OK.

Someone correct me if I'm wrong, but I think the big hangup in adoption at the moment is mod_perl. mod_perl 2.0 is supposed to fix that but it's still under development at the moment.

Here's a link for people who wonder what a MPM is: http://httpd.apache.org/docs-2.0/mpm.html

Re:PHP works fine with Apache 2.0

[nemui-chan]

Thats correct. No one I know is willing to use mod_perl under a 2.0 environment because it has 'issues' according to the guys on #apache freenode.

Re:PHP works fine with Apache 2.0

[sweede]

I personally am waiting for the perchild to be fixed so i can run php in virtual hosts as the user instead of running as apache like suexec does. Having everything group writeable for applications like Gallery sucks as someone could exploit that and delete my photo gallery or who knows.

Re:PHP works fine with Apache 2.0

[Neon Spiral Injector]

You can have almost the same funtionality as mod_php if you use a CGI php with Linux's misc_binfmt to register *.php files with /usr/bin/php. You just have to chmod +x each php script and set the ExecCGI option on directories you want to run PHP from. Then you can use suexec to separate users.

Of course it does limit you to features that are availible to the CGI version of PHP. But that is just about everything, except some of the PATH_* varibles.

Other than that, I wouldn't hold your breath over the PerChild. I held mine for about 6 months, and I got nothing but blue in the face. That is when I resorted to the system above.

Re:PHP works fine with Apache 2.0

[sweede]

That rocks, if i had mod points and i didnt post in this article, i'd mod you + insightfull, but then you probably wouldnt of posted that in here because i wouldnt of mentioned the perchild situtation..

o well, maybe someone else will :)

Re:PHP works fine with Apache 2.0

[Chester K]

Someone correct me if I'm wrong, but I think the big hangup in adoption at the moment is mod_perl. mod_perl 2.0 is supposed to fix that but it's still under development at the moment.

mod_perl 2.0 is still technically in development (1.99_04 is the latest version), but I've found it stable enough to use in production, and have been without problems for quite some time now.

It's a little crufty, especially around the (almost necessary) libapreq2/Apache::Request library, and as far as API documentation goes, but if you're familiar with mod_perl 1.x, it's not that different.

Prefork MPM assumed, only a madman would run on the worker MPM.

Re:PHP works fine with Apache 2.0

[perlchild]

I'd also sugges that the fact that there is several MPMs, while beneficial in the long run, is slowing down apache 2.0 acceptance.

Think about it, all the third party modules had to support one apache(1.3) now they have to be thread-safe, or recommend that you use prefork. Prefork is ok, but most of the hype that was generated when apache 2.0 was launched was for the other mpms (perchild is an especially nice idea) but most third-parties have either never heard of them, or decide not to support them.
Now if you run a server for other people and take requests for apache modules(think "good" virtual hosters) that means prefork is the only acceptable MPM, as it's the most compatible. Prefork is approximately as performant as 1.3 for a lot of loads, but heavier in some cases, and is less tested. Until more of the extant code gets thread-safety(off-topic question: is slash thread-safe?) that means unless your hardware DOES run faster with 2.0, why change?
And of course, most third party apps developers are in no hurry to invest the time to thread-check their apps, if noone is using 2.0 with worker. It's a chicken and egg problem.

mod_ssl?

[Arlo]

Someone let me know when mod_ssl gets updated too. That's when I upgrade.

Re:mod_ssl?

[Ryquir]

Uh you did know that the seperate add to apache and build mod_ssl is only for 1.3.X variants right? The same functionality is found included with Apache 2.0 see Apache 2.0 Docs

Yes, Virginia, there is a PHP

[aminorex]

My employer has been using 2.0.40 with php 4.2.2
for a coon's age. Ignore the scarewords. (Yes,
using non-threadsafe 3d party libraries with a
multithreaded application execution model is prone
to bugs... so don't do that, doh!)

This is NOT a release.

[Orbital Sander]

As you can read in this message, this is not a release but a Release Candidate. It was posted in the /dev/dist directory so testers can have at it.

Now, if all of you want to download and test this release, and report your findings back to the httpd-dev mailinglist, by all means go for it.

But this is not a release yet.

The 1.3.31 RC Tarballs have been removed

[jimjag]

As Sander mentioned, 1.3.31 is NOT released. If it had been, you would have seen an announcement... Is being first to post such a big thing now that we don't even bother *checking* the facts?? Because of this totally mistaken idea, the tarballs on httpd.apache.org/dev/dist/ have been removed, which means more work for those of us coordinating and testing the release. However, to avoid people running unofficial releases, this seems to be what we need to do. Depending on the viability of the 1.3.31 RELEASE CANDIDATE tarballs, 1.3.31 may be released (*really* released) in the next few days.

The reason: API stability/compatability

[moeymo]

If you've highly customized instance of Apache, the configuration API changes make it expensive to upgrade.

You can stay in the old branch or spend hours figuring out how to do the same thing with the latest version. People take the old until they need new features in the new version.

The good news is that Apache is stressing that configuration/public APIs need to be more stablea across versions. Thank you!

99.999% of us don't need 2.x

[Splork]

1.3.x is great. 99.999% of us don't need 2.x. and of the remaining 0.001% that think they do at least half of them would be better off buying more than one computer to serve their website.

Re:99.999% of us don't need 2.x

[phrasebook]

Sense a lot of that makes.

Use PHP with FastCGI

[Fweeky]

mod_fastcgi should be thread safe, and the FastCGI PHP SAPI module is probably better tested than the Apache 2 ones. Plus, if PHP crashes it doesn't take Apache with it, and you can do fancy things like jailing the daemonized PHP's, or running multiple servers as different users.

OK, I;ll bite

[Run4yourlives]

How is PHP a joke, specifically?

Re:OK, I;ll bite

[Anonymous Coward]

How is PHP a joke, specifically?

I laugh at it every time I have to work with it. Well okay I laugh at it when I'm not angry with which is really most of the time.

Function names aren't very orthoganal and they change. Return values have changed between dot-releases. They don't backport bug fixes, the solution is "upgrade to the most recent release" which might break code compatability. Scopes are not intuitive or even clearly defined AFAIK. (So changing $foo is the same as changing $GLOBALS['foo'] but not when you are inside a function call. $foo might refer to $GLOBALS['foo'] or $_GET['foo'] or $_POST['foo'] or just $foo and maybe more.) Regular expressions don't work well (ie they are not compatable with perl or sed because you have to escape things with seemingly random numbers of backslashes). The preg_replace functions are more code then equivalent code in Perl. The database interface (in php4 at least) lacks any abstraction and depends on different functions depending on your database (mysql vs postgresql). Error message have been getting better but it would be nice to have some sort of "use strict;" like option (which is script wide and not server wide). Backticked commands don't save the return value of the run command. (Think of $? in bash and perl.) To get the return value you can't use backticks, shell_exec() or system(). You have to use exec(). All of which have different ways of getting different information about the command run. Comparison operations are mostly anoying. Don't ever compare a string to a number, just cast and convert yourself first. PHP is a weakly typed language but it's not worth guessing how things will be converted. You can't tell it to enforce declaration of variables. Undeclared variables are equal to FALSE, "", 0 and !isset() all at the same time. www.php.net has a nice search where you just type www.php.net/MySearchTerm but documentation like "This function is currently not documented; only the argument list is available." for apache_setenv() which takes a bool named "walk_to_top".

How's that for an anoying joke? No the joke is people rely on this thing to make money on the web. Then again it's not as bad as ColdFusion though and heck the ACM runs on Coldfusion.

Apache 1.3.31 is NOT released.. only 1.3.29.

[EMR]

1.3.31 is in development.. it has NOT been officially released..

Re:Simple Solution

[bofkentucky]

Not trolling here but all of the options you mentioned were java based ones. Java is not the be all and end all of languages, php has its place, just as java does. If you want to see PHP really in action, check out the horde project, yeah they have a forums/portal system, but on top of that they have a tremendous framework which can be used to add tremendous functionality to your website, ranging from FTP and NNTP gateways to a great calendar and contact manager app.

Despite the efforts of the Apache Foundation, IBM, the JBoss people and others, Sun maintains a stranglehold on java standardization and API's, which can be (and have been) changed on a whim.

<span class="rant">What pisses me off is the failures of JVM's to degrade gracefully, we have a management app for a device that is java based, but written to what appears to be Java 1.2/AWT, which JVM 1.4.* + moz 1.6 or NN4.8 pukes and crashes over, IE6 somehow stays alive, but throws exceptions all over the place. The product has been EOL'ed by the vendor but it is critical to our opperation and is the only reason I load IE ever</span>

try to run it with nss_ldap

[MaoTse]

I was really suprised when I had to switch to httpd-2.xx when I moved on to a Ldap based setup using padl nss_ldap library. (No apache ldap modules involved).

CGI with suexec on 1.3.xx just wouldn't work. All I had were segfaults ;-).

Problem vanished when I upgraded to apache2. Now all my CGI users are happy. And, of course I run apache in prefork mode ;-).

Re:Simple Solution

[Anonymous Coward]

yeah right, bet it relies on microsoft's non-java jvm.

www.php.net mirrors run *shock* Apache 2.0

[Anonymous Coward]

$ HEAD -e http://www.us2.php.net/install.apache2 | grep Server
Server: Apache/2.0.46 (Unix) mod_perl/1.99_09 Perl/v5.8.0 mod_ssl/2.0.46 OpenSSL/0.9.6g DAV/2 FrontPage/5.0.2.2634 PHP/4.3.2 mod_gzip/2.0.26.1a

$ HEAD -e http://www.uk.php.net/install.apache2 | grep Server
Server: Apache/2.0.48 (Unix) mod_ssl/2.0.48 OpenSSL/0.9.6g PHP/4.3.4

1.3.31 is *now* officially released

[jimjag]

Read all about it:

Apache 1.3.31 Announcement

Apache 2 vs. PHP

[bigbadbob0]

Apache 2 with prefork + php works just fine. No problems whatsoever. I've been running this in production for several months now handling 35k requests/day.

On a dual processor FreeBSD 5.2.1 machine Apache 2 can compile from the ports (I had to tweak the portfile, though I think this has been fixed now) using worker threads. It even runs and handles all I could beat it with using apache bench ( ab(1) ) over fast ethernet LAN.

That same worker thread setup with PHP dumps core all over the place.

choose your destiny

[chasingporsches]

right now i think it is just personal preference. i still use apache 1.3 on my macs because its what comes with OS X 10.3, and i don't feel like upgrading. and i'm doing all my development in PHP 5 and MySQL 5 now (due to the fact that by the time i'm done with what i'm writing, they will be stable) and PHP 5 works beautifully with 1.3. so no, i don't feel the need to upgrade. on linux, i toy around with 2.0, but i'm just so familiar with 1.3, it makes it easier. and multithreading and support for BeOS and OS/2 isn't reason enough to make me upgrade.

output filters

[David Jao]

What finally convinced me to switch to Apache 2.0 in at least one case is the external filters feature. I find filters useful enough to be worth all the extra baggage that 2.0 brings.

Even if you don't use mod_ext_filter directly, the extra programming hooks offered by the filter functionality are very useful for writing your own modules.