http和servlet基礎(chǔ)外文翻譯

1、<p><b>　　中文6727字</b></p><p><b>　　翻譯原文</b></p><p>　　作者：Hans Bergsten</p><p>　　HTTP and Servlet Basics</p><p>　　Let's start off this chap

2、ter by defining the term web application. We've 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 throu

3、gh 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 specialize

4、d devices.</p><p>　　The lofty goal here is to access all the information and services you need from any type of device that happens to be in front of you. This means that the same simple client program must

5、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 and a server talk to each other mu

6、st be defined in detail. That's exactly what the HyperText Transport Protocol (HTTP) is for.</p><p>　　The communication model defined by HTTP forms the foundation for all web application design. A basic

7、understanding of HTTP is key to developing applications that fit within 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

8、need to be aware of as a web application developer.</p><p>　　One other item: this book is about using JSP as the server-side technology. JSP is based on the Java servlet technology. Both technologies share a

9、 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.

10、 Hence, we look at servlet fundamentals in the last section of this chapter.</p><p>　　2.1 The HTTP Request/Response Model</p><p>　　HTTP and all extended protocols based on HTTP are based on a ve

11、ry simple communications model. Here's how it works: a client, typically a web browser, sends a request for a resource to a server, and the server sends back a response corresponding to the resource (or a response wi

12、th an error message if it can't 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 dynamic

13、ally.</p><p>　　This simple model implies three important facts you need to be aware of:</p><p>　　HTTP is a stateless protocol. This means that the server doesn't keep any information about t

14、he client after it sends its response, and therefore it can't recognize that multiple requests from the same client may be related.</p><p>　　Web applications can't easily provide the kind of immediat

15、e 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. Perfo

16、rming a request/response exchange when a user selects an item in a list box or fills out a form element is usually too taxing on the bandwidth available to most Internet users.</p><p>　　There's nothing i

17、n the protocol that tells the server how a request is made; consequently, the server can't distinguish between various methods of triggering the request on the client. For example, HTTP doesn't allow a web server

18、 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 browser's Back button. In addition, HTTP doesn&#

19、39;t contain any means for the server to invoke client spec</p><p>　　Over the years, people have developed various tricks to overcome the first problem; HTTP's stateless nature. The other two problems—no

20、 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 bro

21、wser), such as JavaScript or a Java applet. </p><p>　　2.1.1 Requests in Detail</p><p>　　Let's take a closer look at requests. A user sends a request to the server by clicking a link on a web

22、 page, submitting a form, or typing in a web page address in the browser's address field. To send a request, the browser needs to know which server to talk to and which resource to ask for. This information is specif

23、ied by an HTTP Uniform Resource Locator (URL):</p><p>　　http://www.gefionsoftware.com/index.html</p><p>　　The first part of the URL shown specifies that the request is made using the HTTP protoc

24、ol. This is followed by the name of the server, in this case www.gefionsoftware.com. The web server waits for requests to come in on a specific TCP/IP port. Port number 80 is the standard port for HTTP requests. If the w

25、eb server uses another port, the URL must specify the port number in addition to the server name. For example:</p><p>　　http://www.gefionsoftware.com:8080/index.html</p><p>　　This request is sen

26、t to a server that uses port 8080 instead of 80. The last part of the URL, /index.html, identifies the resource that the client is requesting.</p><p>　　A URL is actually a specialization of a Uniform Resourc

27、e 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 URI is a Uniform Resource Name (URN), whi

28、ch 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

29、diffe</p><p>　　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 li

30、ne, request headers, and possibly a request body.</p><p>　　The request line starts with the request method name, followed by a resource identifier and the protocol version used by the browser:</p><

31、;p>　　GET /index.html HTTP/1.1</p><p>　　The most commonly used request method is named GET. As the name implies, a GET request is used to retrieve a resource from the server. It's the default request m

32、ethod, so if you type a URL in the browser's address field, or click on a link, the request is sent as a GET request to the server.</p><p>　　The request headers provide additional information the server

