【正文】
ur sales tracking system with the context path /sales. This allows one servlet container to distinguish between the different applications it serves and dispatch requests like /sales/report?month=Jan to the sales tracking application and /hr/emplist to the human resources application. The remaining URI path is then used within the selected context to decide how to process the request by paring it to pathmapping rules defined by the application39。s deployment descriptor. Rules can be defined to send all requests starting with /report to one servlet and requests starting with /forecast to another. Another type of mapping rule can say that one servlet handles all requests with paths ending with a specific file extension, such as .jsp. shows how the different parts of the URI paths are used to direct the request processing to the right resource through the container and context. Each context is selfcontained and doesn39。t know anything about other applications running in the same container. References between the servlets and JSP pages in the application are monly relative to the context path and, therefore, are referred to as contextrelative paths. By using contextrelative paths within the application, a web application can be deployed using any context path. Finally, a context can hold objects shared by all ponents of the application, such as database connections and other shared resources needed by multiple servlets and JSP pages. 中文翻譯稿 應(yīng)用技術(shù)學(xué)院 06 計算機 ( 0616403028)徐鵬程 2020 年 4 月 HTTP 和 Servlet 的基礎(chǔ)知識 讓我們從定義 Web 應(yīng)用程序這一章開始。我們都看到過一般的客戶端應(yīng)用軟件,但怎么樣才是一個真正的 Web 應(yīng)用程序?然而,它可以被定義為一個用于用戶接入的運行在服務(wù)器上的程序,通過一個簡單,一般用途的客戶。今天,最常見的客戶端是一種運行在 pc機上的網(wǎng)頁瀏覽器或工作站系統(tǒng),但其他類型的用戶正在迅速加入,如無線 PDA ,手機,和其他專門設(shè)備。 最崇高目標(biāo)是從你面前的任何類型的設(shè)備上獲得你所要的 信息和服務(wù)。這意味著同樣的簡單客戶端程序必須能夠與許多不同的服務(wù)器應(yīng)用通話,以及應(yīng)用程序必須能夠適用于許多不同類型的客戶。為了滿足這一需要,必須制定詳細(xì)的客戶端和服務(wù)器相互通信的協(xié)義。這正是超文本傳輸協(xié)議( HTTP )的目的。 通信模型所確定的 HTTP 形式的基礎(chǔ),所有的 Web 應(yīng)用程序設(shè)計?;玖私?HTTP 的關(guān)鍵應(yīng)用,適合發(fā)展中國家的限制范圍內(nèi)的協(xié)議,無論哪個服務(wù)器端技術(shù)的使用。在本章中,我們看一下最重要的細(xì)節(jié)的 HTTP 您需要了解作為一個 Web 應(yīng)用程序開發(fā)。 另外一個項目:這本書是用 JSP 作為服務(wù)器端技術(shù)。 JSP 技術(shù)是基于 Java Servlet技術(shù)。這兩種技術(shù)有著大量的術(shù)語和概念,所以知道一點 servlets 將幫助你,即使你開發(fā)純 JSP 的應(yīng)用。要真正理解和使用的全部的 JSP ,你需要知道一點 servlets 。因此,我們期待在 servlet 的基本入在最后一章的這一節(jié)。 HTTP 請求 /響應(yīng)模型 所有擴展 HTTP 和基于 HTTP 協(xié)議是基于一個非常簡單的通信模式。其工作原理如下:客戶端,通常是一個 Web 瀏覽器,發(fā)出了一個請求資源的服務(wù)器,服務(wù)器發(fā)回的響應(yīng)相應(yīng)的資源(或響應(yīng)的錯誤信息,如果它不能處理請求出于 某種原因) 。 A資源是一些事情的數(shù)據(jù),如一個簡單的 HTML 文件逐字返回到瀏覽器或程序,動態(tài)生成的響應(yīng)。 這種簡單的模式意味著三個重要的事實你需要了解: HTTP 是一種無狀態(tài)協(xié)議。這意味著服務(wù)器不保留任何信息發(fā)出后客戶端的反應(yīng),因此,它不能承認(rèn),多請求來自同一客戶端可能有親緣關(guān)系。 Web 應(yīng)用程序無法輕易地提供什么樣的即時反饋信息中常見的獨立的圖形用戶界面應(yīng)用程序,如文字處理機或傳統(tǒng)客戶機 /服務(wù)器應(yīng)用程序。每當(dāng)它們之間的互動客戶端和服務(wù)器需要一個請求 /響應(yīng)交流時。執(zhí)行請求 /響應(yīng)交流當(dāng)用戶選擇一個項目在一個列 表框或 填寫表單元素通常是過于繁重的帶寬提供給大多數(shù)的互聯(lián)網(wǎng)用戶。 這里沒有什么協(xié)議告訴服務(wù)器如何提出要求 。因此,服務(wù)器無法在客戶端上區(qū)分各種方法觸發(fā)的要求。例如,不允許 HTTP Web 服務(wù)器來區(qū)分一個明確的要求所造成的點擊一個鏈接或提交表單和一個隱含的要求所造成的調(diào)整瀏覽器窗口或使用瀏覽器的后退按鈕。此外,超文本傳輸協(xié)定不包含任何手段服務(wù)器調(diào)用客戶端的特定職能,例如回去在瀏覽器歷史記錄列表或發(fā)送的反應(yīng)在一定范圍內(nèi)。另外,服務(wù)器無法檢測什么時候用戶關(guān)閉瀏覽器。 多年來,人們已經(jīng)制定了各種技巧來克服務(wù)第一個問題 。HTTP 的無國籍性。其他兩個問題,沒有及時反饋,也沒有詳細(xì)說明如何提出要求,更難處理,但有些互動,才能實現(xiàn)所產(chǎn)生的反應(yīng),其中包括客戶端代碼(代碼執(zhí)行的瀏覽器) ,如 JavaScript 或 Java 小程序。 詳敘 Requests 讓我們仔細(xì)看看 Requests。用戶發(fā)送請求到服務(wù)器,通過點擊一個鏈接的網(wǎng)頁上,提交表單時,或輸入一個網(wǎng)頁地址在瀏覽器的地址欄。發(fā)送請求后,瀏覽器需要知道與哪些服務(wù)器交換數(shù)據(jù),并要求得到資源。 URL 必須跟據(jù)服務(wù)器名詳細(xì)描術(shù)端口號 ,例如: 第一部分所顯示的 URL 中指定的 Requests 是使用 HTTP 協(xié)議的。其次是服務(wù)器的名稱,在這種情況下 。 Web 服務(wù)器等待請求將在某一特定的 TCP / IP端口。端口號 80是標(biāo)準(zhǔn)端口,用于 HTTP 請求。如果 Web 服務(wù)器使用另一個端口, URL 必須跟據(jù)服務(wù)器名稱指定端口號。例如: 這一請求被發(fā)送到一臺服務(wù)器,使用端口 8080 而不 是 80 。最后部分的 URL ,/ ,確定了客戶端請求的資源。 網(wǎng)址實際上是一個專業(yè)化的統(tǒng)一資源標(biāo)識符( URI ,所界定的符合 RFC 2396 規(guī)格) 。URl 跟據(jù)地址確定部份資源,例如服務(wù)器,其中包含的資源。另一種類型的 URI是一個統(tǒng)一資源名稱( URN) ,這是一個全局唯一標(biāo)識符 ,無論在什么地方都有效的資源的位置。HTTP 只處理 URL 的不同。該條款的 URI 和 URL 常常被互換,不幸的是,他們有不同的定義略有不同的規(guī)格。我試圖使用條款所界定的 HTTP/ 規(guī)范(符合 RFC 2616年) ,這是相當(dāng)接近,以他們是如何也用在 Servlet 和 JSP 規(guī)范。因此,我只有當(dāng) URI 以 開頭時才使用的 term URl (或 ,為 HTTP 加密連線) ,其次是服務(wù)器名稱,并可能有一個端口號,如以前的例子。我使用的 URI 作為一個通用術(shù)語的任何字符串,確定了資源,確定位置可以從上下文而不耍要 URI。例如,當(dāng)請求已被交付給服務(wù)器,位置已經(jīng)定確,只有資源標(biāo)識符是很重要的。 瀏覽器使用 URL 信息創(chuàng)造的請求消息使用指定的協(xié)議發(fā)送到指定的服務(wù)器。 HTTP 請求消息由三部份組成:一個請求行,請求標(biāo)頭, 請求體。 請求行以方法名稱的開頭,隨后進行了資源標(biāo)識符和協(xié)議版本所使用的瀏覽器: GET / HTTP/ 最常用的方法是 GET。顧名思義, GET 請求用于從服務(wù)器檢索資源。這是默認(rèn)的請求方法,因此,如果您輸入網(wǎng)址在瀏覽器的地址欄,或者點擊一個鏈接,發(fā)送的請求是作為一個 GET 請求到服務(wù)器。 標(biāo)題要求提供額外的信息可以使用服務(wù)器來處理請求。郵件正文是只包含在某些類型的 requests,如 POST 請求以后討論。 下面是一個例子,一個有效的 HTTP 請求消息: GET / HTTP/ Host: 用戶代理: Mozilla/ (Windows。 U。 Win 9x 。 enUS。 rv: ) 接受: image/gif, image/jpeg, image/pjpeg, image/png, */* 接受語言: en 接受字符: iso88591,*,utf8 請求行指定的 GET 方法和要求的資源命名 / 使用 HTTP/ 協(xié)議返回。不同的頭提供不同的資料。 主機標(biāo)頭使用 URL告訴服務(wù)器主機名 。服務(wù)器可能有多個名稱,因此這一信息是用來區(qū)分多個虛擬的網(wǎng)絡(luò)服務(wù)器共享相同的 Web 服務(wù)器進程。 user agent 標(biāo)題包含有關(guān)類型的瀏覽器提出請求。服務(wù)器可以用它來傳送不同類型的反應(yīng),不同類型的瀏覽器。例如,如果服務(wù)器知道是使用 Inter Explorer 或 Netscape Navigator,它可以發(fā)出一個反應(yīng),充分利用每一個瀏覽器的獨特功能。它也可以判斷客戶端以外的 HTML 瀏覽器使用,如無線標(biāo)記語言(標(biāo)記語言)的瀏覽器的手機或 PDA 設(shè)備,并產(chǎn)生適當(dāng)?shù)姆磻?yīng)。 請求頭提供有關(guān) 的語言和文件格式的瀏覽器。這些標(biāo)題可以用來適應(yīng)不同功能的瀏覽器和不同的用戶,如使用了一個受支持的圖像格式和首選語言。這些只是一小部分的標(biāo)題中可以包含請求的信息。 資源標(biāo)識符( URI ) ,并不一定對應(yīng)于一個靜態(tài)文件在服務(wù)器上。它可以識別一個可執(zhí)行的程序,記錄在一個數(shù)據(jù)庫中,或差不多任何 Web 服務(wù)器知道。這就是通用術(shù)語資源的使用。事實上,就沒有辦法判斷 / 的通用資源識別符對應(yīng)的文件還是其他什么東西,它只是一個名字,這意味著一些服務(wù)器。 Web 服務(wù)器被配置為地圖這些指定的名稱對應(yīng)指定的資源 。 祥敘 response 當(dāng) Web 服務(wù)器收到請求,在 URI 的其礎(chǔ)上決定,用配置信息來處理它。它可以處理簡單的 HTML 文件,也可以將申請轉(zhuǎn)交給一些組成部分,負(fù)責(zé)相應(yīng)的資源 URI 。這可能是一個程序使用的數(shù)據(jù)庫信息,例如,動態(tài)生成一個適當(dāng)?shù)姆磻?yīng)。在瀏覽器沒有差別時 response是如何處理的 。一切關(guān)心的就得到了答復(fù)。 在回復(fù)郵件看起來類似請求消息。它包括三件事:一個狀態(tài)行,響應(yīng)頭,和一個可選的反應(yīng)機構(gòu)。下面是一個例子: HTTP/ 200 OK LastModified: Mon, 20 Dec 2020 23:26:42 GMT Date: Tue, 11 Jan 2020 20:52:40 GMT Status: 200 ContentType: text/html ServletEngine: Tomcat Web Server/ ContentLength: 59 html body h1Hello World!/h1 /body /html 狀態(tài)行開頭的名稱協(xié)議,其次是狀態(tài)代碼,并有簡短的描述狀態(tài)代碼。在這里,狀態(tài)代碼是 200 ,這 意味著被執(zhí)行的請求成功。回應(yīng)郵件標(biāo)題就像請求消息。在這個例子中,最后修改標(biāo)題給出的日期和時間,資源最后修改。該瀏覽器可以使用此信息作為一個時間戳在本地緩存 。下一次用戶要求這一資源,他可以向服務(wù)器發(fā)送它只要當(dāng)它被更新,因為這是最后一次要求。內(nèi)容類型標(biāo)頭講述了什么類型的瀏覽器的反應(yīng)數(shù)據(jù)和身體包含的內(nèi)容長度標(biāo)題是多么大。其他標(biāo)題不言自明。一個空行分隔標(biāo)題的郵件正文。在這里,內(nèi)容體是一個簡單的 HTML 網(wǎng)頁: html body h1Hello World!/h1 /body /html 當(dāng)然, body 可以包含一個更為復(fù)雜的 HTML 網(wǎng)頁或任何其他類型的內(nèi)容。例如,請求可能會返回一個 HTML 頁面的 img 要素。當(dāng)瀏覽器讀取第一個反應(yīng)時,并認(rèn)為是 img 要素,它就發(fā)出了一個新的要求所確定的資源,往往是在平行。服務(wù)器返回一個響應(yīng),每幅圖像的要求,與內(nèi)容類型標(biāo)題告訴什么類型的影像(例如圖片 /