wiley http essentials protocols for secure scaleable web sites phần 2 docx

33 222 0
wiley http essentials protocols for secure scaleable web sites phần 2 docx

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

HTTP Operation 23 page the user has identified a local file. By clicking on the Upload button, the user asks the browser to send a PUT re- quest to the server. 2.2.4 File Deletion – DELETE With GET and PUT operations, http becomes a serviceable protocol for simple file transfers. The DELETE operation completes this function by giving clients a way to delete ob- jects from servers. The message exchange contains no sur- prises. As figure 2. 13 shows, the client sends a DELETE message along with the uri of the object the server should remove. The server responds with a status code and, option- ally, more data for the client. ᮤ Figure 2.12 The PUT request may be used to upload a file to a server. In this example the user wants to store the indicated file on the server. 24 HTTP Essentials 2.3 Behind the Scenes The basic http operations generally occur as a direct result of end-user actions. Those four operations are not the only ones the protocol defines, however. Three additional opera- tions, OPTIONS, HEAD, and TRACE, frequently take place be- hind the scenes. Clients use them to communicate with servers not so much to perform user actions but to prepare for or diagnose problems with the basic operations. Although this section does not discuss it further, the http specification also reserves the name for another operation, CONNECT. The standard does not define how CONNECT works, except to indicate that it is intended to support tunneling. (See section 2.4.3.) Future extensions to http may define CONNECT in more detail. 2.3.1 Capabilities – OPTIONS Clients can use an OPTIONS message to discover what capa- bilities a server supports. The exchange is the standard re- quest and response, as figure 2. 14 illustrates. If the client includes a uri, the server responds with the options relevant to that object. If the client sends an asterisk ( * ) as the uri, the server returns the general options that apply to all objects it maintains. A client might use the OPTIONS message to determine the version of http that the server supports or, in the case of a specific uri, which encoding methods the server can provide for the object. Such information would let the client adjust Client Server 1 DELETE URI 2 200 OK + Data Figure 2.13 ᮣ T he DELETE operation lets a client remove an object from a server. The URI identifies the object to delete. HTTP Operation 25 how it interacts with the server or how it actually requests a specific object. 2.3.2 Status – HEAD The HEAD operation is just like a GET operation, except that the server does not return the actual object requested. As figure 2. 15 shows, the server returns a status code but no data. ( HEAD is short for “header,” as the server returns only message headers in response.) Clients can use a HEAD message when they want to verify that an object exists, but they don’t need to actually retrieve the object. Programs that verify links in Web pages, for example, can use the HEAD message to ensure that a link refers to a valid object without consuming the network bandwidth and server resources that a full retrieval would require. Cache servers can also use the HEAD operation; it gives them a way to see if an object has changed without actually retrieving the full object. 2.3.3 Path – TRACE The TRACE message gives clients a way to check the network path to a server. When a server receives a TRACE, it responds Client Server 1 OPTIONS URI 2 200 OK + Options Client Server 1 HEAD URI 2200 OK ᮤ Figure 2.15 The HEAD request mimics a GET operation, except that the server does not actually return the requested object, only HTTP headers. ᮤ Figure 2.14 Clients can use an OPTIONS request to ask about a particular object or about the server itself. The server returns the options data in its response. 26 HTTP Essentials simply by copying the TRACE message itself into the data for the response. Figure 2. 16 shows the simplest case. TRACE messages are more useful when multiple servers are involved in responding to a request. An intermediate server, for example, may accept requests from clients but turn around and forward those requests onto additional servers. (Proxies and cache servers, described in the next section, are examples of such intermediate servers.) When an interme- diate server is involved, TRACE works as in figure 2.17. The intermediate server modifies the request by inserting a Via option in the message. This Via option is part of the message that arrives at the destination server, and it is copied into the data of the server’s response. When the client receives the response, it can see the Via option in the data and identify any intermediate servers in the path. Section 3.2.34 describes this process in more detail. 2.4 Cooperating Servers With the exception of the TRACE message, this chapter has so far focused on the communication between a single client Client Server 1 TRACE 2 200 OK + Message Client 1 TRACE 4 200 OK + Message Ultimate Server 2 TRACE + Via 3 200 OK + Message Intermediate Server Figure 2.16 ᮣ Servers respond to TRACE requests by echoing the request in their reply. Figure 2.17 ᮣ T he TRACE request lets clients discover the path their messages follow through a network o f intermediate servers. HTTP Operation 27 and a single server. The http protocol defines more complex interactions, however, that frequently involve multiple servers cooperating on a client’s behalf. In this section, we’ll look at the different ways that multiple servers may be involved in a communication exchange. 2.4.1 Virtual Hosts Of all the enhancements that http version 1.1 adds to ver- sion 1.0, one of the smallest is direct support for virtual hosts. But although the protocol change is small, this feature is a major benefit for the World Wide Web. Virtual host support addresses a key element of the Web’s architecture that the designers of version 1.0 did not anticipate—Web hosting providers. The popularity of the Internet has created a tremendous de- mand for Web sites, as organizations ranging from corpora- tions to individuals (and even pets!) establish a presence on the Web. In many cases, though, it is impractical or ineffi- cient for the organization itself to own and operate the serv- ers and network infrastructure a Web site requires. To meet this demand, traditional Internet Service Providers, tele- communications carriers, and specialized service providers can host Web sites on behalf of other organizations. A sig- nificant majority of sites on the Internet are modest and re- quire little resources from the systems on which they run. Because they don’t require a dedicated server, for example, most Web hosting providers actually run many separate Web sites on a single server, as figure 2. 18 illustrates. The problem facing a Web server hosting multiple Web sites is simply stated: When a client requests a Web page, how does the server know which site the client is attempting to access? Consider a client request for the Web page corre- sponding to http://www.company 1.com/news.html. The cli- ent first resolves the host part, www.company 1.com, to an ip address. Then, as figure 2. 19 shows, it establishes a tcp con- nection and sends the http command GET news.html to 28 HTTP Essentials that address. Note, though, that the Web server does not participate in the dns resolution, so it doesn’t know which host the client intends to contact. The Web server has no way of knowing whether “news.html” refers to com- pany 1.com or company2.com. Prior to http 1.1, Web hosting providers had only two ways to solve this problem. They could require the Web sites to use unique uris for all their pages. So if company 1.com had a page named “news.html” on its site, company2.com could not use that same name within its pages. In practice, Web host- ing providers implemented this solution by requiring a site identifier in all path names. For example, instead of the straightforward uri “http://www.company 1.com/news.html,” the company 1.com Web site might use the more complicated www.company1.com Internet Web Browser Physical Web Server www.company2.com Domain Name System 1 Query www.company1.com 2 IP Address 3 GET /news.html www.company1.com Internet Web Browser Physical Web Server www.company2.com Virtual Hosts Figure 2.19 ᮣ Virtual hosts can make it difficult for the Web server to determine which Web site the client is trying to access. In this case the physical Web server has no idea which Web address the client requested because it did not participate in the DNS exchange that mapped the host name to its IP address. Figure 2.18 ᮣ Virtual hosting lets many Web addresses share the same Web server. T his configuration is typical in ISPs that provide Web hosting for small businesses and individuals. HTTP Operation 29 “http://www.company1.com/company1.com/news.html.” As an alternative, Web hosting providers could assign separate ip addresses to each site on their servers. The servers then determine which site a client has requested by examining the ip address to which the client connects. Servers end up with multiple ip addresses, and ip addresses are scarce resources. With version 1.1, http addresses the problem of virtual hosts with a simple addition to the client’s request. That addition is the Host header, in which the client must place the host name of the site it is requesting. As figure 2.20 shows, the server can easily determine the site to which a request ap- plies, and it can return the appropriate resource. 2.4.2 Redirection While virtual host support allows a single server to support multiple Web sites easily, redirection offers a way to support a single site to use multiple servers. Redirection lets a server redirect a client to another uri for an object. Figure 2.2 1 shows the process. First the client requests an object from the first Web server. Instead of returning the requested ob- ject, however, the server replies with a 301 Moved status code. The response also indicates a new uri for the object. The client recognizes this uri and, in step 3, reissues the re- quest. This time the GET succeeds, and the second server re- turns the actual object. www.company1.com Internet Web Browser Physical Web Server www.company2.com GET /news.html Host: www.company1.com ᮤ Figure 2.20 The Host feature in HTTP version 1.1 lets clients explicitly identify the Web site they are accessing, so the virtual hosting Web server can return the right content. 30 HTTP Essentials Redirection is essential to the very dynamic Web environ- ment. It provides a convenient way to support revisions within a Web site, relocation of content, and even the change of a corporate identity. Note that the redirection does not have to specify a different host. Frequently, in fact, redirection is used to inform the client of a new path for the resource on the same host. Note also that there are other techniques for accomplishing the same effect. The server can, for example, answer the original request by providing a JavaScript object that automatically directs the client to a new location. 2.4.3 Proxies, Gateways, and Tunnels Another way that http servers can cooperate with each other is by acting as proxies, gateways, or tunnels. In each of these roles, the server that the client first contacts relays the request to a new server and then relays the second server’s response back to the client. Figure 2.22 shows a proxy server in operation. In the figure, the client first sends its http request directly to the proxy server. That server, however, cannot (or chooses not to) respond to the client immediately. Instead, it re- issues the request to a second server, which the figure labels Internet Web Server 3 Web Server GET 4 1 2 200 OK 301 Moved GET Web Browser Figure 2.21 ᮣ A server redirects a client to tell the client that the object it requested is located elsewhere. When, in step 2, the client receives a 301 Moved response, it looks for a new URI in the response message and issues a new GET request for that URI. HTTP Operation 31 the “origin server” (so called because it is the origin of the requested object). In the most basic case, the second GET has a uri identical to that of the first; it’s simply sent to a new server. That server treats the second GET as if it had come from a client and responds with the requested object. The proxy server then has the information the client originally requested, and it returns that object to the client in step 4. Although figure 2.22 shows a single proxy server, http al- lows multiple proxies to participate in satisfying a request. The proxies form a chain as in figure 2.23, handing off the request from one to the other until the requested object can be found. The proxies then pass that object back to the client in the reverse direction. As each server processes a request, it adds its own identity to the Via header in the request. By the time the request arrives at the ultimate final server, the Via Client proxy1 proxy2 origin 1 GET URI 2 GET URI Via: proxy1 3 GET URI Via: proxy1, proxy2 4 200 OK5 200 OK Via: proxy2 6 200 OK Via: proxy2, proxy1 Origin Server Internet 1 Proxy Server GET 4 200 OK 2 GET 3 200 OK Web Browser ᮤ Figure 2.23 Proxy servers create or update the Via option as they relay requests or responses. This option may make it easier to diagnose network problems. ᮤ Figure 2.22 A proxy server positions itself in between clients and servers. It forwards requests on behalf of clients and relays responses from the servers. 32 HTTP Essentials header will have captured the path taken by the request through the server chain. The response follows the same process, with each intermediate system inserting its identity in the Via header. (Note that figure 2.23 shows only a partial Via header; for complete details, see section 3.2.50.) Proxy servers perform several important functions for http communications. The most common is in support of cach- ing, which section 2.4.4 discusses in more detail. Other uses include enforcing policy for an organization. A corporation can direct all its internal clients to use a proxy server to ac- cess the public Internet, allowing the proxy server to filter that Internet access appropriately. Frequently this type of operation is part of a firewall. Proxy servers have also been used to provide anonymity to Web browsers, preventing servers from discovering identifying information about actual clients. If, as is common, a proxy serves multiple origin servers, then the client must usually include the absolute uri in its re- quests. Without the full uri, the proxy may not be able to tell which server the client wishes to contact. Because this behavior is unusual for many clients, and because clients must know to send their requests to proxy servers rather than the ultimate destination, they must often be explicitly con- figured to use a proxy server. Chapter 5 describes some of the mechanisms that system administrators can use to automati- cally configure proxy servers for their users. Gateways and tunnels operate very much like proxy servers; however, there are subtle differences. Gateways act as an endpoint to a server chain, but they still rely on other servers to provide all or part of the requested object. In many cases, gateways use a protocol other than http to access the object. In figure 2.24, for example, the gateway uses the Structured Query Language to retrieve information from a database management system. [...].. .HTTP Operation 33 ᮤ Figure 2. 24 A gateway accepts HTTP requests and translates them to a different format such as SQL The gateway also ensures that any reply is a proper HTTP response 2 SQL query 1 HTTP request Internet DBMS Client Gateway 3 SQL result 4 HTTP response While gateways act as a definite endpoint to a server chain, tunnels are exactly the opposite As figure 2. 25 indicates,... rfc 27 77 The process begins when a proxy inserts a Meter header into a request message as it forwards the message on (See section 3 .2. 35 for details of this header.) Steps 2 and 3 of figure 2. 28 show this process By inserting the header here, the proxy 1 GET URI Client 1 Proxy A 6 20 0 OK Figure 2. 28 ᮣ Proxies that support metering insert the Meter header in requests passing through them Servers ask for. .. and can significantly improve their performance There are some disadvantages, ᮤ Figure 2. 27 When a new client asks for the same object, the cache server returns its local copy instead of sending another request all the way to the origin server This speeds up the response, and it saves bandwidth for the Internet connection 36 HTTP Essentials though For some Web sites, having a cache deliver pages to... 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 Web Site 2 Figure 2. 32 ᮣ A... from the origin server Figures 2. 26 and 2. 27 show the process The first figure shows standard proxy operation The key to a cache server’s operation is that it remembers the requested object, generally by saving a copy on its local disk or in its memory Figure 2. 27 shows the payoff for the cache server In this figure, a new client requests the same object as in figure 2. 26 This time, however, the cache... user that has not been authorized The mechanism that http defines for state maintenance is 1 HTTP Request Client Figure 2. 30 ᮣ Servers can return state management cookies in their responses Clients, if they wish, include those cookies in subsequent requests to the same server HTTP Response 2 + Cookie 3 HTTP Request + Cookie HTTP Response 4 Server HTTP Operation known as a cookie A server creates cookies... performance They do that by remembering the objects requested by clients and, if the 1 GET Secure Client Tunnel 2 200 OK Server ᮤ Figure 2. 25 A tunnel allows a client to communicate directly with a distant server In this example the tunnel creates a secure path for the client’s request and the server’s response 34 HTTP Essentials same object is requested again (either by the same client or a different client),... original request.) Secure The cookie may be returned with insecure requests 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... linefeed The HTTP specifications follow the same convention as Windows; they use the symbol CRLF to represent the two-character sequence HTTP Essentials 3.1 The Structure of HTTP Messages As we saw in the previous chapter, http is a client/server protocol; clients issues requests, and servers respond to those requests The http message structure mirrors that division There is one format for http requests... request from an http 1.0 client, for example, may still indicate HTTP/ 1.1 in its Status-Line That server, however, must be careful to include only http 1.0 options in its response Otherwise it may be sending the client information that the client cannot understand The blank line here marks the end of message headers; the message body follows ੬ HTTP/ 1.1 20 0 OK Date: Sun, 08 Oct 20 00 18:46: 12 GMT Server: . proxy2 origin 1 GET URI 2 GET URI Via: proxy1 3 GET URI Via: proxy1, proxy2 4 20 0 OK5 20 0 OK Via: proxy2 6 20 0 OK Via: proxy2, proxy1 Origin Server Internet 1 Proxy Server GET 4 20 0 OK 2 GET 3 20 0. agency’s server. Web Site 1 Internet Ad Server Web Browser new page with new banner ad Web Site 2 Web Site 1 Internet Ad Server Web Browser Web page with banner ad Figure 2. 32 ᮣ A new Web site may. authorized. The mechanism that http defines for state maintenance is Client Server 1 HTTP Request 4HTTP Response 2 HTTP Response + Cookie 3 HTTP Request + Cookie Figure 2. 30 ᮣ Servers can return

Ngày đăng: 14/08/2014, 11:21

Mục lục

  • 2.4.3 Proxies, Gateways, and Tunnels

  • 2.4.5 Counting and Limiting Page Views

Tài liệu cùng người dùng

Tài liệu liên quan