計算機專業(yè)外文翻譯（中英文）---http和servlet的基礎知識

上傳人：奔*** IP屬地：河北更新時間：2024-03-01 格式：docx 頁數(shù)：24 大小：39.00KB 人氣指數(shù)：12 舉報 版權申訴

已閱讀1頁，還剩23頁未讀，繼續(xù)免費閱讀

版權說明：本文檔由用戶提供并上傳，收益歸屬內(nèi)容提供方，若內(nèi)容存在侵權，請進行舉報或認領

文檔簡介

1、　　附錄A 譯文　　HTTP和Servlet的基礎知識　　讓我們從定義Web應用程序這一章開始。我們都看到過一般的客戶端應用軟件，但怎么樣才是一個真正的Web應用程序？然而，它可以被定義為一個用于用戶接入的運行在服務器上的程序，通過一個簡單，一般用途的客戶。今天，最常見的客戶端是一種運行在pc機上的

2、網(wǎng)頁瀏覽器或工作站系統(tǒng)，但其他類型的用戶正在迅速加入，如無線PDA ，手機，和其他專門設備。最崇高目標是從你面前的任何類型的設備上獲得你所要的信息和服務。這意味著同樣的簡單客戶端程序必須能夠與許多不同的服務器應用通話，以及應用程序必須能夠適用于許多不同類型的客戶。為了滿足這一需要，必須制定詳細的客戶端和服務器相互通信的協(xié)義。這正是超文本傳輸協(xié)議（ HTTP ）的目的。通信模型所確定的HTTP形式的基礎，所有的Web應

3、用程序設計。基本了解HTTP的關鍵應用，適合發(fā)展中國家的限制范圍內(nèi)的協(xié)議，無論哪個服務器端技術的使用。在本章中，我們看一下最重要的細節(jié)的HTTP您需要了解作為一個Web應用程序開發(fā)。另外一個項目：這本書是用JSP作為服務器端技術。 JSP技術是基于Java Servlet技術。這兩種技術有著大量的術語和概念，　　Last-Modified: Mon, 20 Dec 2002 23:26:

4、42 GMT　　Date: Tue, 11 Jan 2003 20:52:40 GMT　　Status: 200　　Content-Type: text/html　　Servlet-Engine: Tomcat Web Server/5.0<

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

6、　</body>　　</html>　　狀態(tài)行開頭的名稱協(xié)議，其次是狀態(tài)代碼，并有簡短的描述狀態(tài)代碼。在這里，狀態(tài)代碼是200 ，這意味著被執(zhí)行的請求成功?；貞]件標題就像請求消息。在這個例子中，最后修改標題給出的日期和時間，資源最后修改。該瀏覽器可以使用此信息作為一個時間戳

7、在本地緩存;下一次用戶要求這一資源，他可以向服務器發(fā)送它只要當它被更新，因為這是最后一次要求。內(nèi)容類型標頭講述了什么類型的瀏覽器的反應數(shù)據(jù)和身體包含的內(nèi)容長度標題是多么大。其他標題不言自明。一個空行分隔標題的郵件正文。在這里，內(nèi)容體是一個簡單的HTML網(wǎng)頁：html>　　<body>　　<h

8、1>Hello World!</h1>　　</body>　　</html>　　當然，人體可以包含一個更為復雜的HTML網(wǎng)頁或任何其他類型的內(nèi)容。例如，請求可能會返回一個HTML頁面的img要素。當

9、瀏覽器讀取第一個反應時，并認為是img要素，它就發(fā)出了一個新的要求所確定的資源，往往是在平行。服務器返回一個響應，每幅圖像的要求，與內(nèi)容類型標題告訴什么類型的影像（例如圖片/ gif格式），體內(nèi)含有字節(jié)構成的類型。　　2.1.3請求參數(shù) 除了URI和標題，一個請求消息可以包含更多信息的形式參數(shù)。如果確定了的URI服務器端程序顯示天氣信息，例如，請求參數(shù)可以提供有關城市的用戶希望看到一個

10、預測。電子商務的應用，開放的我們可能會確定一個程序，處理訂單，與用戶的客戶數(shù)量和名單所要采購的物品轉(zhuǎn)移作為參數(shù)。參數(shù)可以發(fā)出兩種方式之一：匯價上的URI形式的查詢字符串或發(fā)出的一部分，請求郵件正文。這是一個例子，一個網(wǎng)址的查詢字串：http://www.weather.com/forecast?city=Hermosa+Beach&state=CA 查詢字符串開始問號（？），由名稱/值對分隔符號（＆

