Slashdot Mirror


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?

20 of 56 comments (clear)

  1. Don't bother looking or anything by Oriumpor · · Score: 2, Informative

    For apache 2.0, GOOGLE says it does

    1. Re:Don't bother looking or anything by Anonymous Coward · · Score: 2, Informative

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

    2. Re:Don't bother looking or anything by Anonymous Coward · · Score: 1, Informative

      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).

  2. Threads by kompiluj · · Score: 5, Informative

    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.

    --
    You can defy gravity... for a short time
    1. Re:Threads by Bistronaut · · Score: 4, 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:

      • 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.

    2. Re:Threads by GoRK · · Score: 4, Informative

      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.

    3. Re:Threads by Electrum · · Score: 2, Informative

      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.

  3. php works fine by B00yah · · Score: 2, Informative

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

  4. Re:1.3.31? by bofkentucky · · Score: 2, Informative

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

    --
    09f911029d74e35bd84156c5635688c0
  5. PHP works fine with Apache 2.0 by FattMattP · · Score: 4, Informative
    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

    --
    Prevent email address forgery. Publish SPF records for y
    1. Re:PHP works fine with Apache 2.0 by Neon+Spiral+Injector · · Score: 4, Informative

      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.

    2. Re:PHP works fine with Apache 2.0 by Chester+K · · Score: 2, 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.

      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.

      --

      NO CARRIER
  6. Re:mod_ssl? by Ryquir · · Score: 3, Informative

    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

  7. This is NOT a release. by Orbital+Sander · · Score: 4, Informative

    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.

  8. The 1.3.31 RC Tarballs have been removed by jimjag · · Score: 5, Informative

    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.

  9. 99.999% of us don't need 2.x by Splork · · Score: 2, Informative

    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.

  10. Use PHP with FastCGI by Fweeky · · Score: 3, Informative

    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.

  11. Apache 1.3.31 is NOT released.. only 1.3.29. by EMR · · Score: 4, Informative

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

  12. try to run it with nss_ldap by MaoTse · · 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 ;-).

  13. 1.3.31 is *now* officially released by jimjag · · Score: 2, Informative

    Read all about it:

    Apache 1.3.31 Announcement