Show Contents Previous Page Next Page Preface In this section...
In This Preface
One of the minor miracles of the World Wide Web is that it makes client/server network programming easy. With the Common Gateway Interface (CGI) anyone can become a network programmer, creating dynamic web pages, frontends for databases, and even complex intranet applications with ease. If you're like many web programmers, you started out by writing CGI scripts in Perl. With its powerful text-processing facilities, forgiving syntax, and tool-oriented design, Perl lends itself to the small programs that CGI was designed for. Unfortunately the Perl/CGI love affair doesn't last forever. As your scripts get larger and your server more heavily loaded, you inevitably run into the performance wall. A 1,000-line Perl CGI script that runs fine on a lightly loaded web site becomes unacceptably slow when it increases to 10,000 lines and the hit rate triples. You may have tried switching to a different programming language and been disappointed. Because the main bottleneck in the CGI protocol is the need to relaunch the script every time it's requested, even compiled C won't give you the performance boost you expect. If your application needs go beyond simple dynamic pages, you may have run into the limitations of the CGI protocol itself. Many interesting things go on in the heart of a web server--things like the smart remapping of URLs, access control and authentication, or the assignment of MIME types to different documents. The CGI protocol doesn't give you access to these internals. You can neither find out what's going on nor intervene in any meaningful way. To go beyond simple CGI scripting, you must use an alternative protocol that doesn't rely on launching and relaunching an external program each time a script runs. Alternatives include NSAPI on Netscape servers, ISAPI on Windows servers, Java servlets, server-side includes, Active Server Pages (ASP), FastCGI, Dynamic HTML, ActiveX, JavaScript, and Java applets. Sadly, choosing among these technologies is a no-win situation. Some choices lock you into a server platform for life. Others limit the browsers you can support. Many offer proprietary solutions that aren't available in other vendors' products. Nearly all of them require you to throw out your existing investment in Perl CGI scripts and reimplement everything from scratch.
The Apache server offers you a way out of this trap. It is a freely distributed, full-featured web server that runs on Unix and Windows NT systems. Derived from the popular NCSA
The best thing about Apache modules, however, is the existence of
Move your existing Perl scripts over to This book will show you how to write Apache modules. Because you can get so much done with Perl modules, the focus of the book is on the Apache API through the eyes of the Perl programmer. We cover techniques for creating dynamic HTML documents, interfacing to databases, maintaining state across multiple user sessions, implementing access control and authentication schemes, supporting advanced HTTP methods such as server publish, and implementing custom logging systems. If you are a C programmer, don't despair. Two chapters on writing C-language modules point out the differences between the Perl and C APIs and lead you through the process of writing, compiling, and installing C-language modules. This book includes complete reference guides to both the Perl and C APIs and multiple appendixes covering the more esoteric aspects of writing Apache modules. We think you'll find developing Apache modules to be an eye-opening experience. With any luck, you won't have to worry about switching web application development environments for a long time to come. What You Need to Know to Get the Most out of This Book Show Contents Go to Top Previous Page Next PageThis book was designed for application developers who already have some experience with web programming. We assume that you understand CGI scripting, know how to produce HTML pages dynamically, and can create fill-out forms and process their contents. We also assume that you know the basics of web server administration--if not with the Apache server itself, then with another Unix or Microsoft Windows-based web server. A knowledge of the Perl programming language is definitely required! We use the Perl version of the Apache API to illustrate the central concepts of module design and implementation, and most of our example code is written in Perl as well. We chose to do it this way because we think there are more people who are comfortable developing web applications in Perl than in C or C++. You don't have to be a Perl guru to read this book, but there will be places where you'll find the going tough if you don't understand Perl syntax. We make particularly heavy use of the current features of Perl (Version 5.004 and higher), particularly in regard to Perl's object-oriented syntax. If you know Perl Version 4 but haven't gotten around to reading about the Version 5 features, now's the time to start learning about hash references, blessed objects, and method calls. If you're an experienced C programmer, you can probably get what you need from the Perl chapters without necessarily understanding every line of the example code. Be forewarned, however, that our discussion of the C-language API tends toward terseness since it builds on the framework established by earlier chapters on the Perl API.
Apache and We've used the following books for background reading and reference information. We hope they will be useful to you as well:
Copyright © 1999 by O'Reilly & Associates, Inc. |
