|
|
|
| |
        
|
 |
|
To access the contents, click the chapter and section titles.
Platinum Edition Using HTML 4, XML, and Java 1.2
Part VI
|
 | ON THE WEB http://www.w3.org/Addressing/ W3C’s resource site, “Web Naming and Addressing (URIs, URLs, etc...)” is an excellent place to learn about Web addressing and URLs, with explanations, links, and history. |
After a server has responded to a request from a browser, it breaks the connection. If the document you get back has links to other documents (inline graphics, for instance), your browser goes through the whole routine again. Each time you contact the server, it’s as if you’d never been there before, and each request yields a single document. This is what’s known as a stateless connection.
Fortunately, most browsers keep a local copy, called a cache, of recently accessed documents. When the browser notices that it’s about to refetch something already in the cache, it supplies the information from the cache rather than contact the server again. This greatly lessens network traffic.
Using a cache is fine for retrieving static text or displaying graphics, but what if you want dynamic information? What if you want a page counter or a quote-of-the-day? What if you want to fill out a guest book form rather than just retrieve a file?
The State of HTTP
Because the server doesn’t remember you between visits, the HTTP 1.0 protocol is called stateless. This means that the server doesn’t know the state of your browser, whether this is the first request you’ve ever made or the hundredth request for information making up the same visual page. Each GET or POST (the two main methods of invoking a CGI program) in HTTP 1.0 must carry all the information necessary to service the request. This makes distributing resources easy but places the burden of maintaining state information on the CGI application.
A “shopping cart” script is a good example of needing state information. When you pick an item and place it in your virtual cart, you need to remember that it’s there so that when you get to the virtual checkout counter, you know what to pay for. The server can’t remember this for you, and you certainly don’t want the user to have to retype the information each time he sees a new page. Your program must track all the variables itself and figure out, each time it’s called, whether it has been called before, whether this is part of an ongoing transaction, and what to do next. Most programs do this by shoveling hidden fields into their output, so when your browser calls again, the hidden information from the last call is available. In this way, it figures out the state you’re supposed to have and pretends you’ve been there all along. From the user’s point of view, it all happens behind the scenes.
The Web has used HTTP 1.0 since 1990, but many proposals for revisions and extensions have been discussed since then. HTTP/1.1 Revision 4 came out in August 1998; HTTP 1.1 is very close to completion and contains many changes to the current HTTP protocol. Netscape Communicator 4 and Microsoft Internet Explorer 4 are both compatible with HTTP 1.1.
 | ON THE WEB http://www.w3.org/Protocols/ If you’re interested in the technical specifications of HTTP, both current and future, stop by this site. |
NOTE: HTTP 1.1, when approved and in widespread use, will provide a great number of improvements for state information. In the meantime, however, the protocol is stateless, and that’s what your programs will have to remember.
When the URL points to a program, however, the server starts the program. The server then sends back the program’s output as if it were a file. What does this accomplish? For one thing, a CGI program can read and write data files (a Web server can only read them) and produce different results each time you run it. This is how page counters work. Each time the page counter is called, it finds the previous count from information stored on the server (usually in a file), increments it by one, and creates a .gif or .jpg file on-the-fly as its output. The server sends the graphic data back to the browser the same as if it were a real file living somewhere on the server.
NCSA Software Development maintains the CGI specification. You’ll find the specification—along with other excellent links—online at the World Wide Web Consortium’s CGI pages: http://www.w3.org/CGI/. This document goes into great detail, including history, rationales, and implications. If you don’t already have a copy, download one and keep it handy. You won’t need it to understand the examples in this book, but it will give you a wonderful overview of CGI and help you think through your own projects in the future.
NOTE: The current version of the CGI specification is 1.1. The information you’ll find at www.w3.org is composed of continually evolving specifications, proposals, examples, and discussions. You should keep this URL handy (make a bookmark) and check in from time to time to see what’s new.
| 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.
|