11、）。這些名稱和值必須是URL編碼，也就是說，特殊字符，如空格，問號，符號，以及所有其他nonalphanumeric字符編碼，以便它們不會混淆字符用于分離名稱/值對和其他部分的URI 。在這個例子中，之間的空間荷摩莎和沙灘被編碼為一個加號。其他特殊字符的編碼為相應的十六進制ASCII值，例如，一個問號被編碼為％ 3樓。參數(shù)時，發(fā)送的一部分機構的要求，他們按照同樣的語法; URL編碼名稱　　&l

12、t;a href="/forecast?city=Hermosa+Beach&state=CA">　　Hermosa Beach weather forecast　　</a>　　當您使用的一種形式發(fā)送用戶輸入到服務器，您可以指定是

13、否使用GET或POST方法的方法，屬性，如下所示:　　<form action="/forecast" method="POST">　　City: <input name="city" type="text">

14、　　State: <input name="state" type="text">　　　　<input type="SUBMIT">　　</form&

15、gt;　　如果用戶輸入“赫摩薩海灘”和“加州”的表單字段并點擊提交按鈕，瀏覽器發(fā)送一個請求消息這樣的服務器：POST /forecast HTTP/1.1　　Host: www.gefionsoftware.com　　User-Agent: Mozilla/5.0 (Windows; U;

16、Win 9x 4.90; en-US; rv: 1.0.2)　　Accept: image/gif, image/jpeg, image/pjpeg, image/png, */*　　Accept-language: en-US　　Accept-charset: iso-8859-1,*,utf-8</p&

17、gt;　　city=Hermosa+Beach&state=CA　　由于不同的參數(shù)是如何發(fā)出的GET和POST請求，以及不同的目的，瀏覽器處理的要求以不同的方式。 GET請求，參數(shù)和所有，可以很容易地被保存為書簽，硬編碼為紐帶，和響應緩存的瀏覽器。另外，瀏覽器都知道，沒有損害的是，如果它需要發(fā)出一個GET請求再次自動，例如，如果用戶點擊刷新按鈕。 POST請

18、求，另一方面，不能書簽一樣容易;瀏覽器將節(jié)省的URI和郵件正文的要求。由于POST請求的目的是執(zhí)行一些不可逆轉(zhuǎn)的行動可能在服務器上，瀏覽器還必須要求用戶如果奧凱發(fā)送再次請求除了GET和POST方法，即HTTP指定下列方法：OPTIONSThe期權方法是用來找出選項（例如，方法）一臺服務器或一個資源提供。頭的方法是用來得到回應與所有標題產(chǎn)生的GET請求，但身體。它可以確保一個鏈接是有效的，或看到一個資源的最后修改。P

19、UTThe PUT方法是用來儲存郵件正文內(nèi)容的服務器作為一種資源所確定的URI。DELETEThe Delete方法用于刪除所確定的資源的URI 。 TRACE方法是用于測試的溝通客戶端和服務器。服務器發(fā)回的信息的要求，正是因為它得到它，因為身體的反　　2.2.1優(yōu)于其他服務器端技術　　簡單來說，一個servlet是一塊代碼，增加新功能的服務器

20、（通常是Web服務器），就像CGI和專有服務器擴展，如NSAPI和的ISAPI 。但是，相對于其他技術， servlets有許多優(yōu)點：獨立平臺和供應商的所有主要的Web服務器和應用服務器的支持servlets ，因此一個servlet為基礎的解決方案不配合你一個具體的供應商。另外， servlets是寫在Java編程語言，因此他們可以用來在任何操作系統(tǒng)上運行的Java運行環(huán)境。集成Servlets Java中的開發(fā)，因此可

21、以充分利用所有其他的Java技術，如JDBC的數(shù)據(jù)庫訪問， JNDI的對目錄的訪問， RMI的遠程資源訪問等從版本2.2, 該servlet的規(guī)范是在Java 2企業(yè)版（ J2EE ），使servlets的一個重要組成部分任何大規(guī)模的企業(yè)應用，并正式關系到其他服務器端的技術，如企業(yè)JavaBeans 。效率Servlets執(zhí)行的進程中運行，直到servlet的應用程序被關閉。每個servlet的請求是作為一個單獨的執(zhí)行線程在

22、此永久進程。這是更為有效的的CGI模式，在一個新的進程創(chuàng)建的每　　附錄B 英文文獻　　HTTP and Servlet Basics　　Let's start off this chapter by defining the term web application.

23、 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 through a thin, general-purpose client. Today,

24、 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 loft

25、y 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 be able to talk to many different server

26、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 must be defined in detail. That's exact

27、ly 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 developin

28、g 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 need to be aware of as a web application

29、developer.　　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 lot of terminology and concepts, so know

30、ing 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 fundamentals i

31、n 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. Here'

32、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 with an error message if it can't proce

33、ss 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 m

34、odel implies three important facts you need to be aware of:　　HTTP is a stateless protocol. This means that the server doesn't keep any information about the client after it sends its response, an

35、d therefore it can't recognize that multiple requests from the same client may be related.　　Web applications can't easily provide the kind of immediate feedback typically found in standalone

36、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

37、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.　　There's nothing in the protocol that tells the server how

38、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 to differentiate between an explicit req

39、uest 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't contain any means for the server to

40、invoke client spec　　Over the years, people have developed various tricks to overcome the first problem; HTTP's stateless nature. The other two problems—no immediate feedback and no details about

41、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 apple

42、t. 　　2.1.1 Requests in Detail　　Let's 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

43、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 specified by an HTTP Uniform Resource Locator (

44、URL):　　http://www.gefionsoftware.com/index.html　　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 s

45、erver, 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 web server uses another port, the URL must

46、 specify the port number in addition to the server name. For example:　　http://www.gefionsoftware.com:8080/index.html　　This request is sent to a server that uses port 8080 instead

47、 of 80. The last part of the URL, /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-239

48、6 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), which is a globally unique identifier that i

49、s 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 diffe　　The browser u

50、ses 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 a reque

51、st 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

52、;　　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 method, so if you type a URL in the browse

53、r's 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 messa

54、ge body is included only in some types of requests, like the POST request discussed later.　　Here's an example of a valid HTTP request message:　　GET /index.html HTTP/1.1</p

55、>　　Host: www.gefionsoftware.com　　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, */*<

