Web Client Programming with Perl-Chapter 3: Learning HTTP- P1

Tham khảo tài liệu web client programming with perl-chapter 3: learning http- p1, công nghệ thông tin, quản trị web phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả
Nội dung trích xuất từ tài liệu:
Web Client Programming with Perl-Chapter 3: Learning HTTP- P1 Chapter 3: Learning HTTP- P1In the previous chapter, we went through a few examples of HTTPtransactions and outlined the structure that all HTTP follows. For the mostpart, all web software will use an exchange similar to the HTTP we showedyou in Chapter 2, Demystifying the Browser. But now its time to teach youmore about HTTP. Chapter 2 was like the Spanish for Travelersphrasebook that you got for your trip to Madrid; this chapter is the textbookfor Spanish 101, required reading if you want course credit.HTTP is defined by the HTTP specification, distributed by the World WideWeb Consortium (W3C) at www.w3.org. If you are writing commercial-quality HTTP applications, you should go directly to the spec, since itdefines which features need to be supported for HTTP compliance.However, reading the spec is a tedious and often unpleasant experience, andreaders of this book are assumed to be more casual writers of HTTP clients,so weve pared it down a bit to make HTTP more accessible for the spec-wary. This chapter includes:  Review of the structure of HTTP transactions. This section also serves as a sort of road map to the rest of the chapter.  Discussion of the request methods clients may use. Beyond GET, HEAD, and POST, we also give examples of the PUT, DELETE, TRACE, and OPTIONS methods.  Summary of differences between various versions of HTTP. Clients and servers must declare which version of HTTP they use. For the most part, what youll see is HTTP 1.0, but at least youll know what that means. We also cover HTTP 1.1, the newest version of HTTP to date.  Listing of server response codes, and discussion of the more common codes. These codes are the first indication of what to do with the servers response (if any), so robust client programs should be prepared to intercept them and interpret them properly.  Coverage of HTTP headers for both clients and servers. Headers give clients the opportunity to declare who they are and what they want, and they give servers the chance to tell clients what to expect.This is one of the longest chapters in this book, and no doubt you wont readit all in one sitting. Furthermore, if you use LWP, then you can go pretty farwithout knowing more than a superficial amount of HTTP. But its allinformation you should know, so we recommend that you keep coming backto it. Although a few key phrases will help you get around town, fluencybecomes very useful when you find yourself lost in the outskirts of the city.Structure of an HTTP TransactionAll HTTP transactions follow the same general format, as shown in Figure3-1. Figure 3-1. Structure of HTTP transactionsHTTP is a simple stateless protocol, in which the client makes a request, theserver responds, and the transaction is then finished. The client initiates thetransaction as follows: 1. First, the client contacts the server at a designated port number (by default, 80). Then it sends a document request by specifying an HTTP command (called a method), followed by a document address and an HTTP version number. For example: GET /index.html HTTP/1.0 Here we use the GET method to request the document /index.html using version 1.0 of HTTP. Although the most common request method is the GET method, there is also a handful of other methods that are supported by HTTP, and essentially define the scope and purpose of the transaction. In this chapter, we talk about each of the commonly used client request methods, and show you examples of their use. There are three versions of HTTP: 0.9, 1.0, and 1.1. At this writing, most clients and servers conform to HTTP 1.0. But HTTP 1.1 is on the horizon, and, for reasons of backward compatibility, HTTP 0.9 is still honored. We will discuss each version of HTTP and the major differences between them.2. Next, the client sends optional header information to inform the server of the clients configuration and document preference. All header information is given line by line, each line with a header name and value. For example, a client can send its name and version number, or specify document preferences:[1] User-Agent: Mozilla/1.1N (Macintosh; I; 68K) Accept: */* Accept: image/gif Accept: image/x-xbitmap Accept: image/jpeg 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 clients 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 ...