Slashdot Mirror

gark writes "The Java Lobby has a weblog on Java success stories. Many of the successful applications are servlet based, and several use Apache JServ. Perhaps WORA [write once, run anywhere] really has been achieved, at least for server apps."

According to the December Netcraft survey, Apache can now be found running on over 5 million sites. Overall, Apache's "market share" dropped about a third of a percent, with the biggest change being a 0.77% increase by Zeus mostly due to its use by UUNet.

The Elliptic Curve Discrete Logarithms project has made a generous proposal to the Apache Software Foundation: They are looking for help in solving part of Certicom's ECC Challenge. If they win, they will give donate $8000 of the $10000 prize to the ASF, with the remaining $2000 being divided between the 2 volunteers who find the match (so it's $1000 each). It's a cool challenge, a piece of cake to participate and it helps out your favorite server.

With the success of various IPOs lately, there are a lot of new millionaires in the Open Source community running around. It's heartwarming to those of us with long-standing roots in Open Source and a deep commitment to it to see this "validation," of sorts, towards the ideals that we hold dear. Unfortunately, as postings on Slashdot clearly indicate, it also fosters some resentment. Will Open Source's own success destroy the grass roots effort that forms its foundation?

This isn't some idle speculation. Linux, FreeBSD, Apache, PHP and others depend on the wide and varied developer community in order to grow and develop. People who helped got some 'Net notice, their names in the contributor lists and a warm fuzzy feeling that they were helping the effort. But now people are seeing companies and individuals making staggeringly large amounts of money, and are asking "When am I gonna get mine?" Not that they were/are "in it" for the money alone, but, after all, they think, "others are making major bucks." Some other developers are asking themselves why they should put forth so much of their own time and effort to simply benefit the corporate bottom line of a company that, they feel, has deserted the common Open Source contributor.

Of course, that's not totally true. Usually the company implements a "Directed Shares" program that allows significant Open Source contributors to purchase shares at the pre-IPO price. Still, things have not gone smoothly in these programs, with last minute changes in pricing and implementation causing even those "chosen" members to scramble about. And even if you did get in on the 2 big ones, RedHat and VA Linux, and had the money to buy the maximum amount of shares, and cashed in at the best possible time, you would have made about $150,000 (before taxes). Not exactly chump change, but for people who have put 4 or 5 years of significant effort into Open Source, the payoff may seem a little small.

So what will happen? Well, I'm certain we'll see a weeding out of some developers. Some will leave in search of obtaining some of that money out there. Others will leave because the playing field has changed, and recognition by your peers may no longer have the attraction that it once had, what with gobs of money floating around. Others will "follow the money" and start contributing to Open Source in hopes of "getting in" on the action, maybe even dropping any efforts on such projects where there are no perceived fiscal payoffs: "What, they aren't going public soon? Forget them! I'll work on Foobar."

And there will be some of us who stay because, well, even though the world may have changed, we haven't. All the things that made contributing to Open Source are still valid and vital. And so while we may look a little enviously at the stock market pages, and have to endure people asking "Why are you wasting your time" or "Why aren't you rich yet", we stay the course. Sometimes rewards are more than what you see on a bank statement; it's a warm and pure satisfaction that goes deeper than your wallet.

Romulux writes "Active server pages are pretty bitchen. Can databases be integrated in this way using Linux. " I'm not sure if Romulux's main desire is access to databases or whether it's the capability to use ASP under Linux (and Apache). If the former, of course there's PHP and Perl scripting, with their inherent database connectivity. If it's just ASP then there are at least a few Apache modules that implement this. Anyone know of more?

The latest Netscraft Survey is out. Apache enjoyed an over 1 percent increase, with Microsoft and Netscape showing some decreases. According to the survey, Apache has a 54.81 percent "market share." Also reported is the fact that Webjump actuals uses a hybrid setup with NT serving static content and the dynamic content with a Solaris/Apache/Perl system. Tucked away in the report is a small factoid that PHP is on over 1.1 million domains.

If you use Apache, chances are that you use Analog as your web log file analyser . Well, Analog 4.0 was just released yesterday (11/16). Better performance and more options make this a worthwhile upgrade.

