This Tutorial introduced you to client/server architecture. The browser and your CGI program are a classic example of the client/server architecture. The client requests some service of your CGI program. Your CGI program, the server, responds or services the client’s request.
You also learned that the request and response system is initiated using HTTP headers. These headers are called request/response headers. The HTTP request/response headers are sent through the Internet using the TCP/IP message protocol.
The first header of every HTTP request/response sequence is the method request header. And the first response header always will be a Status response header. The method response header defines what the server is expected to do with any additional data and how that data might affect the URI in the method response header. The Status response header from the server defines the success or failure status of the method response header.
This basic knowledge is the foundation for many future applications-one of which is redirecting your Web page client based on the User-Agent HTTP header. Tomorrow you will learn the fundamentals of how to build an interactive Web site. In Tutorial 3 you will learn all the details you need to know to implement Server Side Include commands, which enable you to build interactive Web pages with very little programming knowledge. In Tutorial 4 you learn how to send data to your CGI program-the basis for making any interactive CGI application.
||What are the basic headers required for returning a Web page?
||The question seems to boil down to what you have to do to return HTML from your CGI program. The answer is not very much!
First and most common is the Content-Type response header. Use this when your CGI program is going to return some MIME-compliant data. Remember that the Content-Type header tells the browser what type of data to expect so that it can launch the proper application to receive it. The server will do any remaining work required to go with the returned data.
Next, you could send a Location response header. The browser will receive, along with the Location response header, a Status response header of 301, telling the browser about the moved URI. Your server generates the Status response header. The Location response header tells the browser that the request URI is at another location.
Finally, your CGI code could return one of the many status codes describing to the browser the status of the URI request. If you do this, you need to return the Status response header from a non-parsed header (NPH) CGI program. The NPH-CGI program doesn’t get any help generating response headers from the server. If your program is generating the Status response header, however, you don’t want help from the server because the server’s response will conflict with your Status response header. Tutorial 4discusses NPH-CGI programs.
These three response headers-Content-Type, Location, and Status-are the basic response headers that your CGI program will use to return information to your client.
One Last Note:
Always Always Always remember to send two newlines (\n) after outputting the last response header from your CGI program. This is such an easy thing to do and is often the source of broken CGI programs.
||How did you get that screen capture of the response header in Figure 2.2?
||This one is kinda easy and therefore fun to play with. Remember that section on TCP/IP and how the connection is to a public socket over a predefined port? Well, that port for the HTTP server is number 80. So if you first log onto your server, you then can Telnet to port 80.
Take a look at the way I did this in Figure 2.2.
First, I did a regular Telnet connection to my Internet provider. After I logged onto my provider’s UNIX machine, I Telneted to one of the Web servers I’m responsible for. I did this from the command line by typing > telnet www.accn.com 80.
The 80 also could be replaced with http. http is the name of the program or daemon that is assigned to listen for and interpret connections on port 80. The default port for HTTP’s Internet connection is 80. Using 80 in this command always works. Using http usually works.
Next, I just typed a valid Get method request header. I could have requested a CGI program. I even could have sent PATH_INFO and QUERY_STRING data. This is a great way to see what the server does with your request headers.
You can send as many valid request headers as you want this way; just end the sequence of request headers with a blank line. The server will process the typed request headers just as if it had received them in the “normal” TCP/IP manner. As far as the server is concerned, it has received the request headers in a normal manner. It can’t tell that these request headers were typed from the command line.
Gook luck and have fun with this one. It’s a great learning tool!
||There seem to be a lot of HTTP headers. How do you tell the request headers from the response headers?
||Well, for the most part, you can’t. Remember that HTTP headers can be used as both client and server HTTP headers. There are a few headers that describe just the server; these are always response headers. The other headers can be used as both response and request headers, however. Think of the Content-Length header. This header is used by both the client and the server for most transactions. When the client is sending Post data, a Content-Length request header is sent to the server. When the server is returning an HTML file, a Content-Length response header is sent to the client.
As you can see, whether an HTTP header is a request or response header is based on the sender. Request headers are sent by the client. Response headers are sent by the server.