browser will typically ask the user to enter relevant authorization
information. After receiving the information from the user, the browser
retransmits the request with additional headers that describe the
authorization information.
DELETE: Remove URL
Since PUT creates new URLs on the server, it seems appropriate to have a
mechanism to delete URLs as well. The DELETE method works as you
would think it would.
A client request might read:
DELETE /images/logo22.gif HTTP/1.1
The server responds with a success code upon success:
HTTP/1.0 200 OK
Date: Fri, 04 Oct 1996 14:31:51 GMT
Server: HypotheticalPublish/1.0
Content-type: text/html
Content-length: 21
<h1>URL deleted.</h2>
Needless to say, any server that supports the DELETE method is likely to
request authorization before carrying through with the request.
TRACE: View the Client's Message Through the Request Chain
The TRACE method allows a programmer to see how the client's message is
modified as it passes through a series of proxy servers. The recipient of a
TRACE method echoes the HTTP request headers back to the client. When
the TRACE method is used with the Max-Forwards and Via headers, a
client can determine the chain of intermediate proxy servers between the
original client and web server. The Max-Forwards request header
specifies the number of intermediate proxy servers allowed to pass the
request. Each proxy server decrements the Max-Forwards value and
appends its HTTP version number and hostname to the Via header. A proxy
server that receives a Max-Forwards value of 0 returns the client's HTTP
headers as an entity-body with the Content-type of message/http. This
feature resembles traceroute, a UNIX program used to identify routers
between two machines in an IP-based network. HTTP clients do not send an
entity-body when issuing a TRACE request.
Figure 3-7 shows the progress of a TRACE request. After the client makes
the request, the first proxy server receives the request, decrements the Max-
Forwards value by one, adds itself to a Via header, and forwards it to the
second proxy server. The second proxy server receives the request, adds
itself to the Via header, and sends the request back, since Max-Forwards
is now 0 (zero).
OPTIONS: Request Other Options Available for the URL
Figure 3-7. A TRACE request
When a client request contains the OPTIONS method, it requests a list of
options for a particular resource on the server. The client can specify a URL
for the OPTIONS method, or an asterisk (*) to refer to the entire server. The
server then responds with a list of request methods or other options that are
valid for the requested resource, using the Allow header for an individual
resource, or the Public header for the entire server. Figure 3-8 shows an
example of the OPTIONS method in action.
Figure 3-8. An OPTIONS request
Versions of HTTP
On the same line where the client declares its method, it also declares the
URL and the version of HTTP that it conforms to. We've already discussed
the available request methods, and we assume that you're already familiar
with the URL. But what about the HTTP version number? For example:
GET /products/toothpaste/index.html HTTP/1.0
In this example, the client uses HTTP version 1.0.
In the server's response, the server also declares the HTTP version:
HTTP/1.0 200 OK
By specifying the version number in both the client request and server
response, the client and server can communicate on a common denominator,
or in the worst case scenario, recognize that the transaction is not possible
due to version conflicts. (For example, an HTTP/1.0 client might have a
problem communicating with an HTTP/0.9 server.) If a server is capable of
understanding a version of HTTP higher than 1.0, it should still be able to
reply with a format that HTTP/1.0 clients can understand. Likewise, clients
that understand a superset of a server's HTTP should send requests
compliant with the server's version of HTTP.
While there are similarities among the different versions of HTTP, there are
many differences, both subtle and glaring. Much of this discussion may not
make sense to you if you aren't already familiar with HTTP headers (which
are discussed at the end of this chapter). Still, let's go over some of the
highlights.
HTTP 0.9
Version 0.9 is the simplest instance of the HTTP protocol. Under HTTP 0.9,
there's only one way a client can request something, and only one way a
server responds. The web client connects to a server at port 80 and specifies
a method and document path, as follows:
GET /hello.html
The server then returns the entity-body for /hello.html and closes the TCP
connection. If the document doesn't exist, the server just sends nothing, and
the web browser will just display . . . nothing. There is no way for the server
to indicate whether the document is empty or whether it doesn't exist at all.
HTTP 0.9 includes no headers, version numbers, nor any opportunity for the
server to include any information other than the requested entity-body itself.
You can't get much simpler than this.
Since there are no headers, HTTP 0.9 doesn't have any notion of media
types, so there's no need for the client or server to communicate document
preferences or properties. Due to the lack of media types, the HTTP 0.9
world was completely text-based. HTTP 1.0 addressed this limitation with
the addition of media types.
In practice, there is no longer any HTTP 0.9 software currently in use. For
compatibility reasons, however, web servers using newer versions of HTTP
need to honor requests from HTTP 0.9 clients.
HTTP 1.0
As an upgrade to HTTP 0.9, HTTP 1.0 introduced media types, additional
methods, caching mechanisms, authentication, and persistent connections.
By introducing headers, HTTP 1.0 made it possible for clients and servers to
exchange "metainformation" about the document or about the software
itself. For example, a client could now specify what media it could handle
with the Accept header and a server could now declare its entity-body's
media type with the Content-type header. This allowed the client to
know what kind of data it was receiving and deal with it accordingly. With
the introduction of media types, graphics could be embedded into text
documents.
HTTP 1.0 also introduced simple mechanisms to allow caching of server
documents. With the Last-modified and If-Modified-Since
headers, a client could avoid the retransmission of cached documents that
didn't change on the server. This also allowed proxy servers to cache
documents, further relieving servers from the burden of transmitting data
when the data is cached.
With the Authorization and WWW-Authenticate headers, server
documents could be selectively denied to the general public and accessed
only by those who knew the correct username and password.
Proxies
Instead of sending a request directly to a server, it is often necessary for a
client to send everything through a proxy. Caching proxies are used to keep
local copies of documents that would normally be very expensive to retrieve
from distant or overloaded web servers. Proxies are often used with
firewalls, to allow clients inside a firewall to communicate beyond it. In this
case, a proxy program runs on a machine that can be accessed by computers
on both the inside and outside of the firewall. Computers on the inside of a
firewall initiate requests with the proxy, and the proxy then communicates to
the outside world and returns the results back to the original computer. This
type of proxy is used because there is no direct path from the original client
computer to the server computer, due to imposed restrictions in the
intermediate network between the two systems.
There is little structural difference between the request that a proxy receives
and the request that the proxy server passes on to the target server. Perhaps
the only important difference is that in the client's request, a full URL must
be specified, instead of a relative URL. Here is a typical client request that a
client would send to a proxy:
GET http://www.ora.com/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 proxy then examines the URL, contacts www.ora.com, forwards the
client's request, and then returns the response from the server to the original
client. When forwarding the request to the web server, the proxy would
convert http://www.ora.com/index.html to /index.html.
HTTP 1.1
HTTP 1.1's highlights include a better implementation of persistent
connections, multihoming, entity tags, byte ranges, and digest
authentication.
"Multihoming" means that a server responds to multiple hostnames, and
serves from different document roots, depending on which hostname was
used. To assist in server multihoming, HTTP 1.1 requires that the client
include a Host header in all transactions.
Entity tags simplify the caching process by representing each server entity
with a unique identifier called an entity tag. The If-match and If-
none-match headers are used to compare two entities for equality or
inequality. In HTTP 1.0, caching is based on an entity's document path and
modification time. Managing the cache becomes difficult when the same
document exists in multiple locations on the server. In HTTP 1.1, the
document would have the same entity tag at each location. When the
document changes, its entity tag also changes. In addition to entity tags,
HTTP 1.1 includes the Cache-control header for clients and servers to
specify caching behavior.
Byte ranges make it possible for HTTP 1.1 clients to retrieve only part of an
entity from a server using the Range header. This is particularly useful
when the client already has part of the entity and wishes to retrieve the
remaining portion of the entity. So when a user interrupts a browser and the
transfer of an embedded image is interrupted, a subsequent retrieval of the
image starts where the previous transfer left off. Byte ranges also allow the
client to selectively read an index of a document and jump to portions of the
document without retrieving the entire document. In addition to these
features, byte ranges also make it possible to have streaming multimedia,
which are video or audio clips that the client reads selectively, in small
increments.
In addition to HTTP 1.0's authentication mechanism, HTTP 1.1 includes
digest authentication. Instead of sending the username and password in the
clear, the client computes a checksum of the username, password, document
location, and a unique number given by the server. If a checksum is sent, the
username and password are not communicated between the client and server.
Since each transaction is given a unique number, the checksum varies from
transaction to transaction, and is less likely to be compromised by "playing
back" authorization information captured from a previous transaction.
Persistent connections
One of the most significant differences between HTTP 1.1 and previous
versions of HTTP is that persistent connections have become the default
behavior in HTTP 1.1. In versions previous to HTTP 1.1, the default
behavior for HTTP transactions is for a client to contact a server, send a
request, and receive a response, and then both the client and server
disconnect the TCP connection. If the client needs another resource on the
server, it has to reestablish another TCP connection, request the resource,
and disconnect.
In practice, a client may need many resources on the same server, especially
when many images are embedded within the same HTML page. By
connecting and disconnecting many times, the client wastes time in network
overhead. To remedy this, some HTTP 1.0 clients started to use a
Connection header, although this header never appeared in the official
HTTP 1.0 specification. This header, when used with a keep-alive
value, specifies that the network connection should remain after the initial
transaction, provided that both the client and server use the Connection
header with the value of keep-alive.
Không có nhận xét nào:
Đăng nhận xét