ch1intro.htm
来自「FastCGI,语言无关的、可伸缩架构的CGI开放扩展」· HTM 代码 · 共 582 行 · 第 1/2 页
HTM
582 行
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML> <HEAD> <TITLE> FastCGI Programmer's Guide - Chapter 1, The Fast Common Gateway Interface </TITLE><STYLE TYPE="text/css"> body { background-color: #ffffff; } li.c2 {list-style: none} div.c1 {text-align: center}</STYLE> </HEAD> <BODY> <A HREF="cover.htm">[Top]</A> <A HREF="ap_guide.htm">[Prev]</A> <A HREF="ch2c.htm">[Next]</A> <A HREF= "ap_guida.htm">[Bottom]</A> <HR> <BR> <A NAME="9432"></A> <DIV CLASS="c1"> <H1> 1 The Fast Common<BR> Gateway Interface </H1> </DIV> <A NAME="7982"></A> <P> The Fast Common Gateway Interface (FastCGI) is an enhancement to the existing CGI (Common Gateway Interface), which is a standard for interfacing external applications with Web servers. </P> <P> <A NAME="8373"></A> FastCGI is a proposed open standard and we expect both free and commercial Web servers to support it. FastCGI is included in Open Market WebServer and Secure WebServer, versions 2.0 and greater. </P> <BR> <BR> <H1> Advantages of FastCGI </H1> <A NAME="8369"></A> <P> FastCGI extends and enhances the CGI model in several ways: </P> <BR> <BR> <UL> <LI CLASS="c2"> <A NAME="7832"></A> </LI> <LI> FastCGI enables applications to persist between client requests, eliminating application start up overhead and allowing the application to maintain state between client calls. <A NAME="7995"></A> </LI> <LI> FastCGI enables applications to reside on remote systems (rather than having to reside on the same system as the Web server) <A NAME="7997"></A> </LI> <LI> FastCGI enables additional flexibility in application functionality, with explicit support for applications that do client authentication and filtering of input. </LI> </UL> <H2> Long-lived Applications </H2> <A NAME="8458"></A> <P> CGI applications are ephemeral and short-lived: each time a client requests a CGI application, the server asks the operating system to spawn a new CGI process. After the CGI process satisfies the request, the server kills it. The server spawns and subsequently kills a new process for each client request. </P> <P> <A NAME="8459"></A> FastCGI applications are long-lived, and can persist between client calls. The server spawns the FastCGI process once and it continues to run and satisfy client requests until it is explicitly terminated. You can also ask the Web server to start multiple copies of a FastCGI application, if you expect that concurrent processing will improve the application's performance. </P> <P> <A NAME="5761"></A> Long-lived applications have two important advantages over short-lived applications: </P> <BR> <BR> <UL> <LI CLASS="c2"> <A NAME="7138"></A> </LI> <LI> A short-lived application pays start up overhead on every request; a long-lived application spreads the overhead over many requests. For an application that has a heavy start up cost, such as opening a database, doing initialization on every call can be very inefficient. Reinitializing for every client is also very inefficient for Perl programs, where the interpreter reads through the entire program before executing any of it. <A NAME="9204"></A> </LI> <LI> A long-lived application can cache information in memory between requests, allowing it to respond more quickly to later requests. </LI> </UL> <A NAME="8733"></A> <P> FastCGI is not the only way to get a long-lived application on the Web, however. For example, there are many existing search engines that are implemented as long-lived applications. </P> <P> <A NAME="8734"></A> In most cases, these applications rely on customized Web servers. In other words, since most Web servers do not support long-lived applications, a programmer must code this support into a Web server. This approach requires a tremendous amount of work and also ties the application to a particular server. </P> <P> <A NAME="8735"></A> Another way to get a long-lived application is to write code that calls routines from the Web server's API. This alternative involves a lot of extra coding, ties the application to a particular Web server, and introduces problems of maintainability, scalability, and security. </P> <P> <A NAME="8736"></A> We believe that FastCGI is the most general and flexible strategy for building long-lived Web applications. </P> <BR> <BR> <H2> Separating Application and Server </H2> <A NAME="8446"></A> <P> CGI applications must run on the same node as the Web server; FastCGI applications can run on any node that can be reached from your Web server using TCP/IP protocols. For example, you might want to run the FastCGI application on a high-speed computer server or database engine, and run the Web server on a different node. </P> <BR> <BR> <H2> FastCGI "Roles" </H2> <A NAME="8777"></A> <P> CGI and FastCGI applications are effective ways to allow an application to act as an extension to the Web server. CGI provides no explicit support for different kinds of applications: under CGI, every application receives an HTTP request, does something with it, and generates an HTTP response. FastCGI provides explicit support for several common "roles" that applications can play. </P> <P> <A NAME="8769"></A> The three roles supported by the WebServer 2.0 are: </P> <BR> <BR> <UL> <LI CLASS="c2"> <A NAME="8409"></A> </LI> <LI> Responder <A NAME="8410"></A> </LI> <LI> Filter <A NAME="8411"></A> </LI> <LI> Authorizer </LI> </UL> <H3> Responder Applications </H3> <A NAME="8679"></A> <P> A <EM>responder</EM> application is the most basic kind of FastCGI application: it receives the information associated with an HTTP request and generates an HTTP response. Responder is the role most similar to traditional CGI programming, and most FastCGI applications are responders. </P> <BR> <BR> <H3> Filter Applications </H3> <A NAME="8681"></A> <P> A <EM>filter</EM> FastCGI application receives the information associated with an HTTP request, plus an extra stream of data from a file stored on the Web server, and generates a "filtered" version of the data stream as an HTTP response. </P> <P> <A NAME="8421"></A> With filter applications, the system administrator maps a particular MIME-type to a particular filter FastCGI application. When a client requests a URL with that MIME-type, the Web server invokes the filter application, which processes the file at the specified URL and sends a response (usually HTML text) back to the client. </P> <P> <A NAME="8422"></A> For example, suppose you write a filter FastCGI application that converts SGML text to HTML, and map the extension .sgml (MIME-type SGML) to your filter FastCGI application. Now, suppose that a user requests the following URL: </P> <BR> <BR><PRE><A NAME="8423">/www.aerjug.com/docs/chap1.sgml</A></PRE> <A NAME="8424"></A> <P> Given this URL, the Web server passes <CODE>chap1.sgml</CODE> as input to your filter FastCGI application, which processes <CODE>chap1.sgml</CODE> and returns an HTML version of it to the requesting client. </P> <BR> <BR> <H3> Authorizer Applications </H3> <A NAME="8426"></A> <P> An <EM>authorizer</EM> FastCGI application receives the information in an HTTP request header and generates a decision whether to authorize the request. </P> <P> <A NAME="8428"></A> To mark a FastCGI application as having the authorizer role, the system administrator names the application inside the server configuration file, using a directive called <CODE>AuthorizeRegion</CODE>. (See the Open Market Web Server manual for information on server configuration directives.) </P> <P> <A NAME="8429"></A> When a client requests a URL that meets the <CODE>AuthorizeRegion</CODE> criteria, the Web server calls your authorizer FastCGI application. If your application grants authorization (by returning a response code of 200), the Web server resumes execution of commands in the <CODE>AuthorizeRegion</CODE> section. If your application denies authorization (by returning any other response code), the Web server stops processing subsequent commands in the <CODE>AuthorizeRegion</CODE> section, and returns the response from your FastCGI application to the client. </P> <P> <A NAME="8431"></A> Authorizer applications can return headers containing environment variables. Other CGI or FastCGI programs accessing this request (including other authorizers) can access these environment variables. The headers must have the following format: </P> <BR> <BR><PRE><A NAME="8432">Variable-<EM>name</EM>: <EM>value</EM></A></PRE> <A NAME="8433"></A> <P> For example, the following header </P> <BR> <BR><PRE><A NAME="8434">Variable-AUTH_METHOD: database lookup</A></PRE> <A NAME="8435"></A> <P> causes the environment variable <CODE>AUTH_METHOD</CODE> to be set to <CODE>"database lookup"</CODE> for this request. Other CGI or FastCGI applications running on this request can access the value of <CODE>AUTH_METHOD</CODE>. </P> <P> <A NAME="8437"></A> Authorizer applications cannot successfully read from standard input. Any attempts to read from standard input result in an immediate EOF. </P> <P> <A NAME="8438"></A> All data that authorizer applications write to standard error will get written to the traditional server error logs. </P> <BR> <BR> <H1> Writing FastCGI Applications </H1> <A NAME="9301"></A> <P> The work involved in writing a FastCGI application depends in large part on the I/O libraries that you use. This manual describes how to write FastCGI applications in terms of the Open Market libraries, which are available for C, Perl, and Tcl. FastCGI is an open standard and you are welcome to build your own libraries for other languages as well, but this manual focuses on building FastCGI applications in the context of the Open Market libraries. </P> <P> <A NAME="9443"></A> </P> <P> <A NAME="9450"></A> In general, the goal of the libraries is to make the job of writing a FastCGI application as much like writing a CGI application as possible. For example, you use the same techniques for query string decoding, HTML output to stdout, use of environment variables, and so on. When you use our libraries, porting CGI applications to FastCGI is mostly a matter of restructuring the code to take advantage of FastCGI features and libraries. </P> <BR> <BR> <H2> Code Structure </H2> <A NAME="9470"></A>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?