1、 中文 6727 字 翻译原文 作者： Hans Bergsten HTTP and Servlet Basics Lets start off this chapter by defining the term web application. Weve all seen regular client-side applications, but what exactly is a web application? Loosely, it can be defined as an application running on a server a user accesses through
2、a thin, general-purpose client. Today, the most common client is a web browser on a PC or workstation, but other kinds of clients are rapidly joining the party, such as wireless PDAs, cell phones, and other specialized devices. The lofty goal here is to access all the information and services you ne
3、ed from any type of device that happens to be in front of you. This means that the same simple client program must be able to talk to many different server applications, and the applications must be able to work with many different types of clients. To satisfy this need, the protocol of how a client
4、 and a server talk to each other must be defined in detail. Thats exactly what the HyperText Transport Protocol (HTTP) is for. The communication model defined by HTTP forms the foundation for all web application design. A basic understanding of HTTP is key to developing applications that fit within
5、the constraints of the protocol, no matter which server-side technology you use. In this chapter, we look at the most important details of HTTP you need to be aware of as a web application developer. One other item: this book is about using JSP as the server-side technology. JSP is based on the Java
6、 servlet technology. Both technologies share a lot of terminology and concepts, so knowing a bit about servlets will help you even when you develop pure JSP applications. To really understand and use the full power of JSP, you need to know a fair bit about servlets. Hence, we look at servlet fundame
7、ntals in the last section of this chapter. 2.1 The HTTP Request/Response Model HTTP and all extended protocols based on HTTP are based on a very simple communications model. Heres how it works: a client, typically a web browser, sends a request for a resource to a server, and the server sends back a
8、 response corresponding to the resource (or a response with an error message if it cant process the request for some reason). A resource can be a number of things, such as a simple HTML file returned verbatim to the browser or a program that generates the response dynamically. This simple model impl
9、ies three important facts you need to be aware of: HTTP is a stateless protocol. This means that the server doesnt keep any information about the client after it sends its response, and therefore it cant recognize that multiple requests from the same client may be related. Web applications cant easi
10、ly provide the kind of immediate feedback typically found in standalone GUI applications such as word processors or traditional client/server applications. Every interaction between the client and the server requires a request/response exchange. Performing a request/response exchange when a user sel
11、ects an item in a list box or fills out a form element is usually too taxing on the bandwidth available to most Internet users. Theres nothing in the protocol that tells the server how a request is made； consequently, the server cant distinguish between various methods of triggering the request on t
12、he client. For example, HTTP doesnt allow a web server to differentiate between an explicit request caused by clicking a link or submitting a form and an implicit request caused by resizing the browser window or using the browsers Back button. In addition, HTTP doesnt contain any means for the serve
13、r to invoke client specific functions, such as going back in the browser history list or sending the response to a certain frame. Also, the server cant detect when the user closes the browser. Over the years, people have developed various tricks to overcome the first problem； HTTPs stateless nature.
14、 The other two problems no immediate feedback and no details about how the request is made are harder to deal with, but some amount of interactivity can be achieved by generating a response that includes client-side code (code executed by the browser), such as JavaScript or a Java applet. 2.1.1 Requ
15、ests in Detail Lets take a closer look at requests. A user sends a request to the server by clicking a link on a web page, submitting a form, or typing in a web page address in the browsers address field. To send a request, the browser needs to know which server to talk to and which resource to ask
16、for. This information is specified by an HTTP Uniform Resource Locator (URL): http:/ The first part of the URL shown specifies that the request is made using the HTTP protocol. This is followed by the name of the server, in this case . The web server waits for requests to come in on a specific TCP/I
17、P port. Port number 80 is the standard port for HTTP requests. If the web server uses another port, the URL must specify the port number in addition to the server name. For example: http:/:8080/index.html This request is sent to a server that uses port 8080 instead of 80. The last part of the URL, /
18、index.html, identifies the resource that the client is requesting. A URL is actually a specialization of a Uniform Resource Identifier (URI, defined in the RFC-2396 specification). A URL identifies a resource partly by its location, for instance the server that contains the resource. Another type of
19、 URI is a Uniform Resource Name (URN), which is a globally unique identifier that is valid no matter where the resource is located. HTTP deals only with the URL variety. The terms URI and URL are often used interchangeable, and unfortunately, they have slightly different definitions in different spe
20、cifications. Im trying to use the terms as defined by the HTTP/1.1 specification (RFC-2616), which is pretty close to how they are also used in the servlet and JSP specifications. Hence, I use the term URL only when the URI must start with http (or https, for HTTP over an encrypted connection) follo
21、wed by a server name and possibly a port number, as in the previous examples. I use URI as a generic term for any string that identifies a resource, where the location can be deduced from the context and isnt necessarily part of the URI. For example, when the request has been delivered to the server
22、, the location is a given, and only the resource identifier is important. The browser uses the URL information to create the request message it sends to the specified server using the specified protocol. An HTTP request message consists of three things: a request line, request headers, and possibly
23、a request body. The request line starts with the request method name, followed by a resource identifier and the protocol version used by the browser: GET /index.html HTTP/1.1 The most commonly used request method is named GET. As the name implies, a GET request is used to retrieve a resource from th
24、e server. Its the default request method, so if you type a URL in the browsers address field, or click on a link, the request is sent as a GET request to the server. The request headers provide additional information the server may use to process the request. The message body is included only in som
25、e types of requests, like the POST request discussed later. Heres an example of a valid HTTP request message: GET /index.html HTTP/1.1 Host: User-Agent: Mozilla/5.0 (Windows； U； Win 9x 4.90； en-US； rv: 1.0.2) Accept: image/gif, image/jpeg, image/pjpeg, image/png, */* Accept-Language : en Accept-Cha
26、rset : iso-8859-1,*,utf-8 The request line specifies the GET method and asks for the resource named /index.html to be returned using the HTTP/1.1 protocol version. The various headers provide additional information. The Host header tells the server the hostname used in the URL. A server may have multiple names, so this information is used to distinguish between multiple virtual web servers sharing the
