|
|
|
| |
        
|
 |
|
To access the contents, click the chapter and section titles.
HTML 4.0 Sourcebook
Example 21: Gateway Program Server DirectivesThe second example looks at how HTTP servers compose a response header for data returned by a gateway program. Consider first the actual data sent by a server (here, the Apache 1.1.1 server) upon the client’s first access of the program srch-example (Figure 10.5; these are the data that produced Figure 10.3). Comparing Figure 10.5 with Figure 10.2, you will see that the headers are not those returned by the script: The content-type headers are typographically different (Content-TYPE versus Content-type). In fact, the headers returned to the client were generated by the HTTP server, with help from server directives returned by the gateway program. Server DirectivesThe server takes the header data returned by the gateway program and parses each of the header fields. Most of these headers are passed through unaltered and are included as part of the server response header returned to the client. Some, however, are treated as server directives and are used by the server to modify the HTTP response header fields the server normally returns in the response. The three valid server-directive headers are listed and described in Table 10.1. Figure 10.5 Data returned to the client upon accessing the URL: <http://leonardo.utirc.utoronto.ca:8080/cgi-bin/srch-example> These are the data that produce Figure 10.3. HTTP/1.0 200 OK Server: Apache/1.1.1 Date: Thu, 01 Aug 1996 16:43:53 GMT Content-type: text/html <HEAD> <TITLE>Local Phonebook Search</TITLE> <ISINDEX> </HEAD> <BODY> <H1>Local Phonebook Search</H1> Enter your search in the search field.<P> This is a case-insensitive substring search: thus searching for ‘ian’ will find ‘Ian’ and Adriana‘. </BODY> In addition to these special server directives, a gateway program can return most regular server response header fields—they will simply be forwarded to the client as part of the response header, following those headers generated by the server itself. For example, if a gateway program returns results from a database that is updated on a regular basis, the program could return an Expires header as part of the server directives to indicate when the data will be stale, thereby allowing clients to reliably cache copies until the specified expiration date. Limitations of Server Directives You must not use server directives to produce duplicates of the headers ordinarily returned by the server—such headers usually describe generic characteristics of the server and cannot be altered by a gateway program. For example, the Server, Date, and MIME-Version header fields are server-specific and should never be returned by a gateway program. But, as with spelling, there is an exception to every rule—and the exception here is for non-parsed header gateway programs. Non-Parsed Header Gateway ProgramsIt is possible to return gateway program output directly to the client without any processing by an HTTP server—in this case, the gateway can return any header fields it wants, regardless of the rule presented above. This is accomplished by appending the string nph-, for non-parsed header, to the beginning of the name of the script. When the server sees a gateway program name beginning with nph-, it passes the gateway program output directly to the client, without any processing. For example, Figure 10.6 shows the data returned from the gateway program nph-srch-example: This is an exact duplicate of the program srch-example listed in Figure 10.2, the only change being the string nph- added to the front of the filename.
Comparing Figure 10.6 with the program listing in Figure 10.2 shows that the response now contains just the data printed by the gateway program, with nothing added or modified by the server. The advantages of non-parsed header gateway programs is speed and flexibility, since the server is not required to parse the returned data and generate appropriate headers and the programmer is not limited in what can be placed within the response header. In exchange, the gateway program itself must produce all the required headers fields. Note how the returned data in Figure 10.6 are an invalid server response, as the response does not contain a status line nor does it indicate the date or server type. Thus an nph- script must print, at a minimum, the following response headers, with values appropriate to the script and the data being returned (the portions that must be customized to the situation are shown in italics; these are just example values): Figure 10.6 Non-parsed header output returned upon accessing the URL. <http://leonardo.utirc.utoronto.ca:8080/cgi-bin/nph-srch-example> Content-TYPE: text/html <HEAD> <TITLE>Local Phonebook Search</TITLE> <ISINDEX> </HEAD> <BODY> <H1>Local Phonebook Search</H1> Enter your search in the search field.<P> This is a case-insensitive substring search: thus searching for ‘ian’ will find ‘Ian’ and Adriana’. </BODY> HTTP/1.0 200 OK Date: Thu, 01 Aug 1996 16:50:57 GMT Server: NCSA/1.5.2 Content-type: text/x-babelfish Custom Response FieldsOf course, a CGI program can return any manner of response fields—with non-parsed header scripts, these are passed right through to the client, while if the server parses the response, it will generally pass along any well-formed field that does not conflict with a field the server normally returns. This can be useful, as some browsers understand nonstandard fields in the response header. For example, Netscape Navigator understands content-disposition fields of the form: content-disposition: attachment; filename= name-of-file
|
|||||||||||||||||||
|
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.
|
)
)
){kind=link}
){kind=link}