Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Apache Software

Apache 2.0 Goes Beta 20

Great news from the Apache Conference. A new version of Apache 2.0 has been released as a beta. You can find more information in their announcement. In other news according to Roy Fieldling's talk on the state of Apache, as of their next fiscal year individuals should be able to make tax deductible contributions to the Apache Foundation.
This discussion has been archived. No new comments can be posted.

Apache 2.0 Goes Beta

Comments Filter:
  • by Anonymous Coward
    Well, here is the source from cvs []. Dont know if it works.
    There is some info on the modperl-dev mailing list [], Hope this helps. There is probably a lot more.
  • Well, if you want SSL support, I would stay away from the Apache 2.0.x series, I would consider mod_tls alpha quality since they only recently got it's SSL support working.

    Upgrading to Apache 1.3.19 and mod_ssl is the way to go for now, unless you feel the need to pay for Stronghold.

    There really isn't any easy way to merge the configuration file to 1.3.19. My best suggestion is to set up the new server running on an alternate port (like 8080/8443) and move the configuration over bit by bit, testing as you go.

    Good luck!
  • by augustz ( 18082 )
    And the status of PHP is? The idea for the XML/XSLT stylesheets are intriquing, but what would the performance impact be?
  • Following up on my original post: PHP does work with Apache 2, but you wouldn't want to use it for production. Yuch, a few more months to go.
  • I am learning XSLT and I have to say it's so much easier to use perl or php to transform XML pages into HTMl (or anything else for that matter).

    XSL tags and function are so verbose and hard to read compared to using xmltree() in php and then using foreach statements.

    In all honesty exactly what does xslt do better then php?
  • ...yeah, that's about what I figured it would come to. We're running Raven for the SSL services, which I don't really know much about but It Works so i'm Not Fucking With It. Moving to something a bit more conventional like mod_ssl would make a certain amount of sense, but until I can get a handle on how it differs from Raven, I'm leaving things as is.

    As for the instability of the 2.x series, yeah, I know it isn't anything reliable yet, and I'm not planning to move to it yet. But right now we've got...

    Apache/1.3.6 (Unix) mod_perl/1.21 secured_by_Raven/1.4.2-dev

    ...and if it isn't a total headache to upgrade to something approaching 1.3.19 then I might do it at some point. But again, Things Work so I don't wanna Fuck With It.

    Sooner or later though a slow week will come along & I'll probably do it. I was just hoping to hear something about a utility to update configuration files. Guess not. Oh well....

  • Whaddya mean, Apache doesn't run on a tea kettle?

    Slackers. []


    Anyway, as for the extent of the patches, I'm not entirely sure. It was built quite a while before I came to the company, and the modules that are running are all statically built in. Much to my annoyance, dynamic linking was disabled in the built version, meaning that the only way to add things like mod_speling (which would eliminate about 90% of our 404 errors, particularly people looking for INDEX.HTML etc & Apache being too case-sensitive for its own good) is by one way or the other rebuilding the server from scratch. Dammit.

    Otherwise, the most exotic things we're doing seem to be Raven (which you make sound like it isn't very exotic at all) and NetSaint, which I can handle just fine. When time allows it, I'll start migrating things over to a new version I guess....

  • Can anyone provide some rough advice on how it might be best to upgrade from an "old" & moderately customized version of Apache to the 2.x series, or even the recent 1.3.x series?

    I've inherited & since further adapted the installation that has been running at work, and I don't relish the idea of having to merge together the current httpd.conf file & various binaries into those of a newer version. If nothing else, all the various redirects, aliases, raven-ssl settings, etc that we're currently using would, I assume, be trampled by a stock upgrade. Further, I don't want to just maintain the current httpd.conf file on top of an upgraded installation, because it doesn't make any mention of some of the newer features that would become available and that I'd like to take advantage of.

    Are there tools out there to merge in old settings with a new installation? I don't like the idea of mucking around with diff scripts to do this, but to date I haven't been able to think of any better alternatives. Can someone help?

  • by FattMattP ( 86246 ) on Wednesday April 04, 2001 @09:02PM (#314258) Homepage
    The web site says:
    Apache 2.0.16 Beta is now available for alpha testing.
    Shouldn't we be beta testing the beta? :-)
  • Does anyone know what the plan with XML is? I noticed this new release has a `filter' system which you could probably use to support XML/XSLT stylesheets. Has anyone tried this? Does Apache has a `bigger plan'?

  • Ideally PHP would be expanded first, then the appropriate XML transformation applied. PHP's current support for XML is a nice tool, but doesn't help move your site toward XML.

    As for performance, I see no reason why an effecient XSLT engine can't be written. This is exactly what XML is all about--writing content once, and formatting to taste.. on the fly. I believe confirming this is possible is one of the goals of Apache's XML project. What I'm wondering is what kind of progress have they been making, and when will it be imbedded in apache itself?

    After my first post, I hit freshmeat and found an apache xml module. My impression is it's ``not quite there yet'', but it's encouraging.

  • Core Enhancements:

    Unix Threading
    On Unix systems with POSIX threads support, Apache can now run in a hybrid multiprocess, multithreaded mode. This should improve scalability.
    New Build System
    The build system has been rewritten from scratch to be based on autoconf and libtool. This makes Apache's configuration system more similar to that of other packages.
    Multiprotocol Support
    Apache now has some of the infrastructure in place to support serving multiple protocols. mod_echo has been written as an example.
    Better support for non-Unix platforms
    Apache 2.0 is faster and more stable on non-Unix platforms such as BeOS, OS/2, and Windows. With the introduction of platform-specific multi-processing modules (MPMs) and the Apache Portable Runtime (APR), these platforms are now implemented in their native API, avoiding the often buggy and poorly performing POSIX-emulation layers.
    New Apache API
    The API for modules has changed significantly for 2.0. Many of the module-ordering problems from 1.3 should be gone. 2.0 does much of this automatically, and module ordering is now done per-hook to allow more flexibility.
    Also, new calls have been added that provide additional module capabilities without patching the core Apache server.
    IPv6 Support
    On systems where IPv6 is supported by the underlying Apache Portable Runtime library, Apache gets IPv6 listening sockets by default. Additionally, the Listen, NameVirtualHost, and directives support IPv6 numeric address strings (e.g., "Listen [fe80::1]:8080").

    Apache modules may now be written as filters which act on the stream of content as it is delivered to or from the server. This allows, for example, the output of CGI scripts to be parsed for Server Side Include directive by mod_include.

    Module Enhancements:

    Now supports Berkely DB 3.0
    Includes additional support for session caching across processes using shared memory.
    New module in Apache 2.0. This experimental module allows for character set translation or recoding.
    New module in Apache 2.0. This module implements the HTTP Distributed Authoring and Versioning (DAV) specification for posting and maintaining web content.
    New module in Apache 2.0. This module includes the functionality of mod_mmap_static in Apache 1.3, plus adds further caching abilities.

    You're tired of Slashdot ads? Get junkbuster [] now!
  • Thanks, i will give it a whirl.
  • Yeah baby!

    Got it working, thanks for the hint.

    Server Version: Apache/2.0.16 (Unix) mod_perl/1.99_01-dev Perl/v5.6.0

    I had to recompile Perl to use ithreads, but the stuff works trivially.

    From reading the docs, it looks like the architecture changed a lot, but the new design should avoid some of the issues with a "fat" apache/mod_perl memory footprint.

  • Anyone know about the status of mod_perl under Apache 2?

    It's not in the main distribution, and i couldn't find any info on the mod_perl mailing list archives.

    That's what i'd like to try out.
  • Hey, i moved from Raven to mod_ssl last year, when the RSA patent expired. It wasn't hard, since raven is based on mod_ssl.

    It's a lot easier to keep up to date now, mod_ssl gets updated within a day or two of a new apache release.

    If you are building from source, you just have to figure out how you want to build apache, and get those ./configure builds right. Once you got it, it's easy to do it for new releases. For a low to medium traffic site, i do a static apache/mod_perl, and dso the other modules, including mod_ssl.

    As for your httpd.conf file, it should be the same, except for replacing all the ravenssl stuff with mod_ssl. There will be some pain getting it right, but it shouldn't be too hard.

  • I can't wait until my configuration file outsizes the apache executable ;) Seriously though, i will have to give this version a try... Although i really couldn't ask for much more out of 1.3.x
  • Can anyone provide some rough advice on how it might be best to upgrade from an "old" & moderately customized version of Apache to the 2.x series, or even the recent 1.3.x series?

    This depends on the extent of your patches. Some things have changed in the architecture of 2.0, so your patches may not apply or even be necessary. The module API has also changed, so you'll have to re-do your own modules.

    RavenSSL is not available for 2.0 yet. As another poster says, the open source TLS implementation(s) is/are not finished either, so if your site depends on SSL you may want to keep 1.3 around for a while longer.

    Of course, you don't have to move your production server over immediately. Start running 2.0 on your staging box. If you don't have one, get one. Of course this staging box doesn't have to be an identical copy of your web server: it can be a white box linux PC or even your desktop system since Apache runs on anything but the tea kettle. When you are satisfied with a) functionality, b) stability and c) performance, you move the web server over. You can even stage that: run 2.0 on port 8080 initially while you build the system. When you're done, simply flip ports between 1.3 and 2.0.

  • Whaddya mean, Apache doesn't run on a tea kettle?

    Slackers [].

    This is absolutely hilarious. If it actually runs Apache I'm going to have to get one for the office.

    Otherwise, the most exotic things we're doing seem to be Raven (which you make sound like it isn't very exotic at all) and NetSaint, which I can handle just fine.

    Raven is an SSL plugin. I work for the company that makes it [] (but I don't speak for them, #include stddisclaimer.h), so that's probably why it's not very exotic to me. Raven is a closed source module. Otherwise, if you have the source code of your current version, you can do a diff against the present code base to see what the differences are. If you're really in the dark, you should approach the web server like a black box and (re)define a set of functional requirements, collect and integrate the software and keep record of what you have been doing on file. That's a sound business practice anyway: what if your present webserver irrepairably crashes?

    Oh, have you considered making soft links for the most frequently occuring 404's with the misspel(l)ed names? This may be a bit more maintenance intensive but you don't need mod_speling.

A committee is a group that keeps the minutes and loses hours. -- Milton Berle