Apache HTTP Server 1.3.31 Released 56
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?
Don't bother looking or anything (Score:3, Informative)
Re:Don't bother looking or anything (Score:2, Informative)
Re:Don't bother looking or anything (Score:4, Interesting)
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 (Score:1, Informative)
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 m
Re:Don't bother looking or anything (Score:1)
Re:Don't bother looking or anything (Score:2)
Re:Don't bother looking or anything (Score:2)
Re:Don't bother looking or anything (Score:2)
1.3.31? (Score:2, Interesting)
Re:1.3.31? (Score:3, Informative)
Threads (Score:5, Informative)
Re:Threads (Score:5, Informative)
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:
In general, I follow the "2.x is default for new installations" philosophy.
Re:Threads (Score:5, Informative)
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 (Score:2)
Werd. I am using Apache2 w/ mod_perl2, PHP, and ASP (which relies on mod_perl). Works great!
Re:Threads (Score:1)
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 (Score:3, Informative)
Or use FastCGI.
PHP? (Score:2)
Re:PHP? (Score:1, Redundant)
Re:PHP? (Score:1)
OK, I;ll bite (Score:1)
php works fine (Score:2, Informative)
PHP works fine with Apache 2.0 (Score:5, Informative)
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 [apache.org]
Re:PHP works fine with Apache 2.0 (Score:2)
Re:PHP works fine with Apache 2.0 (Score:2, Interesting)
Re:PHP works fine with Apache 2.0 (Score:5, Informative)
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 (Score:3, Informative)
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,
Re:PHP works fine with Apache 2.0 (Score:2)
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
mod_ssl? (Score:1)
Re:mod_ssl? (Score:3, Informative)
Yes, Virginia, there is a PHP (Score:4, Interesting)
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. (Score:5, Informative)
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 (Score:5, Informative)
The reason: API stability/compatability (Score:3, Interesting)
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 (Score:3, Informative)
Re:99.999% of us don't need 2.x (Score:2)
output filters (Score:1)
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.
Use PHP with FastCGI (Score:4, Informative)
Re:Simple Solution (Score:4, Insightful)
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>
Apache 1.3.31 is NOT released.. only 1.3.29. (Score:5, Informative)
try to run it with nss_ldap (Score:3, Informative)
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 ;-).
1.3.31 is *now* officially released (Score:2, Informative)
Apache 1.3.31 Announcement [apache.org]
Apache 2 vs. PHP (Score:1)
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 (Score:1)