PHP version 4.0b3-RC5 (meaning PHP4, beta3, release-candidate 5) has been announced by the PHP Development Team. PHP is an extremely popular module for Apache and other web servers, as shown by this usage report obtained using Netcraft results. The PHP4 website still only refers to Beta2, though you can grab this Beta3 RC via CVS.
UPDATE: 11/16/99: PHP4.0b3 (the real thing) is released. Available here!

With the posting of it's first Press Release, the new Apache XML Project is officially launched. Also, the website itself is open to the public. The project itself contains 4 sub-projects:

• Xerces - XML parsers in Java, C++, and Perl
• Xalan - XSLT stylesheet processors, in Java and C++
• Cocoon - XML-based web publishing, in Java
• FOP - XSL formatting objects, in Java

We now have some meat to talk about :)

With the posting of it's first Press Release, the new Apache XML Project is officially launched. Also, the website itself is open to the public. The project itself contains 4 sub-projects:

• Xerces - XML parsers in Java, C++, and Perl
• Xalan - XSLT stylesheet processors, in Java and C++
• Cocoon - XML-based web publishing, in Java
• FOP - XSL formatting objects, in Java

We now have some meat to talk about :)

One commonly quoted reason for the resistance of commercial companies towards open source technology, such as Linux or Apache, is the lack of support. Unless there is a mortar-and-brick establishment behind the product, it's said, companies will not use open source.
Of course, this ignores the fact that there are companies out there whose business model is to provide just that kind of support. There's a short article in the Nov 9 issue of Computer Current Magazine that mentions just two.

IBM, Sun and others are helping the Apache Group create Open Source XML ^[?] tools for use with Apache. Some companies including Lotus are giving away their XSL ^[?] technology to the project.

Quite a number of people have been writing to us about Dave Whitinger's column that ran on LinuxToday and was sent over here as well. Dave's contention is the browser compatibility is a crucial battle for the success of Linux - and things don't look so good. Click below to read the column, and contribute your thoughts.

By Dave Whitinger, dave@wmkt.com (Temporary E-Mail account)

Linux is quickly becoming the operating system of the future, thanks in part to the advanced type of development that we refer to as Free Software, or Open Source, as well as the rock-solid features that are present in Linux. It is the ultimate server platform.

Linux is also enjoying success as a desktop workstation. My wife, Trish, makes the perfect example of the typical desktop user.

When we became married in August of 1996, she was a complete computer illiterate, having never even used a Windows or Unix machine. I presented her with a choice:

1. I will give her a Windows computer, but will offer nothing in the way of technical support or training assistance.
2. I will give her a Linux box, and will give her complete technical support and training assistance.

A New Hope

Not knowing the difference anyway, she chose the latter, and found herself extremely happy with a rock-solid desktop.

She enjoys her Red Hat Linux 6.1 workstation. Coupled with the K Desktop Environment and various applications that I have installed for her, she's ready to go. She has her TkRat E-Mail program, Netscape Navigator, notepad text editor, licq, games, the Gimp, and a variety of other nice applications, all accessed via a friendly interface.

Finding friends in mailing lists and on-line web-based chat groups, she was happy as a clam. She would fire up her Netscape Navigator and hit any web site she wanted, and was constantly bragging to her friends about this great computer operating system that she had the privilege of using.

The Empire Strikes Back

...Until the day that Netscape Navigator, her web browser, her window to the outside world, the major purpose for using the computer, simply disappeared from her desktop while she was browsing.

Trish turned to me, confusion spread across her face, and opined, "Dave, my Netscape has simply vanished from my screen. Perhaps you have telneted in and did a kill -9 on it?"

Dave responds, "Absolutely not! Why would I do that? Let's examine the problem more closely, that the answer to this perplexing issue will reveal itself."

Upon further investigation, it turns out that Netscape apparantly did not "like" the Java code that was being incorporated into one of the websites that Trish frequents. My solution: Turn off Java.

A very important and critical issue is realized here. At this point, Trish's computer is not as powerful as all of her friends' Windows computers. If they can access certain Java-enabled pages that she cannot, she is being left out, all because she chose to use Linux.

Fade to 2 or 3 weeks later.

Trish: "Dave, this website is telling me that I cannot use their services."

Dave: "What's the URL?"

