home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

HTML 4.0 Sourcebook
(Publisher: John Wiley & Sons, Inc.)
Author(s): Ian S. Graham
ISBN: 0471257249
Publication Date: 04/01/98

Bookmark It

Search this book:
 
Previous Table of Contents Next


Chapter 11
CGI Examples, Programs, and Tools

This chapter discusses some practical issues associated with CGI. The first section covers the Netscape client-pull/server-push HTML and HTTP extensions, which are currently implemented on most browsers. These extensions allow for rudimentary animation of Web presentations—examples are provided that illustrate how these extensions work. The second section is a discussion of server-side includes. This is a special feature of many HTTP servers that allows for parsable HTML documents which are processed, by the server, prior to being delivered to a client. The third section gives a detailed presentation of six gateway programming examples, illustrating some of the important issues in gateway program design.

The remaining seven sections are a guide to useful CGI resources. The topics covered include FastCGI (a tool for significantly speeding up CGI program execution), CGI and generic Web application programming libraries, security wrappers for enhanced CGI security, tools that support sophisticated server-side document parsing, “utility” CGI programs for handling common tasks, and CGI packages for connecting Web pages to databases. The chapter concludes with a list of references useful for obtaining additional or updated information.

Netscape CGI Animation Techniques

Most modern browsers support mechanisms that allow for slide show-like presentations and for a rudimentary form of “pushed” animation. The animation scheme, called server-push , uses a special multipart MIME type to let a server send a client a series of images or documents, which in turn are displayed by the browser as an animated sequence. To use this technique, a Web designer must use a gateway program that sends the data to the client using this special MIME type. The “slide-show” mechanism, more properly called client-pull, uses a special HTTP response header, Refresh, which instructs the browser after a defined delay, to either actively refresh the displayed document, or access another document at a specified URL. Again, a gateway program must produce the Refresh HTTP header field. However, HTML authors can include, in their documents, META elements containing the Refresh header field content (using the HTTP-EQUIV attribute value, as discussed in Chapter 6). The browser parses the documents for the META element and understands Refresh header information. This method is particularly useful for creating document slide shows.

The following sections look in detail at these two animation techniques.

Client-Pull

In client-pull , the server sends the client a special HTTP Refresh response header field. The field has the general form

Refresh: xx ; URL=url_string

where xx is an integer giving the time, in seconds, that the browser should wait before refreshing the document, and url_string is the full (not relative) URL that the browser should access when it is time to do the refresh. For example, the header

Refresh: 10; URL=http://www.utoronto.ca/home.html

tells a browser to wait 10 seconds and then access the indicated URL. The URL portion can be left out, in which case the browser will re-access the URL it just retrieved. Thus, the header

Refresh: 30

tells a browser to refresh the currently displayed URL, after a 30-second delay. The refresh time can be set to zero, in which case the browser will refresh the display as soon as the currently requested data are fully loaded.

There are several things to note about this procedure. First, this response header field is understood by most, but not all, browsers (it is understood by Netscape Navigator 2 and greater, and Internet Explorer 3 and greater); those that do not understand it will simply ignore the header, display the accessed document, and then stop. Second, the Refresh: field must be returned by a gateway program—servers themselves do not return refresh header fields. Third, each request by the client counts as a separate HTTP transaction—in particular, the connection will be broken between requests unless HTTP keep-alive headers are sent by the CGI program sending the documents.

Client-Pull via META Elements

As an alternative to using a CGI program, Refresh can be placed inside an HTML document META element. This lets authors add refresh capability into already existing parsed HTML documents (parsed HTML documents are discussed later in this chapter) or build slide shows into a sequence of regular HTML documents, using the URLs in the Refresh fields to reference consecutive pages. The META element equivalent to the general form of the Refresh HTTP response header is

<META HTTP-EQUIV=“Refresh” CONTENT=“xx; URL=url_string”>

while META elements equivalent to the two examples just given are:

<META HTTP-EQUIV=“Refresh” CONTENT=“10;
      URL=http://www.utoronto.ca/home.html”>
<META HTTP-EQUIV=“Refresh” CONTENT=“30”>

Most browsers understand these META elements and interpret their content as HTTP response header fields (this is the purpose of the HTTP-EQUIV attribute, as discussed in Chapter 6). This is, of course, only possible with HTML documents; if you are returning other forms of data, such as images, you need to use the gateway program approach.

Server-Push

Server-push is a second and fundamentally different way of creating dynamic documents. When a client accesses a resource delivered using server-push, the client-server connection remains open, and the server sends a sequence of data objects, one after the other, over an open connection—the connection does not close until the sequence is finished. This is done using a special MIME multipart message format, discussed next. There are two advantages to this method. First, it is faster than client-pull, since the browser does not need to recontact the server to get the second (or subsequent) piece of data. Second, the method can be used not just for a document, but also for the images within a document—you can use server-push to download a sequence of images into an <IMG SRC="“..”> element. This allows for embedded animation sequences created by referencing, from an IMG element, a gateway program that delivers a sequence of image files via server-push. The disadvantage is that you absolutely need to write a special-purpose gateway program—unlike client-pull, you cannot implement server-push using META elements.


NOTE: Efficiency of Server-Push

Although faster than client-pull, server-push animation is far less efficient than an animated GIF—you should use the latter whenever possible. Server-push is appropriate when the animation must be dynamically generated by a gateway program such as an animated GIF that is dynamically generated by the server or an HTML page that lists the users of a system and is “pushed” whenever a user logs in or out.


Server-push is implemented using the MIME type multipart/x-mixed-replace . By employing this MIME type, a server can deliver a sequence (in principle, an endless sequence) of data files, one after the other. This is done by defining a boundary string as part of the MIME type header. A boundary string is a string of ASCII characters used to separate each part of a multipart message from the preceding and following parts. The MIME content-type declaration takes the form:

Content-type: multipart/x-mixed-replace;boundary=String


Previous Table of Contents Next


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.