56、/p>　　Accept-Language : en　　Accept-Charset : iso-8859-1,*,utf-8　　The request line specifies the GET method and asks for the resource named /index.html to be returned

57、 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 inf

58、ormation is used to distinguish between multiple virtual web servers sharing the same web server process.　　The User-Agent header contains information about the type of browser making the request. The

59、 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, it can send a response that takes advan

60、tage 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 PDA device, a　　The A

61、ccept 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 the user's preferences, such as use

62、a supported image format and the preferred language. These are just a few of the headers that can be included in a request message. 　　The resource identifier (URI) doesn't necessarily correspond

63、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 resource is used. In fact, there's no

64、 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 unique names to the real resources.

65、;　　2.1.2 Responses in Detail　　When the web server receives the request, it looks at the URI and decides, based on configuration information, how to handle it. It may handle it internally b

66、y 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 program that uses database information, for

67、instance, to dynamically generate an appropriate response. To the browser it makes no difference how the request is handle　　The response message looks similar to the request message. It consists of t

68、hree things: a status line, response headers, and an optional response body. Here's an example:　　HTTP/1.1 200 OK　　Last-Modified: Mon, 20 Dec 2002 23:26:42 GMT<

69、p>　　Date: Tue, 11 Jan 2003 20:52:40 GMT　　Status: 200　　Content-Type: text/html　　Servlet-Engine: Tomcat Web Server/5.0　　Content-Length:

70、 59　　<html>　　<body>　　<h1>Hello World!</h1>　　</body></b&g

71、t;　　</html>　　The status line starts with the name of the protocol, followed by a status code and a short description of the status code. Here the status

72、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 date and time for when the resource was last

73、 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　　<html><b

74、>　　<body>　　<h1>Hello World!</h1>　　</body>　　</html>　　Of

75、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 reads the first response and finds the <

76、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-Type header telling what type of image it is

77、 (for instance image/gif) and the body containing the bytes that make　　2.1.3 Request Parameters　　Besides the URI and headers, a request message can contain additional information

