docs.rinet.ru/UCGI/ch13.htm
Chapter 13 - Proprietary Extensions to Severs Chapter 13 Proprietary Extensions to Severs CONTENTS Server Push HTTP Cookies Other Server Extensions WebServer/400 Apache Modules Jigsaw Resources Netscape and Microsoft Summary Behind every good CGI program is a good server, usually an HTTP server. An HTTP server is a program that intermediates between the end user the browser and the CGI program itself. It is the server that actually spawns the CGI program, passing along information from the browser, and it is the server that collects the output of the CGI program and sends it back to the end user who requested it. At its most basic, that is all a Web server has to do: Be a sort of halfway house for information between the client and the machine storing the data. It didnt take long before people started to realize that the more tricks a server had up its sleeve, the less work they would have to do with external CGI programs. Server extensions are added bits of functionality that are either built straight into the server or dynamically added to the server as needed. This means that when a client requests a function from a server, the server extension is right there. Unlike CGI programs, a server extension does not require an extra process to be run on the host machine. A downside to server extensions is that they are largely proprietary, meaning that a nifty add-on to the ncSA server might not be present in the CERN server or vice versa. However, several server extensions have proven useful enough to be added to many of the most popular Web servers which at the time of this writing means Apache, ncSA, and Netscape. Ill start by looking at the two server extensions that are currently used the most: server push and cookies. Server Push Server push was first envisioned as a method for displaying simple animations over the Web. At the time server push was implemented, it was the only option, but today Web animations are better served by Java or GIf89a extensions. Other applications have been found for server push, and its cousin, client pull, so it remains a useful extension supported by almost all servers. To understand server push, you must first look at how the Web server handles data before it passes it on to the client. When asked to retrieve a file from the host, the server first looks at the extension of the file and based on that, assigns it a MIME type. MIME Multipurpose Internet Mail Extensions types tell the browser what type of file it is receiving. This is usually put in the initial header of the document, which the end user never sees.
The second line gives the date the document was last modified, and the last line gives the size of the document in bytes. The third line, Content-type: text/html , tells the browser to expect an HTML document and treat it accordingly. As intimated by the acronym, MIME was originally designed as a set of protocols to enable electronic mail to contain full multimedia enhancements. In fact, most modern mail clients do support MIME, but its usefulness has grown beyond that. One of the necessities of transferring multimedia mail is the capability to enclose several different types of documents in one message. A document of this type has a string of characters given in the header known as the boundary. This boundary can occur any number of times in the message, each time preceded by - . Each section of document between boundaries is considered a separate message with its own MIME type.
The x means that its an extra type that is not part of the official MIME specification. This means that instead of one message with lots of different types, a multipart/x-mixed-replace message is really lots of separate messages all with the same type. When applied to a MIME type such as image/gif, this multipart/x-mixed-replace causes one GIF to be displayed and then replaced by another and so on. Because the key to server push lies in the header that appears before the document is sent, you cant use server push within a plain HTML document. You must use a CGI program to generate the document and send each part along as needed. One of the great advantages of server push is that as long the browser remains on the page, the server can keep the connection open as long as it wants. Suppose you want to keep users around the world up-to-date on the local softball game. Using server push, a connection is kept open between your server and each viewer, and you could send an updated score whenever necessary. Note The advantage of a persistent connection can also be a disadvantage. Having a server keep the connection open keeps the servers process alive, which could cause added load to your system. This is usually not a problem, but if you get thousands of hits a day, it does add up. For a simple example, you can go back to the original purpose of server push and make a poor mans animation. Ill use Perl for these examples, although this first one is simple enough for Bourne Shell.
This also means that people using a good connection might receive the images too fast to display and could skip images. You can avoid this by using sleep statements in strategic parts of the script to pause between images. Using sleep statements is also a good way to create slide-show-type animations. You could cause each image to stay on the screen for however long is necessary before the next image is called up. As mentioned previously, you can also use server push to create an HTML document that updates itself as needed. As long as the client stays on the page, it receives the new information;
Even though it has lost the spotlight to newer and flashier technologies, server push can still yield great results when applied creatively. HTTP Cookies Aside from being great with milk, cookies have become one of the most discussed server extensions ever. HTTP cookies are an attempt to solve one of the great hurdles of working with CGI: state retention. Once the server sends the document to the client, it forgets that the client ever existed. If a user browses through a hundred pages on the same site, they make a hundred separate connections to the same server. Almost all CGI-based applications, from games to databases, need to store information about the person using them between calls to the program. Traditionally, this requires saving information in temporary files or hidden variables in HTML forms. For instance, a series of CGI programs that interact with a database might ask for a username on the first page, save the data to a temporary file, and then pass the username and temporary filename from CGI to CGI by using hidden variables. Cookies are an attempt to simplify this by allowing the browser to store information sent to it by the server. The browser then sends the information back each time it accesses that server. To avoid filling up the hard drive of the end user, cookies are generally very short pieces of information: usually an ID number or filename of a file on the server that contains more information. Note Although called server extensions, almost everything discussed in this chapter must also have support on the client side. Unless the browser has the capability to store the cookie information, your CGI cant do anything with it. At the time of this writing, several major browsers still have not implemented HTTP cookies, including Lynx-FM and ncSA Mosaic. If your pages absolutely depend on cookies, its a good idea to provide an alternate mechanism for people who have no access to a cookie-capable browser. Like server push, HTTP cookies are implemented through the HTTP header that is sent before the document itself. The value of a cookie is passed to the client through the header Set-Cookie . The full syntax, as it would appear to a browser receiving a cookie, is as follows: Set-Cookie: namevalue;
Including this subroutine in an external package allows you to check for cookies easily in any CGI script. Originally, they were mainly used for storing user preferences and to facilitate shopping cart systems. The ability to store data on the client side has proven to be very versatile. If you have access to a Netscape browser version 20 or greater,...
|
http://csua.com/feed/