Chương 6. Web, FTP và Intranet Zone
6.2 Hoạt động của HTTP
6.2.3 Cookies and State Maintenance
The http protocol normally operates as if each client request is independent of all others. The server responds to
any request strictly on the merits of that request, without
reference to other requests from the client (or, for that
matter, any other client). This type of operation is known as stateless because the server does not have to keep track of the state of its clients.
Because maintaining state requires server resources (memory, processing power, etc.), stateless operation is usually desirable.
In some applications, however, the server needs to keep some state information about each of its clients. Users that successfully log in to a Web site, for example, shouldn’t have to log in again every time they view a different page on that site. A server can avoid this inconvenience by tracking the state of the client. The first time the client requests a page from the site, the server requires the user to log in. As the user continues to browse the site and make additional http
requests, however, the server remembers the previously successful login and refrains from requesting additional logins.
6.2.3.1 Cookies
State maintenance requires one critical capability: Servers must be able to associate one http request with another.
The server must be able to tell, for example, that the user requesting a new page really is the same user that has already logged in, not a different user that has not been authorized.
The mechanism that http defines for state maintenance is
visits the online broker’s site. The Web page from the first site contains multiple objects. One of those objects is a banner ad that resides on an ad server operated by the ad agency.
The user’s Web browser dutifully requests all the objects that make up the page, including the banner. The fact that the ad resides on a different http server is not a problem. The client simply sends its GET request to the server indicated in the Web page. It is in the response to this GET request that the server inserts its cookie.
Later, the user browses to the sporting goods site. As figure 2.32 illustrates, the Web page for this site also includes a
banner ad, and that ad also resides on the ad agency’s server.
The Web browser dutifully sends a GET request to that server, and, because it is the same server that originally provided the cookie, it includes the cookie in that request. The ad agency now knows which sites the user has visited. Note, however, that the ad agency can track information only for sites with which it has a relationship. If the user visits another Web site that does not have an agreement with the ad agency, that Web site will have no banner ad pointing to the ad agency’s server. Without a banner ad and associated cookie exchange, the agency will remain unaware of the user’s visit to the site.
6.2.3.2 Cookie Attributes
Cookies consist of the series of attributes listed in table 2.1. The server chooses values for the required attributes and, if it
desires, for the optional attributes as well.
6.2.3.3 Accepting Cookies
When a client receives a cookie, it saves the attributes that make up the cookie. In addition, if the server has omitted any of the optional attributes, the client supplies default values.
Table 2.2 lists the default values that clients apply to missing attributes.
Note that a client is never required to accept a cookie. Users, for example, may configure their Web browsers to accept cookies or not, as figure 2.33 shows. An http server, therefore, cannot count on a cookie being accepted, even if the
cookie is appropriately formatted.
Even if a user is willing to accept cookies, the http specification requires that the client reject cookies under certain
circumstances. Rejected cookies are simply ignored by the client and, therefore, are never included in subsequent requests.
Table 2.3 lists the conditions under which a client
must reject a server’s cookie. Note that the client considers these conditions after it has applied any default attribute values
as outlined in table 2.2.
Finally, when a client accepts a cookie, the new cookie supercedes any previously accepted cookies that have the same
NAME, Domain, and Path attribute values.
6.2.3.4 Returning Cookies
Once a client has accepted a cookie and supplied appropriate default values, it determines when to return the cookie to a server in subsequent http requests. Table 2.4 outlines the rules under which a client includes a cookie in a request.
Note that more than one cookie may meet the table’s criteria, in which case the client should include multiple cookies in
its request.
Table 2.4 Rules for Returning Cookies
Conditions Under Which a Client Returns a Cookie
• The domain name for the new request must belong to the domain
specified by the cookie’s Domain attribute.
• The port for the new request must be included in the list of ports of the cookie’s Port attribute, unless the Port attribute was absent from the cookie (indicating all ports).
• The path for the new request must match the cookie’s Path attribute, or represent a child of the Path attribute.
• The cookie must not have expired, as per its Max-Age attribute.
When the client returns a cookie to a server, it includes the
Domain, Path, and Port attributes if those attributes were
present in the original cookie. It does not include those attributes if they were absent from the original cookie.
6.3 Hoạt động của FTP
From a networking perspective, the two main types of FTP are active and passive. In active FTP, the FTP server initiates a data transfer connection back to the client. For passive FTP, the connection is initiated from the FTP client. These are illustrated in Figure 15-1.
From a user management perspective there are also two types of FTP: regular FTP in which files are transferred using the username and password of a regular user FTP server, and anonymous FTP in which general access is provided to the FTP server using a well known universal login method.