78、 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 the user wants to see a forecast for. In

79、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 parameters.　　Parameters can b

80、e 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:　　http://www.weather.com/for

81、ecast?city=Hermosa+Beach&state=CA　　The query string starts with a question mark (?) and consists of name/value pairs separated by ampersands (&). These names and values must be URL-encoded, m

82、eaning that special characters, such as whitespace, question marks, ampersands, and all other nonalphanumeric characters are encoded so that they don't get confused with characters used to separate name/value pairs a

83、nd other parts of the URI. In this example, the space between Hermosa and Beach is encoded as a plus sign. Other special charact　　2.1.4 Request Methods　　As described earlier, GET

84、 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 requests some kind of processing on the ser

85、ver, for instance, updating a database or processing a purchase order.　　The way parameters are transferred is one of the most obvious differences between the GET and POST request methods. A GET reque

86、st 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, just to make life interesting). If you inse

87、rt 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　　<a href="/forecast?city=Hermos

88、a+Beach&state=CA">　　Hermosa Beach weather forecast　　</a>　　When you use a form to send user input to the server, you can

89、specify whether to use the GET or POST method with the method attribute, as shown here:　　<form action="/forecast" method="POST">　　City: <input name=&

90、quot;city" type="text">　　State: <input name="state" type="text">　　　　<input type=&q

91、uot;SUBMIT">　　</form>　　If the user enters "Hermosa Beach" and "CA" in the form fields and clicks on the Submit button, the br

92、owser sends a request message like this to the server:　　POST /forecast HTTP/1.1　　Host: www.gefionsoftware.com　　User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.

93、90; en-US; rv: 1.0.2)　　Accept: image/gif, image/jpeg, image/pjpeg, image/png, */*　　Accept-language: en-US　　Accept-charset: iso-8859-1,*,utf-8<

94、p>　　city=Hermosa+Beach&state=CA　　Due to the differences in how parameters are sent by GET and POST requests, as well as the differences in their intended purpose, browsers handle the requests

95、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 no damage is done if it needs to send a G

96、ET request again automatically, for instance if the user clicks the Reload button.　　A POST request, on the other hand, can't be bookmarked as easily; the browser would have to save both the URI a

97、nd 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 send the request again

98、　　Besides the GET and POST methods, HTTP specifies the following methods:　　OPTIONSThe OPTIONS method is used to find out what options (e.g., methods) a server or a resource offers.<p&

99、gt;　　HEADThe HEAD method is used to get a response with all headers generated by a GET request but without the body. It can make sure a link is valid or to see when a resource was last modified.　　PU

100、TThe PUT method is used to store the message body content on the server as a resource identified by the URI.　　DELETEThe DELETE method is used to delete the resource identified by the URI.

101、　　TRACEThe 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 of the response.&

102、lt;p>　　These methods aren't normally used in a web application.　　2.2 Servlets　　The JSP specification is based on the Java servlet specification. In fact, JSP pages are oft

103、en 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'll take a closer look at

104、 how JSP pages are actually turned into servlets automatically.　　If you're already familiar with servlets, this is old news. You can safely skip the rest of this chapter.　　2.

105、2.1 Advantages over Other Server-Side Technologies　　In simple terms, a servlet is a piece of code that adds new functionality to a server (typically a web server), just like CGI and proprietary serve

眾賞文庫> 全部分類> 畢業(yè)設計

溫馨提示

1. 本站所有資源如無特殊說明，都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
2. 本站的文檔不包含任何第三方提供的附件圖紙等，如果需要附件，請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
3. 本站RAR壓縮包中若帶圖紙，網(wǎng)頁內(nèi)容里面會有圖紙預覽，若沒有圖紙預覽就沒有圖紙。
4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
5. 眾賞文庫僅提供信息存儲空間，僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理，對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯，并不能對任何下載內(nèi)容負責。
6. 下載文件中如有侵權或不適當內(nèi)容，請與我們聯(lián)系，我們立即糾正。
7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

計算機專業(yè)外文翻譯（中英文）---http和servlet的基礎知識

文檔簡介

溫馨提示

最新文檔

評論

計算機專業(yè)外文翻譯（中英文）---http和servlet的基礎知識

文檔簡介

溫馨提示

最新文檔

評論

免費下載