33、may use to process the request. The message body is included only in some types of requests, like the POST request discussed later.</p><p>　　Here's an example of a valid HTTP request message:</p>

34、<p>　　GET /index.html HTTP/1.1</p><p>　　Host: www.gefionsoftware.com</p><p>　　User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv: 1.0.2)</p><p>　　Accept: image/gif, im

35、age/jpeg, image/pjpeg, image/png, */*</p><p>　　Accept-Language : en</p><p>　　Accept-Charset : iso-8859-1,*,utf-8</p><p>　　The request line specifies the GET method and asks for the

36、resource named /index.html to be returned using the HTTP/1.1 protocol version. The various headers provide additional information.</p><p>　　The Host header tells the server the hostname used in the URL. A se

37、rver may have multiple names, so this information is used to distinguish between multiple virtual web servers sharing the same web server process.</p><p>　　The User-Agent header contains information about th

38、e type of browser making the request. The server can use this to send different types of responses to different types of browsers. For instance, if the server knows whether Internet Explorer or Netscape Navigator is used

39、, it can send a response that takes advantage of each browser's unique features. It can also tell if a client other than an HTML browser is used, such as a Wireless Markup Language (WML) browser on a cell phone or a

40、PDA device, a</p><p>　　The Accept headers provide information about the languages and file formats the browser accepts. These headers can be used to adjust the response to the capabilities of the browser and

41、 the user's preferences, such as use a supported image format and the preferred language. These are just a few of the headers that can be included in a request message. </p><p>　　The resource identifier

42、(URI) doesn't necessarily correspond to a static file on the server. It can identify an executable program, a record in a database, or pretty much anything the web server knows about. That's why the generic term

43、resource is used. In fact, there's no way to tell if the /index.html URI corresponds to a file or something else; it's just a name that means something to the server. The web server is configured to map these uni

44、que names to the real resources.</p><p>　　2.1.2 Responses in Detail</p><p>　　When the web server receives the request, it looks at the URI and decides, based on configuration information, how to

45、 handle it. It may handle it internally by simply reading an HTML file from the filesystem, or it can forward the request to some component that is responsible for the resource corresponding to the URI. This can be a pro

46、gram that uses database information, for instance, to dynamically generate an appropriate response. To the browser it makes no difference how the request is handle</p><p>　　The response message looks similar

47、 to the request message. It consists of three things: a status line, response headers, and an optional response body. Here's an example:</p><p>　　HTTP/1.1 200 OK</p><p>　　Last-Modified: Mon,

48、 20 Dec 2002 23:26:42 GMT</p><p>　　Date: Tue, 11 Jan 2003 20:52:40 GMT</p><p>　　Status: 200</p><p>　　Content-Type: text/html</p><p>　　Servlet-Engine: Tomcat Web Server/

49、5.0</p><p>　　Content-Length: 59</p><p><b>　　<html></b></p><p><b>　　<body></b></p><p>　　<h1>Hello World!</h1></p>

50、<p><b>　　</body></b></p><p><b>　　</html></b></p><p>　　The status line starts with the name of the protocol, followed by a status code and a short descrip

51、tion of the status code. Here the status code is 200, meaning the request was executed successfully. The response message has headers just like the request message. In this example, the Last-Modified header gives the dat

52、e and time for when the resource was last modified. The browser can use this information as a timestamp in a local cache; the next time the user asks for this resource, he can ask t</p><p><b>　　<htm

53、l></b></p><p><b>　　<body></b></p><p>　　<h1>Hello World!</h1></p><p><b>　　</body></b></p><p><b>　　</htm

54、l></b></p><p>　　Of course, the body can contain a more complex HTML page or any other type of content. For example, the request may return an HTML page with <img> elements. When the browser re

55、ads the first response and finds the <img> elements, it sends a new request for the resource identified by each element, often in parallel. The server returns one response for each image request, with a Content-Typ

56、e header telling what type of image it is (for instance image/gif) and the body containing the bytes that make</p><p>　　2.1.3 Request Parameters</p><p>　　Besides the URI and headers, a request m

57、essage can contain additional information in the form of parameters. If the URI identifies a server-side program for displaying weather information, for example, request parameters can provide information about the city

58、the user wants to see a forecast for. In an e-commerce application, the URI may identify a program that processes orders, with the user's customer number and the list of items to be purchased transferred as parameter

59、s.</p><p>　　Parameters can be sent in one of two ways: tacked on to the URI in the form of a query string or sent as part of the request message body. This is an example of a URL with a query string:</p&g

60、t;<p>　　http://www.weather.com/forecast?city=Hermosa+Beach&state=CA</p><p>　　The query string starts with a question mark (?) and consists of name/value pairs separated by ampersands (&). Thes

61、e names and values must be URL-encoded, meaning that special characters, such as whitespace, question marks, ampersands, and all other nonalphanumeric characters are encoded so that they don't get confused with chara

62、cters used to separate name/value pairs and other parts of the URI. In this example, the space between Hermosa and Beach is encoded as a plus sign. Other special charact</p><p>　　2.1.4 Request Methods</p&

63、gt;<p>　　As described earlier, GET is the most commonly used request method, intended to retrieve a resource without causing anything else to happen on the server. The POST method is almost as common as GET; it re

64、quests some kind of processing on the server, for instance, updating a database or processing a purchase order.</p><p>　　The way parameters are transferred is one of the most obvious differences between the

65、GET and POST request methods. A GET request always uses a query string to send parameter values, while a POST request always sends them as part of the body (additionally, it can send some parameters as a query string, ju

66、st to make life interesting). If you insert a link in an HTML page using an <a> element, clicking on the link results in a GET request being sent to the server. Since the GET request uses a quer</p><p>

67、;　　<a href="/forecast?city=Hermosa+Beach&state=CA"></p><p>　　Hermosa Beach weather forecast</p><p><b>　　</a></b></p><p>　　When you use a form t

68、o send user input to the server, you can specify whether to use the GET or POST method with the method attribute, as shown here:</p><p>　　<form action="/forecast" method="POST"><

69、/p><p>　　City: <input name="city" type="text"></p><p>　　State: <input name="state" type="text"></p><p><b>　　<p></b>

70、;</p><p>　　<input type="SUBMIT"></p><p><b>　　</form></b></p><p>　　If the user enters "Hermosa Beach" and "CA" in the form field

71、s and clicks on the Submit button, the browser sends a request message like this to the server:</p><p>　　POST /forecast HTTP/1.1</p><p>　　Host: www.gefionsoftware.com</p><p>　　User-

72、Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv: 1.0.2)</p><p>　　Accept: image/gif, image/jpeg, image/pjpeg, image/png, */*</p><p>　　Accept-language: en-US</p><p>　　Accept-ch

