- Paperback: 750 pages
- Publisher: O'Reilly Media; 1 edition (11 April 1999)
- Language: English
- ISBN-10: 156592567X
- ISBN-13: 978-1565925670
- Product Dimensions: 17.8 x 3.1 x 23.3 cm
- Average Customer Review: 4.7 out of 5 stars See all reviews (3 customer reviews)
- Amazon Bestsellers Rank: 864,417 in Books (See Top 100 in Books)
- See Complete Table of Contents
Writing Apache Modules with Perl and C: The Apache API and mod_perl: Customizing Your Web Server Paperback – 11 Apr 1999
- Choose from over 13,000 locations across the UK
- Prime members get unlimited deliveries at no additional cost
- Find your preferred location and add it to your address book
- Dispatch to this address when you check out
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
About the Author
Doug MacEachern has been addicted to Perl and web servers since early 1994 when he was introduced to Plexus as a student employee at the University of Arizona. Soon after returning to his home town of Boston, Massachusetts, and entering the "real world," he discovered the Apache web server, and since early 1996, he has been gluing Perl into all its nooks and crannies. His day job has consisted of integrating various other technologies with the Web, including DCE, Kerberos, and GSSAPI, but Perl has been the only one he cannot let go of. Doug has continued as a developer disguised as a consultant since the start of 1998, spending most of his time between Auckland, New Zealand, and San Francisco, California, with time at home in Boston during the warmer months. Doug likes to spend his time away from software--far, far away, sailing on the ocean, diving below it, or simply looking at it from a warm, sandy beach where technology doesn't go much beyond thatched huts and blenders.
Lincoln Stein is an assistant investigator at Cold Spring Harbor Laboratory, where he develops databases and user interfaces for the Human Genome Project using the Apache server and its module API. He is the author of several books about programming for the Web, including The Official Guide to CGI.pm, How to Set Up and Maintain a Web Site, and Web Security: A Step-by-Step Reference Guide.
Excerpt. © Reprinted by permission. All rights reserved.
Chapter 4 - Content Handlers
In this chapter:
Content Handlers as File Processors
Chaining Content Handlers
This chapter is about writing content handlers for the Apache response phase, when the contents of the page are actually produced. In this chapter you'll learn how to produce dynamic pages from thin air, how to modify real documents on the fly to produce effects like server-side includes, and how Apache interacts with the MIME-typing system to select which handler to invoke.
Starting with this chapter we shift to using the Apache Perl API exclusively for code examples and function prototypes. The Perl API covers the majority of what C programmers need to use the C-language API. What's missing are various memory management functions that are essential to C programmers but irrelevant in Perl. If you are a C programmer, just have patience and the missing pieces will be filled in eventually. In the meantime, follow along with the Perl examples and enjoy yourself. Maybe you'll even become a convert.
Content Handlers as File Processors
Early web servers were designed as engines for transmitting physical files from the host machine to the browser. Even though Apache does much more, the file-oriented legacy still remains. Files can be sent to the browser unmodified or passed through content handlers to transform them in various ways before sending them on to the browser. Even though many of the documents that you produce with modules have no corresponding physical files, some parts of Apache still behave as if they did.
When Apache receives a request, the URI is passed through any URI translation handlers that may be installed (see Chapter 7, Other Request Phases, for information on how to roll your own), transforming it into a file path. The mod_alias translation handler (compiled in by default) will first process any Alias, ScriptAlias, Redirect, or other mod_alias directives. If none applies, the http_core default translator will simply prepend the DocumentRoot directory to the beginning of the URI.
Next, Apache attempts to divide the file path into two parts: a "filename" part which usually (but not always) corresponds to a physical file on the host's filesystem, and an "additional path information" part corresponding to additional stuff that follows the filename. Apache divides the path using a very simple-minded algorithm. It steps through the path components from left to right until it finds something that doesn't correspond to a directory on the host machine. The part of the path up to and including this component becomes the filename, and everything that's left over becomes the additional path information.
Consider a site with a document root of /home/www that has just received a request for URI /abc/def/ghi. The way Apache splits the file path into filename and path information parts depends on what directories it finds in the document root:
Note that the presence of any actual files in the path is irrelevant to this process. The division between the filename and the path information depends only on what directories are present.
Once Apache has decided where the file is in the path, it determines what MIME type it might be. This is again one of the places where you can intervene to alter the process with a custom type handler. The default type handler (mod_mime) just compares the filename's extension to a table of MIME types. If there's a match, this becomes the MIME type. If no match is found, then the MIME type is undefined. Again, note that this mapping from filename to MIME type occurs even when there's no actual file there.
There are two special cases. If the last component of the filename happens to be a physical directory, then Apache internally assigns it a "magic" MIME type, defined by the DIR_MAGIC_TYPE constant as httpd/unix-directory. This is used by the directory module to generate automatic directory listings. The second special case occurs when you have the optional mod_mime_magic module installed and the file actually exists. In this case Apache will peek at the first few bytes of the file's contents to determine what type of file it might be. Chapter 7 shows you how to write your own MIME type checker handlers to implement more sophisticated MIME type determination schemes.
After Apache has determined the name and type of the file referenced by the URI, it decides what to do about it. One way is to use information hard-wired into the module's static data structures. The module's handler_rec table, which we describe in detail in Chapter 10, C API Reference Guide, Part I, declares the module's willingness to handle one or more magic MIME types and associates a content handler with each one. For example, the mod_cgi module associates MIME type application/x-httpd-cgi with its cgi_handler( ) handler subroutine. When Apache detects that a filename is of type application/x-httpd-cgi it invokes cgi_handler( ) and passes it information about the file. A module can also declare its desire to handle an ordinary MIME type, such as video/quicktime, or even a wildcard type, such as video/*. In this case, all requests for URIs with matching MIME types will be passed through the module's content handler unless some other module registers a more specific type.
Top Customer Reviews
Most Helpful Customer Reviews on Amazon.com (beta)
Although this book is old, it has some useful reference material that can still be applied today.
It doesn't mention as much about C as it does PERL, but it does cover the basic fundamental principles of using either language to create your own apache modules, which was more of what I was interested in.
It reduces days of surfing PODS (perl docs), man-pages (unix docs), and online Apache online references into a nice little kitty. But it¹s not a simple typographical candying/laser-printing of your online docs--the author gives thorough treatment to important GOALS one would want to achieve with the Apache and Apache+Perl facilities--the facilities are elegant, but the sample code and explanations are definitely clear too.
Even the reference section (Chapter 9-11) to Apache library are infested with snippets that improve code comprehension. I felt comfortable tackling the logic of third party Apache modules (in c) and Perl+Apache modules (in perl) after my first run through the book.
The authors made sure you¹ll feel equally comfortable in c when tackling the Apache API, I¹m really happy about this, because some sites require programming in c to maximize server availability when the number of concurrent clients are too high for normal perl or java solutions, and other situations. Since the authors worked with the core server as well as Apache API closely in the effort to bring Perl and Apache together, I can see their enthusiasm in their explanation of c side of the API--which is what they use when improving the GNU mod_perl project--this helps to make this reference far far from being another dry treatment of a programming interface.
While advanced CGI writers can learn all they need about Apache modules, I found it really soft and patient with newbies too. Newbies will find reading this book helps them a lot in understanding how one administer an Apache server (from a sys-admin or programmer¹s point of view) and learn what Apache is all about (if you thought the Apache Bible is good, this book helps you understand the workings of Apache even better). This book is like a brilliant TLC tele-surgery of high-performance Apache modules. Good for web-Jedi¹s all over the galaxy. I felt like I just camped and spent two weeks in a web-guru¹s workshop.Conclusion: *sniffle* Your book rule, worth every penny.
The first part of that truism can perhaps be said of Web Wizards and Apache modules. Fortunately Apache modules are a little easier to write than Sendmail configurations and this book makes it easier still.
Let's not mince words. Perl scripts and other CGI software can quickly become performance bottlenecks on any server, no matter the size of your hardware. The most powerful way of fixing this is to fold a fair amount of that programming inside the server where the overhead of loading interpreters, libraries and code is already taken care of, not to mention you find yourself with much more power and control over the dialogue between server and browser.
Unfortunately writing to an API as large and complex as that in Apache is not always easy. MacEachern and Stein go to a great deal of trouble and exert a fair degree of skill in breaking the learning down into manageable chunks and explaining it all with a large number of examples.
This was the first book I read that really made me understand the process going on, both between the two pieces of software and inside Apache, when a page is requested. From there the book goes on to give you a marvellous understanding of how to write a module in Perl that fits into that process. Finally the last three chapters are excellent API reference guides, one on the Perl API and two on the C API, and an excellent index (which indexes every function in the API's as well as key concepts) make this a superb tool when you get down to writing.
The book does not cover using C in any where near as much depth, but the vital conceptual understanding required and explained in the Perl chapters means that once you have written a module in Perl I don't believe you will find it a problem to do it in C. I have to say though, as a C programmer I am yet to do it, I get so much performance out of a module in Perl I've yet to find the need.
I read this book before starting my first module and I have now written three. I would never have even contemplated the task before reading this volume. I would recommend this book to anyone who wants to get a full understanding of writing software for the web and anyone who wants a quantum leap in the performance of their web software. You will need some fair Perl skills and preferably written a few CGI scripts as this book does not cover the language skills required at all.
Look for similar items by category
- Books > Business, Finance & Law > E-Commerce > Managers' Guides to Computing
- Books > Computing & Internet > Digital Lifestyle > Online Shopping > Amazon
- Books > Computing & Internet > New to Computing
- Books > Computing & Internet > Programming > Languages
- Books > Computing & Internet > Programming > Languages & Tools
- Books > Computing & Internet > Programming > Software Design, Testing & Engineering > Functional Programming
- Books > Computing & Internet > Programming > Software Design, Testing & Engineering > Software Architecture
- Books > Computing & Internet > Web Development > Web Scripting & Programming
- Books > Computing & Internet > Web Development > Web-server Software > Apache