📄 00000096.htm
字号:
server or even alter its existing functionality. Modules are usually <BR>compiled into the server. When building Apache you specify what modules <BR>you'd like to include and the module will be compiled into the Web server <BR>binary. <BR> Some people found this a bit cumbersome—having to recompile the entire <BR>server to add just one module; so in more recent versions of Apache <BR>(1.3.x) you can compile a module into a "shared object" (what Windows <BR>people know as a DLL) and load the module at runtime. Adding or removing a <BR>module can now be done by compiling the module and editing the <BR>configuration file. This functionality did exist previously, but in a more <BR>experimental form. <BR> In principle, the Apache Web server is not a complicated piece of <BR>software. Simply put, it consists of a core that takes care of all the <BR>low-level functions; a set of modules to provide whatever functionality <BR>you would want from your Web server; and handlers to call those modules. <BR>But how do the modules work? How does the Web server decide what to do and <BR>when? <BR> Phases: When Apache receives a request it will go through a number of <BR>"phases" in order to serve the request, as shown in Figure 1. That <BR>simplifies the task of the developer who wants to extend some aspect of <BR>the server. For instance, if the developer wants to provide her own <BR>authentication modules she will only need to write the code needed to do <BR>the actual authentication. The developer will not have to bother with the <BR>other tasks that need to be performed, like determining the MIME type of <BR>the requested object or even write the code that sends the object back to <BR>the user. <BR>Handlers: A module can define "handlers" for one or more phases. For each <BR>phase the server has a list of handlers from various modules that should <BR>be called during each phase. Each module defines a hard-coded data <BR>structure that identifies what phases it can handle. <BR>When the server calls a handler, the handler performs its task and returns <BR>a status code indicating how things went. An OK code will be returned if <BR>the handler performed its task successfully. <BR>The handler can also decline to handle the request and return the DECLINED <BR>code, in which case the Web server simply ignores the handler and calls <BR>the next handler in the list for that phase. Should an error occur, the <BR>handler can indicate this by returning one of the HTTP error codes. The <BR>server will then abort further request processing, write a message to the <BR>error log and send an error message to the browser. <BR> To sum up, a request goes through a number of phases. For each phase the <BR>server maintains a list of handlers. The server will call each handler in <BR>the list until a handler signals that it has handled the request or until <BR>an error is reported. A module can contain one or more handlers. Writing <BR>your own modules <BR> If you plan on writing your own modules you should start out by reading <BR>the "Apache API notes" section of the Apache documentation that comes with <BR>the server. This will give you a basic idea of how to write a module. <BR> After that, look at some of the modules that come with Apache. If you look <BR>under the src/modules directory in the Apache 1.3 source distribution you <BR>will find both standard and experimental modules plus a sample module <BR>called mod_example that is heavily commented to help you understand what <BR>it does. <BR> <BR> <BR>Server-Side Programming <BR> <BR> Modules, like the Web server itself, are generally implemented in the C <BR> programming language. While it makes perfect sense to write a Web server <BR> in C, it may not be very practical for the average Web developer to use <BR> it. C is rather hard to use, even harder to debug, and judging by some of <BR> the code I have seen, it can be terribly hard to read and understand. <BR> The Web industry moves at a fast pace. Customers want their Web sites <BR> online quickly and many of the Web developers have little or no prior <BR> experience in software development. Needless to say, the unforgiving <BR> nature of C makes it hard for inexperienced developers or those stressed <BR> for time to produce reasonably stable code fast enough. <BR> Writing modules for Apache in C may be an option for some, but for others <BR> the time constraints or their ability may be too restrictive for a given <BR> project. Fortunately, Apache gives you other ways to program function in, <BR> the most general solutions being the Common Gateway Interface (CGI) and <BR> FastCGI. <BR> Perhaps the most common solution in the past, and presumably to this day, <BR> is to use CGI in conjunction with some scripting language like Perl. While <BR> widely used, CGI is actually rather crude. It relies on the Web server to <BR> spawn a new process, send the pertinent data for the request to the <BR> process, and then read the response from the program and send it back to <BR> the client. As mentioned earlier, starting and stopping processes is the <BR> nemesis of performance, so the standard CGI mechanism is likely to <BR> introduce bottlenecks into your system. <BR> Not only will the Web server have to spawn a new process, but if you use a <BR> scripting language like Perl, the Perl interpreter will have to read the <BR> script, load the appropriate Perl modules and compile the script into byte <BR> code that can then be executed. Even if you use a language that lets you <BR> produce pre-compiled binaries, there is still the significant overhead of <BR> spawning a new process. <BR> But CGI isn't all bad. The fact that it is so simple to use is probably <BR> what made it so popular in the first place, and an added bonus is that you <BR> are not limited to any one language when creating CGI scripts. If you <BR> like, you can use any language that is able to read environment variables <BR> and communicate using the standard I/O mechanisms. <BR> But before you dismiss CGI as old-hat, consider the Fast CGI option. When <BR> you use FastCGI, your CGI scripts will not terminate between requests, but <BR> keep running, waiting for the next request to arrive, thus eliminating the <BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -