【導(dǎo)讀】Loosely,itcanbedefinedasan. (HTTP)isfor.developer.

　　

【正文】 iated with a unique URI path prefix called the context path. For instance, your human resources application can be associated with the context path /hr and your 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. 中文譯文： HTTP和 Servlet基礎(chǔ) 作者： Hans Bergsten 讓我們從定義 Web 應(yīng)用程序這一章開(kāi)始。我們都經(jīng)?？吹娇蛻舳藨?yīng)用程序，但到底什么是 Web 應(yīng)用程序？習(xí)慣上說(shuō)，它可以被定義為在服務(wù)器上運(yùn)行，通過(guò)一個(gè)簡(jiǎn)單的通用客戶端的用戶訪問(wèn)應(yīng)用程序。今天，最常見(jiàn)的客戶端是一個(gè)在PC 或工作站的網(wǎng)絡(luò)瀏覽器，但其他類型的客戶正在迅速加入，如無(wú)線掌上電腦，手機(jī)，以及其他專業(yè)設(shè)備。 這里的崇高目標(biāo)是能 夠從任何設(shè)備訪問(wèn)到你所要的信息和服務(wù)。這意味著同樣簡(jiǎn)單的客戶端程序必須能夠與許多不同的服務(wù)器應(yīng)用通信，以及應(yīng)用程序必須能夠適用于許多不同類型的客戶。為了滿足這種需要，如何在客戶端和服務(wù)器相互交談，必須詳細(xì)定義的協(xié)議。這正是超文本傳輸協(xié)議（ HTTP）的用途。 通信模型所確定的 HTTP 形式的基礎(chǔ)，所有的 Web 應(yīng)用程序設(shè)計(jì)?；玖私釮TTP 的關(guān)鍵應(yīng)用，適合發(fā)展中國(guó)家的限制范圍內(nèi)的協(xié)議，無(wú)論哪個(gè)服務(wù)器端技術(shù)的使用。在本章中，我們看一下最重要的細(xì)節(jié)的 HTTP 您需要了解作為一個(gè)Web 應(yīng)用程序開(kāi)發(fā)。 另外一個(gè)項(xiàng)目：這 本書(shū)是關(guān)于使用作為服務(wù)器端技術(shù)的 JSP。 JSP 是基于 Java Servlet 技術(shù)。這兩種技術(shù)有著很多的術(shù)語(yǔ)和概念，所以知道有關(guān)的 servlet 知識(shí)可以幫助你，即使你開(kāi)發(fā)純 JSP 應(yīng)用程序。要真正理解并使用了 JSP 的全部功能，您需要了解一點(diǎn) servlet 的知識(shí)。因此，我們期待在本章最后一節(jié)講到的 servlet的基礎(chǔ)。 HTTP 請(qǐng)求 /響應(yīng)模型 所有擴(kuò)展 HTTP 和基于 HTTP 協(xié)議是基于一個(gè)非常簡(jiǎn)單的通信模式。其工作原理如下：客戶端，通常是一個(gè) Web 瀏覽器，發(fā)出了一個(gè)請(qǐng)求資源的服務(wù)器，服務(wù)器發(fā)回的 響應(yīng)相應(yīng)的資源（或響應(yīng)的錯(cuò)誤信息，如果它不能處理請(qǐng)求出于某種原因）。 A 資源是一些事情的數(shù)據(jù)，如一個(gè)簡(jiǎn)單的 HTML 文件逐字返回到瀏覽器或程序，動(dòng)態(tài)生成的響應(yīng)。 這種簡(jiǎn)單的模式意味著你需要了解三個(gè)重要的事實(shí)： HTTP 是一種無(wú)狀態(tài)協(xié)議。這意味著服務(wù)器不保留任何信息發(fā)出后客戶端的反應(yīng)，因此，它不承認(rèn)，多請(qǐng)求來(lái)自同一客戶端可能有親緣關(guān)系。 Web 應(yīng)用程序無(wú)法輕易地提供即時(shí)反饋信息中常見(jiàn)的獨(dú)立的圖形用戶界面 應(yīng)用程序，如文字處理機(jī)或傳統(tǒng)客戶機(jī) /服務(wù)器應(yīng)用程序。每當(dāng)它們之間的互動(dòng)客戶端和服務(wù)器需要一個(gè)請(qǐng)求 /響應(yīng)交流 時(shí)。執(zhí)行請(qǐng)求 /響應(yīng)交流當(dāng)用戶選擇一個(gè)項(xiàng)目在一個(gè)列表框或填寫(xiě)表單元素通常是過(guò)于繁重的帶寬提供給大多數(shù)的互聯(lián)網(wǎng)用戶。 這里沒(méi)有什么協(xié)義告訴服務(wù)器如何提出請(qǐng)求，因此，服務(wù)器無(wú)法在客戶端上區(qū)分各種方法觸發(fā)的要求。例如，不允許 HTTP Web 服務(wù)器來(lái)區(qū)分一個(gè)明確的要求所造成的點(diǎn)擊一個(gè)鏈接或提交表單和一個(gè)隱含的要求所造成的調(diào)整瀏覽器窗口或使用瀏覽器的后退按鈕。此外，超文本傳輸協(xié)定不包含任何手段服務(wù)器調(diào)用客戶端的特定職能，例如回去在瀏覽器歷史記錄列表或發(fā)送的反應(yīng)在一定范圍內(nèi)。另外，服務(wù)器無(wú)法檢測(cè)什么時(shí)候用戶關(guān)閉瀏覽器。 多年來(lái)，人們已經(jīng)制定了各種技巧來(lái)克服務(wù)第一個(gè)問(wèn)題； HTTP 的無(wú)國(guó)籍性。其他兩個(gè)問(wèn)題，沒(méi)有及時(shí)反饋，也沒(méi)有詳細(xì)說(shuō)明如何提出要求 這個(gè)更難處理，但是可以通過(guò)產(chǎn)生的反應(yīng)來(lái)獲取一些互動(dòng)，這些反應(yīng)包括客戶端代碼（代碼執(zhí)行的瀏覽器），如 JavaScript 或 Java 小程序。 詳敘 Requests 讓我們仔細(xì)看看 Requests。用戶發(fā)送請(qǐng)求到服務(wù)器，通過(guò)點(diǎn)擊一個(gè)鏈接的網(wǎng)頁(yè)上，提交表單時(shí)，或輸入一個(gè)網(wǎng)頁(yè)地址在瀏覽器的地址欄。發(fā)送請(qǐng)求后，瀏覽器需要知道與哪些服務(wù)器交換數(shù)據(jù)，并要求得到資源。 URL 必須跟據(jù) 服務(wù)器名詳細(xì)描術(shù)端口號(hào)，例如： 第一部分所顯示的 URL 中指定的 Requests 是使用 HTTP 協(xié)議的。其次是服務(wù)器的名稱，在這種情況下 。 Web 服務(wù)器等待請(qǐng)求將在某一特定的 TCP / IP 端口。端口號(hào) 80 是標(biāo)準(zhǔn)端口，用于 HTTP 請(qǐng)求。如果 Web服務(wù)器使用另一個(gè)端口， URL 必須跟據(jù)服務(wù)器名稱指定端口號(hào)。例如： 這一請(qǐng)求被發(fā)送到一臺(tái)服務(wù)器，使用端口 8080 而不是 80。最后部分的 URL / ,確定了客戶端請(qǐng)求的資源。 網(wǎng)址實(shí)際上是一個(gè)專業(yè)化的統(tǒng)一資源標(biāo)識(shí)符（ URI，所界定的符合 RFC 2396 規(guī)格）。 URI 跟據(jù)地址確定部份資源，例如服務(wù)器，其中包含的資源。另一種類型的 URI 是一個(gè)統(tǒng)一資源名稱（ URN），這是一個(gè)全局唯一標(biāo)識(shí)符 ,無(wú)論在什么地方都有效的資源的位置。 HTTP 只處理 URL 的不同。該條款的 URI 和 URL常常被互換，不幸的是，他們有不同的定義略有不同的規(guī)格。我 試圖使用條款所界定的 HTTP/ 規(guī)范（符合 RFC 2616 年），這是相當(dāng)接近，以他們是如何也用在 servlet和 JSP規(guī)范。因此，我只有當(dāng) URI以 開(kāi)頭時(shí)才使用的 term URI （或 ，為 HTTP 加密連線），其次是服務(wù)器名稱，并可能有一個(gè)端口號(hào)，如以前 的例子。我使用的 URI 作為一個(gè)通用術(shù)語(yǔ)的任何字符串，確定了資源，確定位置可以從上下文而不需要 URI。例如，當(dāng)請(qǐng)求已被交付給服務(wù)器，位置已經(jīng)定確，只有資源標(biāo)識(shí)符是很重要的。 瀏覽器使用 URL信息創(chuàng)造的請(qǐng)求消息使用指定的協(xié)議發(fā)送到指定的 服務(wù)器。 HTTP 請(qǐng)求消息由三部份組成：一個(gè)請(qǐng)求行，請(qǐng)求標(biāo)頭，請(qǐng)求體。請(qǐng)求行以方法名稱的開(kāi)頭，隨后進(jìn)行了資源標(biāo)識(shí)符和協(xié)議版本所使用的瀏覽器： GET / HTTP/ 最常用的方法是 GET。顧名思義， GET 請(qǐng)求用于從服務(wù)器檢索資源。這是默認(rèn)的請(qǐng)求方法，因此，如果您輸入網(wǎng)址在瀏覽器的地址欄，或者點(diǎn)擊一個(gè)鏈接，發(fā)送的請(qǐng)求是作為一個(gè) GET 請(qǐng)求到服務(wù)器。 標(biāo)題要求提供額外的信息可以使用服務(wù)器來(lái)處理請(qǐng)求。郵件正文是只包含在某些類型的 requests，如 POST 請(qǐng)求以后討論。 下面是 一個(gè)例子，一個(gè)有效的 HTTP 請(qǐng)求消息： GET / HTTP/ Host： 用戶代理： Mozilla/ (Windows。 U。 Win 9x 。 enUS。 rv: )接受：image/gif, image/jpeg, image/pjpeg, image/png, */* 接受語(yǔ)言： en 接受字符： iso88591,*,utf8 請(qǐng)求行指定的 GET 方法和要求的資源命名 / 使用 HTTP/ 協(xié)議返回。不同的頭提供不同的資料。 主機(jī)標(biāo)頭使用 URL 告訴服務(wù)器主機(jī)名。服務(wù)器可能有多個(gè)名稱，因此這一信息是用來(lái)區(qū)分多個(gè)虛擬的網(wǎng)絡(luò)服務(wù)器共享相同的 Web 服務(wù)器進(jìn)程。 user agent 標(biāo)題包含有關(guān)類型的瀏覽器提出請(qǐng)求。服務(wù)器可以用它來(lái)傳送不同類型的反應(yīng)，不同類型的瀏覽器。例如，如果服務(wù)器知道是使用 Inter Explorer或 Netscape Navigator，它可以發(fā)出一個(gè)反應(yīng)，充分利用每一個(gè)瀏覽器的獨(dú)特功能。它也可以判斷客戶端以外的 HTML 瀏覽器使用，如無(wú)線標(biāo) 記語(yǔ)言（標(biāo)記語(yǔ)言）的瀏覽器的手機(jī)或 PDA 設(shè)備，并產(chǎn)生適當(dāng)?shù)姆磻?yīng)。 請(qǐng)求頭提供有關(guān)的語(yǔ)言和文件格式的瀏覽器。這些標(biāo)題可以用來(lái)適應(yīng)不同功能的瀏覽器和不同的用戶，如使用了一個(gè)受支持的圖像格式和首選語(yǔ)言。這些只是一小部分的標(biāo)題中可以包含請(qǐng)求的信息。 資源標(biāo)識(shí)符（ URI ），并不一定對(duì)應(yīng)于一個(gè)靜態(tài)文件在服務(wù)器上。它可以識(shí)別一個(gè)可執(zhí)行的程序，記錄在一個(gè)數(shù)據(jù)庫(kù)中，或差不多任何 Web 服務(wù)器知道。這就是通用術(shù)語(yǔ)資源的使用。事實(shí)上，就沒(méi)有辦法判斷 / 的通用資源識(shí)別符對(duì)應(yīng)的文件還是其他什么東西，它只是一 個(gè)名字，這意味著一些服務(wù)器。 Web 服務(wù)器被配置為地圖這些指定的名稱對(duì)應(yīng)指定的資源。 祥敘 response 當(dāng) Web 服務(wù)器接收請(qǐng)求，它根據(jù)配置的信息，查看 URI 并且決定如何處理請(qǐng)求。它可以通過(guò)簡(jiǎn)單的內(nèi)部處理從文件系統(tǒng)讀取一個(gè) HTML 文件，也可以提出請(qǐng)求的一些組件，它是對(duì)資源的 URI 相應(yīng)責(zé)任。這可以是一個(gè)程序使用的數(shù)據(jù)庫(kù)信息，例如，動(dòng)態(tài)地生成一個(gè)適當(dāng)?shù)幕貞?yīng)。若要瀏覽器中并沒(méi)有要求是如何處理不同，它所關(guān)心的是得到一個(gè)回應(yīng)。 響應(yīng)消息類似于請(qǐng)求信息。它包括：它包括三件事：一個(gè)狀態(tài)行，響應(yīng)頭，和一個(gè) 可選的反應(yīng)機(jī)構(gòu)。下面是一個(gè)例子： 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é)議的名稱，后跟一個(gè)狀態(tài)代碼和一個(gè)狀態(tài)代碼的簡(jiǎn)短說(shuō)明。在這里，狀態(tài)代碼是 200，這意味著請(qǐng)求成功執(zhí)行。響應(yīng)消息剛剛想請(qǐng)求消息頭。在這個(gè)例子中，最后的修飾頭給出了當(dāng)資源的最后修改的日期和時(shí)間。該瀏覽器可以使用本地緩存中的一個(gè)時(shí)間戳這一信息，下一次用戶要求這一資源，他可以向服務(wù)器發(fā)送它只要當(dāng)它被更新，因?yàn)檫@是最后一次要求。內(nèi)容類型頭告訴瀏覽器有什么反應(yīng)的數(shù)據(jù)類型和主體包含內(nèi)容長(zhǎng)度頭是多大。另一頭是不言自明。一個(gè)空行分隔郵件正文的標(biāo)題。在這里，主體是 一個(gè)簡(jiǎn)單的 HTML 頁(yè)： html body