Examining the website, it turns out that it is using some special kind of plugin that is only available for Windows or Macintosh platforms. I explained to Trish that she simply will not be able to access the services on this website, until they decide to make this plugin available for Linux. A short and polite note to the webmaster later, there was nothing we could do, and the issue was closed, and Trish's computer became even less valuable to her.

Fade to 2 or 3 more weeks later.

Trish: "Dave, this website is telling me that I am using an unsupported web browser, and cannot view the pages within."

Dave: "Okay, this is starting to make me angry. The web was initially created as a completely open environment where multimedia can be viewed, regardless of your platform. It's a platform independant medium, yet here are people making platform dependant websites."

Trish: "That's great that you feel that way, but I just want to access this coupon website! All my friends say they are getting great deals, and I'm missing out! Oh, and now my netscape just froze again! Argh, (killall -9 netscape ; rm ~/.netscape/lock) again. I want a Windows computer like all my friends have."

I hung my head in shame, realizing that if she is going to be able to take full advantage of the web, she will need a Windows computer. Trish, who has used nothing but Linux for over 3 years, and is completely happy with her computer, now feels the need to switch to Windows so that she can get the same web-browsing features as her friends.

Does this sound like a big deal to you, gentle reader? If it does, than I have accomplished my mission. If it does not, read on:

In 1994, I hated Netscape Communications, Inc. The way they were embracing and extending the HTML standards was starting to become very disturbing for me. The more websites that I found that said that it uses Netscape Extensions, the more angry I became.

Then Netscape released Navigator for Linux, and everybody loved them again. They were our saviour, completing the picture of a perfect desktop for Linux users. We were all Linux users, browsing any site we wished, enjoying the satisfaction of having a great web browser for our desktop.

Then Microsoft created Internet Explorer. Then Microsoft won the "Browser War". Then webmasters began using some of the "advanced" features of Internet Explorer, shutting out Netscape users.

Problem yet? Still not convinced? Okay, let's fast forward 1 year:

Microsoft owns 99% of the web browser market share, and they control the HTTP protocol. They start adding a huge variety of features to their "Internet Information Server", their competitor to Apache, to offer advanced features to Internet Explorer clients. At this point, sites being served by Apache become useless. Then Linux becomes obsolete as a web server platform. Then Microsoft wins the war, and we're right back to square one, and proprietary technology wins again.

Return of the Jedi

On April 1st, 1998, Netscape Communications, Inc. made one final redeeming move. They released the source code to Netscape Navigator, freeing it to the Free Software community to do with as they chose.

1 and a half years later, this browser is still nowhere near completion. There is a band of rebels working feverishly on the code, trying to bring it to a usable state as quickly as possible. Plagued with problems and set-backs, Mozilla continues forward, currently at "Milestone 10". Will we see a completely usable web browser for Linux in time to save us from seeing a new monopoly for Microsoft be created?

Attention: This is the battle that could cost us the war. If we come together and push all of our might toward a Free Web Browser for Linux, we have a good chance of winning this battle. If we fail, we will lose the war. This is the issue that Microsoft wants us to overlook.

I am making a personal committment to get involved with the Mozilla project. It is the project with the most potential to become this Free Web Browser that we so desperately need. Netscape is NOT going to save us this time. Netscape has failed us, and it's time to take matters into our own hands.

If we fail, we will lose the war.

Add that to your .signature:

If we fail, we will lose the war.

And repeat it every morning to yourself:

If we fail, we will lose the war.

When you are looking over Mozilla, finding items that could use your contribution, remember:

If we fail, we will lose the war.

The truth of the matter, friends and esteemed members of the community:

If we fail, we will lose the war.

The latest Netcraft Survey is out, covering through October 1999. Apache continues to lead the pack, but Microsoft's IIS showed a significant increase due to, basically, the influence of one web hosting company, Webjump.
Is the Netcraft survey still relevant? A cursory glance might lead some to believe that Apache decreased in the number of sites hosted, which is definitely not the case. Are there maybe better ways to display the numbers to give a more complete picture?

There's an interesting (but somewhat old) article by Network Computing which supposedly helps webmaster's pick their "best bet" for web development systems. They compare Netscape's Enterprise Server, Microsoft's IIS and the ASF's Apache. Despite Apache and PHP being their "clear favorite" they somehow give the Editor's Choice to Netscape. Confusing, but still a pretty good read.

