To end the header section, the client sends a blank line.
There are many headers in HTTP. We will list all the valid headers in
this chapter, but give special attention to several groupings of headers
that may come in especially handy. Appendix A contains a more
complete listing of HTTP headers.
3. When applicable, the client sends the data portion of the request. This
data is often used by CGI programs via the POST method, or used to
supply document information using the PUT method. These methods
are discussed later in this chapter.
The server responds as follows:
1. The server replies with a status line with the following three fields: the
HTTP version, a status code, and description of the status. For
example:
HTTP/1.0 200 OK
This indicates that the server uses version 1.0 of HTTP in its response,
and a status code of 200 indicates that the client's request was
successful and the requested data will be supplied after the headers.
We will give a listing of each of the status codes supported by HTTP,
along with a more detailed discussion of the status codes you are most
likely to encounter.
2. The server supplies header information to tell the client about itself
and the requested document. For example:
Date: Saturday, 20-May-95 03:25:12 GMT
Server: NCSA/1.3
MIME-version: 1.0
Content-type: text/html
Last-modified: Wednesday, 14-Mar-95 18:15:23
GMT
Content-length: 1029
The header is terminated with a blank line.
3. If the client's request is successful, the requested data is sent. This data
may be a copy of a file, or the response from a CGI program. If the
client's request could not be fulfilled, the data may be a human-
readable explanation of why the server couldn't fulfill the request.
Given this structure, a few questions come to mind:
What request methods can a client use?
What versions of HTTP are available?
What headers can a client supply?
What sort of response codes can you expect from a server, and what
do you do with them?
What headers can you expect the server to return, and what do you do
with them?
We'll try to answer each of these questions in the remainder of this chapter,
in approximate order. The exception to this order is client and server
headers, which are discussed together, and discussed last. Many headers are
shared by both clients and servers, so it didn't make sense to cover them
twice; and the use of headers for both requests and responses is so closely
intertwined in some cases that it seemed best to present it this way.
Client Request Methods
A client request method is a "command" or "request" that a web client issues
to a server. You can think of the method as the declaration of what the
client's intentions are. There are exceptions, of course, but here are some
generalizations:
You can think of a GET request as meaning that you just want to
retrieve a document.
A HEAD request means that you just want some information about
the document, but don't need the document itself.
A POST request says that you're providing some information of your
own (generally used for fill-in forms).
PUT is used to provide a new or replacement document to be stored
on the server.
DELETE is used to remove a document on the server.
TRACE asks that proxies declare themselves in the headers, so the
client can learn the path that the document took (and thus determine
where something might have been garbled or lost).
OPTIONS is used when the client wants to know what other methods
can be used for that document (or for the server at large).
We'll show some examples of each of these seven methods. Other HTTP
methods that you may see (LINK, UNLINK, and PATCH) are less clearly
defined, so we don't discuss them in this chapter. See the HTTP specification
for more information on those methods.
GET: Retrieve a Document
The GET method requests a document from a specific location on the server.
This is the main method used for document retrieval. The response to a GET
request can be generated by the server in many ways. For example, the
response could come from:
A file accessible by the web server
The output of a CGI script or server language like NSAPI or ISAPI
The result of a server computation, like real-time decompression of
online files
Information obtained from a hardware device, such as a video camera
In this book, we are more concerned about the data returned by a request
than with the way the server generated the data. From a client's point of
view, the server is a black box that takes in a method, URL, headers, and
entity-body as input and generates output that clients process.
After the client uses the GET method in its request, the server responds with
a status line, headers, and data requested by the client. If the server cannot
process the request, due to an error or lack of authorization, the server
usually sends an explanation in the entity-body of the response.
Figure 3-2 shows an example of a successful request. The client sends:
GET /index.html HTTP/1.0
User-Agent: Mozilla/1.1N (Macintosh; I; 68K)
Accept: */*
Accept: image/gif
Accept: image/x-xbitmap
Accept: image/jpeg
The server responds with:
HTTP/1.0 200 OK
Date: Sat, 20-May-95 03:25:12 GMT
Server: NCSA/1.3
MIME-version: 1.0
Content-type: text/html
Last-modified: Wed, 14-Mar-95 18:15:23 GMT
Content-length: 1029
(body of document here)
Figure 3-2. GET transaction
HEAD: Retrieve Header Information
The HEAD method is functionally like GET, except that the server will
reply with a response line and headers, but no entity-body. The headers
returned by the server with the HEAD method should be exactly the same as
the headers returned with a GET request. This method is often used by web
clients to verify the document's existence or properties (like Content-
length or Content-type), but the client has no intention of retrieving
the document in the transaction. Many applications exist for the HEAD
method, which make it possible to retrieve:
Modification time of a document for caching purposes
Size of the document, to do page layout, to estimate arrival time, or to
skip the document and retrieve a smaller version of the document
Type of the document, to allow the client to examine only documents
of a certain type
Type of server, to allow customized server queries
It is important to note that most of the header information provided by a
server is optional, and may not be given by all servers. A good design in web
clients is to allow flexibility in the server response and to take default
actions when desired header information is not given by the server.
Figure 3-3 shows an example HTTP transaction using the HEAD method.
The client sends:
HEAD /sample.html HTTP/1.0
User-Agent: Mozilla/1.1N (Macintosh; I; 68K)
Accept: */*
Accept: image/gif
Accept: image/x-xbitmap
Accept: image/jpeg
The server responds with:
HTTP/1.0 200 OK
Date: Sat, 20-May-95 03:25:12 GMT
Server: NCSA/1.3
MIME-version: 1.0
Content-type: text/html
Last-modified: Wed, 14-Mar-95 18:15:23 GMT
Content-length: 1029
(Note that the server does not return any data after the headers.)
Figure 3-3. HEAD transaction
POST: Send Data to the Server
The POST method allows the client to specify data to be sent to some data-
handling program that the server can access. It can be used for many
applications. For example, POST could be used to provide input for:
CGI programs
Gateways to network services, like an NNTP server
Command-line interface programs
Annotation of documents on the server
Database operations
In practice, POST is used with CGI programs that happen to interface with
other resources like network services and command line programs. In the
future, POST may be directly interfaced with a wider variety of server
resources.
In a POST request, the data sent to the server is in the entity-body of the
client's request. After the server processes the POST request and headers, it
may pass the entity-body to another program (specified by the URL) for
processing. In some cases, a server's custom Application Programming
Interface (API) may handle the data, instead of a program external to the
server.
POST requests should be accompanied by a Content-type header,
describing the format of the client's entity-body. The most commonly used
format with POST is the URL-encoding scheme used for CGI applications.
It allows form data to be translated into a list of variables and values.
Browsers that support forms send the data in URL-encoded format. For
example, given the HTML form of:
<title>Create New Account</title>
<center><hr><h1>Account Creation
Form</h2><hr></center>
<form method="post" action="/cgi-bin/create.pl">
Không có nhận xét nào:
Đăng nhận xét