73、arset: iso-8859-1,*,utf-8</p><p>　　city=Hermosa+Beach&state=CA</p><p>　　Due to the differences in how parameters are sent by GET and POST requests, as well as the differences in their intend

74、ed purpose, browsers handle the requests in different ways. A GET request, parameters and all, can easily be saved as a bookmark, hardcoded as a link, and the response cached by the browser. Also, the browser knows that

75、no damage is done if it needs to send a GET request again automatically, for instance if the user clicks the Reload button..</p><p>　　A POST request, on the other hand, can't be bookmarked as easily; the

76、 browser would have to save both the URI and the request message body. Since a POST request is intended to perform some possibly irreversible action on the server, the browser must also ask the user if it's okay to s

77、end the request again.</p><p>　　Besides the GET and POST methods, HTTP specifies the following methods:</p><p><b>　　OPTIONS</b></p><p>　　The OPTIONS method is used to fi

78、nd out what options (e.g., methods) a server or a resource offers.</p><p><b>　　HEAD</b></p><p>　　The HEAD method is used to get a response with all headers generated by a GET request

79、 but without the body. It can make sure a link is valid or to see when a resource was last modified.</p><p><b>　　PUT</b></p><p>　　The PUT method is used to store the message body con

80、tent on the server as a resource identified by the URI.</p><p><b>　　DELETE</b></p><p>　　The DELETE method is used to delete the resource identified by the URI.</p><p>&l