There's an interesting (but somewhat old) article by Network Computing which supposedly helps webmaster's pick their "best bet" for web development systems. They compare Netscape's Enterprise Server, Microsoft's IIS and the ASF's Apache. Despite Apache and PHP being their "clear favorite" they somehow give the Editor's Choice to Netscape. Confusing, but still a pretty good read.

jimz writes "Tomcat, the JSP and Servlet engine, after about a year of waiting, was just released by Sun and given to the Apache group. You can get more info at Apache's Jakarta page. " FYI: "Tomcat, is a world-class implementation of the Java Servlet 2.2 and JavaServer Pages 1.1 Specifications," for those not in know. The download page is online as well - release will be up there muy pronto.

jimz writes "Tomcat, the JSP and Servlet engine, after about a year of waiting, was just released by Sun and given to the Apache group. You can get more info at Apache's Jakarta page. " FYI: "Tomcat, is a world-class implementation of the Java Servlet 2.2 and JavaServer Pages 1.1 Specifications," for those not in know. The download page is online as well - release will be up there muy pronto.

It's nice that "the media" and the outside world in general have finally noticed Open Source. Trouble is, unless you mention Linux, their eyes glaze over like yesterday's halibut. Open Source has a lot of successes, especially Apache . So how come you never see that rainbow feather on the news? Read on.

Sometimes it seems that we're all living in some Bizzaro web world.

Apache runs on over half the sites on the entire web. It's beating the pants off Microsoft's "offering," IIS, as well as other such solutions from such Web "pioneers" as Netscape. One would expect that when the Web and Open Source were discussed in the media, Apache would be a constantly featured player. But other than some noteworthy exceptions, Apache is rarely if ever mentioned.

Today's media darling, when it comes to Open Source technology, or even anything web, is Linux. Why has the popular media (and even some geek media, which should know better) focused so extensively on Linux, at the expense of other powerful and noteworthy successes? If you are one of the more paranoid among us, the answer is clear. With one target, it's easy to get your aim right. After all, if you take down Linux, then by default you take down all the other Open Source players, and Microsoft comes out smelling like a rose. Surely this is all a ploy to ensure total world domination by Microsoft!

Well, I wouldn't go that far, but I do tend to think that the media likes playing up the David vs. Goliath angle of "Linux vs. Microsoft." It needs a single player on the Open Source side, to even out that 800lb gorilla called Microsoft. There's this simple fascination that someone, somewhere could "beat" Microsoft. Imagine that!

With that in mind, I'd like to tune the media into a little secret. Shhhhh. Come closer, so I can whisper it into your ear.

"IT'S ALREADY HAPPENING BABY! IT'S CALLED APACHE "

If people are so concerned or curious whether Open Source can be a success and "beat" Microsoft (or any commercial and/or proprietary company) in this "web thing," then Apache is proof positive that the answer is yes. Apache never started out to "beat" Microsoft, nor is that one of it's goals. It presents itself only as an accurate, reliable and decently fast web server. And for the vast majority of those looking for web servers, what's important is that Apache delivers what it promises. Maybe that is another key feature of Apache's success: that it doesn't promote itself as ABM (Anything But Microsoft). It's content with letting it's performance and track record speak for it. Trouble is, in today's world, you gotta shout.

Certainly, the "battle over the desktop" sounds sexier than "the battle over the web servers," and Microsoft is known more for Windows and NT rather than IIS. So it makes sense that an alternative that goes toe-to-toe with Microsoft in a specific arena that they have controlled for so long, will become such a well known entity. But it is up to all of us to make sure that the message about Open Source is more than just Linux. There are other players that deserve their time in the spotlight, not only for their continued health and survival but also because it presents a more accurate and well-rounded view of what Open Source really is. Open Source is a rich and varied rainbow of projects, each one clearly showing that Open Source is viable, that it can succeed, that it does succeed. Allowing the media to portray one project as the focus of the entire movement does a disservice to the countless other projects and their developers. Open Source can not and should not live or die by what happens to Linux.

Apache makes our case stronger, and in doing so, helps out the entire Open Source movement. So does Perl. So does PHP. So does FreeBSD. Let's make sure the world gets the whole picture. We will all, even Linux, be the better for it.

Thanks to darrn chamberlain for an excellent review of the Lincoln Stein and Doug MacEachern book Writing Apache Modules with Perl and C. This is an excellent book for those considering working with Apache and mod_perl, and helpful for C programmers. Click below for more details. Writing Apache Modules with Perl and C author Li pages 724 publisher O'Reilly, ISBN: 156592567X rating 9.5/10 reviewer darren chamberlain ISBN summary Absolutely essential for anyone who is considering using Apache and mod_perl. C programmers may need more. The Scenario

If you're like me, your first introduction to Perl ^[?] was in the form of CGI ^[?] scripts. A few years ago, I inherited a few dozen ancient CGI scripts (Perl and otherwise) that required Immediate Attention. CGI led to Perl, and to Apache ^[?] ; Perl and Apache led, naturally enough, to mod_perl ^[?] , once I started hitting the performance bottlenecks inherenent in CGI programming. After researching mod_perl, building a mod_perl-enalbed Apache, and reading all the available online documentation, I got it up and running--and I was suitably impressed.

So, when O'Reilly ^[?] announced a book devoted to programming Apache with Perl, I was extremely excited. The book starts with an introduction and history of web programming, introduces CGI and other types of web programming (server API ^[?] 's, such as ISAPI and NSAPI; embedded processors, such as mod_perl, mod_dtcl, and mod_pyapache; FastCGI; Java ^[?] servlets ^[?] ; ActiveX ^[?] ; and client-side scripting languages, such as VBScript ^[?] and JavaScript ^[?] ), and then describes the Apache module architecture, using some simple examples ("Hello, World" in Perl and in C). Then it gets good, covering dynamically generated content; the hobgoblin of HTTP, state; and all the other stuff that gives CGI programmer nightmares (like authentication and authorization).

What's Bad?

Although the title reads '... with Perl and C', the emphasis is very obviously on Perl. The C API reference chapters (chapters 10 and 11, pages 505 through 631) are very thorough, but almost all the examples are in Perl only. In fact, the authors go so far as to recommend that almost all Apache modules be written in Perl, and not C, except for very small modules or modules that need that extra speed boost or small memory footprint of being compiled into the server (page 13: "Anything you can do with the C API you can do with mod_perl with less fuss and bother."). Their reasoning is sound: mod_perl modules and scripts require a server restart at most, and often not even that, while for C modules, Apache itself must be recompiled; but I was expecting more in this area, perhaps a larger section on using DSO. After the book was published, however, several of the Perl-only examples were ported to the C API, and are available for download.

A few of these examples have already been published, and in these cases the book is mostly redundant. Notably, the Apache::NavBar module (which Lincoln uses on the server in his lab) and the Apache::AdBlocker module (chapters 4 and 7), appeared in The Perl Journal last year (issues 12 and 11). This is not that big a deal, since both of these modules are incredibly useful and probably deserve to be published in a few more places, but two brand new modules would have been most welcome, especially since the book's target audience probably also reads The Perl Journal.

What's Good?

There's a lot to like here. Since I'm a Perl programmer by trade and disposition, I personally liked the fact that 99.9% of the examples were written in Perl. With only a few exceptions, the modules could be copied into the right locations and run immediately; the exceptions were the modules that made use of either other programs (Chapter 5's Hangman program which uses a relational database to store state information) or specialized Apache features (Chapter 7's Apache::AdBlocker module, which requires proxy functionality).

Much of the text and all of the source code is available on the web at www.modperl.com. Chapters 6, 7, 8, and 9 can be found on the web site for the book, as can all the Perl modules and some of the examples in functional form (Apache::Magic and hangman).

Chapter 9 is the key chapter, and the heart of the book. It describes in great detail all the Apache:: modules. If you use mod_perl at all, download and print this chapter. Memorize it. Use your favorite indexing script to make it searchable. Everything you need to know about mod_perl is here in this chapter.

The appendices are also excellent, although, because it is an Apache book, I would have figured that several of the sections would be regular chapters, and not relegated to the end. The appendices are divided pretty evenly between concentrating on Perl and on C, unlike most of the rest of the book.

So What's In It For Me?

Fortunately for people like me, there is a lot of information about mod_perl on the web; The Perl Journal has had several articles on it, WebMonkey has had an article or two, and so on. There is a comprehensive mod_perl developer's guide on the offical Apache/Perl site. Lincoln Stein uses it a lot on his site and in his software. And, of course, we have the man pages and perldocs. So why do we need a book?