81、t;b>　　TRACE</b></p><p>　　The TRACE method is used for testing the communication between the client and the server. The server sends back the request message, exactly as it received it, as the body o

82、f the response.</p><p>　　These methods aren't normally used in a web application.</p><p>　　2.2 Servlets</p><p>　　The JSP specification is based on the Java servlet specification

83、. In fact, JSP pages are often combined with servlets in the same application. In this section, we take a brief look at what a servlet is, and then discuss the concepts shared by servlets and JSP pages. In Chapter 3, we&

84、#39;ll take a closer look at how JSP pages are actually turned into servlets automatically.</p><p>　　If you're already familiar with servlets, this is old news. You can safely skip the rest of this chapt

85、er.</p><p>　　2.2.1 Advantages over Other Server-Side Technologies</p><p>　　In simple terms, a servlet is a piece of code that adds new functionality to a server (typically a web server), just li

86、ke CGI and proprietary server extensions such as NSAPI and ISAPI. But compared to other technologies, servlets have a number of advantages:</p><p>　　Platform and vendor independence. All the major web server

87、s and application servers support servlets, so a servlet-based solution doesn't tie you to one specific vendor. Also, servlets are written in the Java programming language, so they can be used on any operating system

88、 with a Java runtime environment.</p><p>　　Integration Servlets are developed in Java and can therefore take advantage of all other Java technologies, such as JDBC for database access, JNDI for directory acc

89、ess, RMI for remote resource access, etc. Starting with Version 2.2, the servlet specification is part of the Java 2 Enterprise Edition (J2EE), making servlets an important ingredient of any large-scale enterprise applic

90、ation, with formalized relationships to other server-side technologies such as Enterprise JavaBeans.</p><p>　　Efficiency Servlets execute in a process that is running until the servlet-based application is s

91、hut down. Each servlet request is executed as a separate thread in this permanent process. This is far more efficient that the CGI model, where a new process is created for each request. First of all (and most obvious),

92、a servlet doesn't have the overhead of creating the process and loading the CGI script and possibly its interpreter. But another timesaver is that servlets can also access resources t</p><p>　　Scalabilit

93、y</p><p>　　By virtue of being written in Java and the broad support for servlets, a servlet-based application is extremely scalable. You can develop and test the application on a Windows PC using the standal

94、one servlet reference implementation, and deploy it on anything from a more powerful server running Linux and Apache to a cluster of high-end servers with an application server that supports loadbalancing and failover.&l

95、t;/p><p>　　Robustness and security Java is a strongly typed programming language. This means that you catch a lot of mistakes in the compilation phase that you would only catch during runtime if you used a scri

96、pt language such as Perl. Java's error handling is also much more robust than C/C++, where an error such as division by zero typically brings down the whole server.</p><p>　　In addition, servlets use spe

97、cialized interfaces to server resources that aren't vulnerable to the traditional security attacks. For instance, a CGI Perl script typically uses shell command strings composed of data received from the client to as

98、k the server to do things such as send email. People with nothing better to do love to find ways to send data that will cause the server to crash, remove all files on the hard disk, or plant a virus or a backdoor when th

99、e server executes the command. Whil</p><p>　　2.2.2 Servlet Containers</p><p>　　A servlet container is the connection between a web server and the servlets. It provides the runtime environment fo

100、r all the servlets on the server as defined by the servlet specification, and is responsible for loading and invoking those servlets when the time is right. The container typically loads a servlet class when it receives

101、the first request for the servlet, gives it a chance to initialize itself, and then asks it to process the request. Subsequent requests use the same, initialized ser</p><p>　　There are many different types o

102、f servlet containers. Some containers are called add-ons, or plug-ins, and are used to add servlet support to web servers without native servlet support (such as Apache and IIS). They can run in the same operating-system

103、 process as the web server or in a separate process. Other containers are standalone servers. A standalone server includes web server functionality to provide full support for HTTP in addition to the servlet runtime envi