A few reasons. First and foremost, few of those sources go into the kind of detail that this book does, while still being approachable. Second, the book focuses on Apache, programming Apache, and (to a lesser extent) programming applications on the web; Perl and C are the means here, not the end. The in-depth technical discussions are about Apache: how it translates URI's to filenames, how it handles subrequests and internal redirects, how it maps files to MIME types. It then presents techniques for usurping these functions, customizing each phase of the reponse process, and explains when and why you would want to do this, instead of letting Apache do it's own thing. Creating checksums on the fly, compressing and decompressing data, creating extremely flexible HTML preprocessors, and modifying outgoing and incoming headers are some just some of the given examples.

The reference chapters are probably the single most valuable thing about the book. If you are a Perl programmer on a budget, you can download chapter 9 from the web site, but the C programmers out there have to buy the book to get the C API refernce. The C reference is 2 chapters (126 pages) long, and covers all the functions in precise detail.

For those among you who are using Microsoft operating systems, the book pays special attention to building, installing, and configuring mod_perl and Apache on Win32 systems, where it is different from Unix and Unix-like systems. Most of the actual modules are very similar (except for the obvious ones, such as scripts that call sendmail and the scripts that access MySQL), but the installation and building of mod_perl (or ApacheModulePerl.dll) are very different. The process is described in enough detail to make it possible, without boring those readers to whom it is irrelevant.

Conclusion

Programming Apache/mod_perl without this book is like writing Perl without the camel book. It can be done, but it is much easier and more enjoyable with the book. The writing is clear, informative, straight-forward, and, at times, amusing. The authors are the definitive sources for information on mod_perl and CGI programming, and this is reflected in every aspect of the book. While not as definitive for C programmers, it is still the best Apache API reference out there, other than the actual source code itself.

Purchase this book at Amazon.

Errata Table of Contents

1. Server-Side Programming with Apache
2. A First Module
3. The Apache Module Architecture and API
4. Content Handlers
5. Maintaining State
6. Authentication and Authorization
7. Other Request Phases
8. Customizing the Apache Configuration Process
9. Perl API Reference Guide
10. C API Reference Guide, Part I
11. API Reference Guide, Part II

1. Standard Noncore Modules
2. Building and Installing mod_perl
3. Building Multifile C API Modules
4. Apache:: Modules Available on CPAN
5. Third-Party C Modules
6. HTML::Embperl--Embedding Perl Code in HTML

Thanks to darrn chamberlain for an excellent review of the Lincoln Stein and Doug MacEachern book Writing Apache Modules with Perl and C. This is an excellent book for those considering working with Apache and mod_perl, and helpful for C programmers. Click below for more details. Writing Apache Modules with Perl and C author Li pages 724 publisher O'Reilly, ISBN: 156592567X rating 9.5/10 reviewer darren chamberlain ISBN summary Absolutely essential for anyone who is considering using Apache and mod_perl. C programmers may need more. The Scenario

If you're like me, your first introduction to Perl ^[?] was in the form of CGI ^[?] scripts. A few years ago, I inherited a few dozen ancient CGI scripts (Perl and otherwise) that required Immediate Attention. CGI led to Perl, and to Apache ^[?] ; Perl and Apache led, naturally enough, to mod_perl ^[?] , once I started hitting the performance bottlenecks inherenent in CGI programming. After researching mod_perl, building a mod_perl-enalbed Apache, and reading all the available online documentation, I got it up and running--and I was suitably impressed.

So, when O'Reilly ^[?] announced a book devoted to programming Apache with Perl, I was extremely excited. The book starts with an introduction and history of web programming, introduces CGI and other types of web programming (server API ^[?] 's, such as ISAPI and NSAPI; embedded processors, such as mod_perl, mod_dtcl, and mod_pyapache; FastCGI; Java ^[?] servlets ^[?] ; ActiveX ^[?] ; and client-side scripting languages, such as VBScript ^[?] and JavaScript ^[?] ), and then describes the Apache module architecture, using some simple examples ("Hello, World" in Perl and in C). Then it gets good, covering dynamically generated content; the hobgoblin of HTTP, state; and all the other stuff that gives CGI programmer nightmares (like authentication and authorization).

What's Bad?

Although the title reads '... with Perl and C', the emphasis is very obviously on Perl. The C API reference chapters (chapters 10 and 11, pages 505 through 631) are very thorough, but almost all the examples are in Perl only. In fact, the authors go so far as to recommend that almost all Apache modules be written in Perl, and not C, except for very small modules or modules that need that extra speed boost or small memory footprint of being compiled into the server (page 13: "Anything you can do with the C API you can do with mod_perl with less fuss and bother."). Their reasoning is sound: mod_perl modules and scripts require a server restart at most, and often not even that, while for C modules, Apache itself must be recompiled; but I was expecting more in this area, perhaps a larger section on using DSO. After the book was published, however, several of the Perl-only examples were ported to the C API, and are available for download.

A few of these examples have already been published, and in these cases the book is mostly redundant. Notably, the Apache::NavBar module (which Lincoln uses on the server in his lab) and the Apache::AdBlocker module (chapters 4 and 7), appeared in The Perl Journal last year (issues 12 and 11). This is not that big a deal, since both of these modules are incredibly useful and probably deserve to be published in a few more places, but two brand new modules would have been most welcome, especially since the book's target audience probably also reads The Perl Journal.

What's Good?

There's a lot to like here. Since I'm a Perl programmer by trade and disposition, I personally liked the fact that 99.9% of the examples were written in Perl. With only a few exceptions, the modules could be copied into the right locations and run immediately; the exceptions were the modules that made use of either other programs (Chapter 5's Hangman program which uses a relational database to store state information) or specialized Apache features (Chapter 7's Apache::AdBlocker module, which requires proxy functionality).

Much of the text and all of the source code is available on the web at www.modperl.com. Chapters 6, 7, 8, and 9 can be found on the web site for the book, as can all the Perl modules and some of the examples in functional form (Apache::Magic and hangman).

Chapter 9 is the key chapter, and the heart of the book. It describes in great detail all the Apache:: modules. If you use mod_perl at all, download and print this chapter. Memorize it. Use your favorite indexing script to make it searchable. Everything you need to know about mod_perl is here in this chapter.

The appendices are also excellent, although, because it is an Apache book, I would have figured that several of the sections would be regular chapters, and not relegated to the end. The appendices are divided pretty evenly between concentrating on Perl and on C, unlike most of the rest of the book.

So What's In It For Me?

Fortunately for people like me, there is a lot of information about mod_perl on the web; The Perl Journal has had several articles on it, WebMonkey has had an article or two, and so on. There is a comprehensive mod_perl developer's guide on the offical Apache/Perl site. Lincoln Stein uses it a lot on his site and in his software. And, of course, we have the man pages and perldocs. So why do we need a book?

A few reasons. First and foremost, few of those sources go into the kind of detail that this book does, while still being approachable. Second, the book focuses on Apache, programming Apache, and (to a lesser extent) programming applications on the web; Perl and C are the means here, not the end. The in-depth technical discussions are about Apache: how it translates URI's to filenames, how it handles subrequests and internal redirects, how it maps files to MIME types. It then presents techniques for usurping these functions, customizing each phase of the reponse process, and explains when and why you would want to do this, instead of letting Apache do it's own thing. Creating checksums on the fly, compressing and decompressing data, creating extremely flexible HTML preprocessors, and modifying outgoing and incoming headers are some just some of the given examples.

The reference chapters are probably the single most valuable thing about the book. If you are a Perl programmer on a budget, you can download chapter 9 from the web site, but the C programmers out there have to buy the book to get the C API refernce. The C reference is 2 chapters (126 pages) long, and covers all the functions in precise detail.

For those among you who are using Microsoft operating systems, the book pays special attention to building, installing, and configuring mod_perl and Apache on Win32 systems, where it is different from Unix and Unix-like systems. Most of the actual modules are very similar (except for the obvious ones, such as scripts that call sendmail and the scripts that access MySQL), but the installation and building of mod_perl (or ApacheModulePerl.dll) are very different. The process is described in enough detail to make it possible, without boring those readers to whom it is irrelevant.

Conclusion

Programming Apache/mod_perl without this book is like writing Perl without the camel book. It can be done, but it is much easier and more enjoyable with the book. The writing is clear, informative, straight-forward, and, at times, amusing. The authors are the definitive sources for information on mod_perl and CGI programming, and this is reflected in every aspect of the book. While not as definitive for C programmers, it is still the best Apache API reference out there, other than the actual source code itself.

Purchase this book at Amazon.

Errata Table of Contents

1. Server-Side Programming with Apache
2. A First Module
3. The Apache Module Architecture and API
4. Content Handlers
5. Maintaining State
6. Authentication and Authorization
7. Other Request Phases
8. Customizing the Apache Configuration Process
9. Perl API Reference Guide
10. C API Reference Guide, Part I
11. API Reference Guide, Part II

1. Standard Noncore Modules
2. Building and Installing mod_perl
3. Building Multifile C API Modules
4. Apache:: Modules Available on CPAN
5. Third-Party C Modules
6. HTML::Embperl--Embedding Perl Code in HTML

An Anonymous Coward wrote in to tell us that Apache 1.3.9 has made an appearance on the ftp sites. The webiste doesn't note this, but the ftp directory has a change log and list of new bits in this bug fix release.

An Anonymous Coward wrote in to tell us that Apache 1.3.9 has made an appearance on the ftp sites. The webiste doesn't note this, but the ftp directory has a change log and list of new bits in this bug fix release.

Progman writes "The Apache Group today announced the creation of the Apache Software Foundation (ASF), read their press release. " It seems as though Apache is formally incorporated now, and the ASF will be a legal umbrella for Apache and other projects. Congrats to Brian and all the others!

Bryan Andersen asks: "I'm looking for information on securing web servers against hacking. In particular, I'm interested in securing Apache on Debian Linux and OpenBSD, but discussion on other server/OS combinations are welcome. Links to sites with good information would be greatly appreciated."

Lot's of people submitted each of these, but the quick summary is that there are new GNOME 0.99.2 RPMs available at the usual places. Not enough for ya? How about a new Apache? 1.3.4 is now out. And if that isn't enough stuff to keep you busy, the Linux 2.2pre7 Kernel has also been released.

Sander van Zoest writes "Yes thats right. the latest and greatest Apache 1.3.3 is out get it from your favorite mirror site see the latest issue of Apacheweek for more information about the changes. "

Since Fresh Meat seems to be less then cheerful, I thought I'd just throw out that Apache has released v1.3.2 of their super popular web server, and WindowMaker (which is the windowmanager still known as WindowMaker) now has the 0.20 beta up for download.

Chris WintersC.net wrote in to tell us that Apache 1.3.0 has apparently made its appearance on Apache's distribution area. Assuming no craziness has occured, it's the latest release stable release of the world's most popular web server. I gotta download this bad boy and upgrade Slashdot now *grin*.

Mike Hicks wrote in with an interesting note: The Committee for the Moral Defense of Microsoft, a pro-microsoft site has been running for awhile now to provide the other side to TMS. It's a fair site. Wrong in several key ways, but this is an excellent way to use the internet to its fullest potential, by posting other ideas. The funny part is that the machine the site runs on, like most of the net, runs Apache. Normally I don't find this kinda stuff all that interesting, but for some reason, this one struck me as cool. Telnet into port 80, and type HEAD / HTTP/1.0

David Ulevitch wrote in to tell us that Network Magazine has awarded Apache a Product of the Year and says " Network Magazine has choosen Apache 1.2.4 to be named web server of the year. Due to the fact that it now runs on WindowsNT, OS/2 and of UNIX!" It's great to see such an awesome package go cross platform and get this kind of acclaim. And Apache will continue to win converts to Open Source. Good stuff,

Netcraft's April Survey shows Apache is still moving up. It grew 1.06% in market share and now tops a million installations on the net (including 3 of mine). MS went up .12% and Netscape dropping .16% this month as well. Thanks to Mike Prettejohn for sending this to us.

Netcraft is running the latest version of their web server reports. Up on top again is Apache web server of champions (and slashdot for that matter). Over 100,000 new apache servers this month. Also the IIS market share seems to have dropped.

Wesley Lemke wrote in to let us know that Internet News has another article reporting that Apache is still the number one web server on the net, with over 50% of the net using their code to serve up their pages. Both NS and MS both claim to be the leader, but the let the truth be told.