【正文】 一個(gè)空行分隔郵件正文的標(biāo)題。內(nèi)容類型頭告訴瀏覽器有什么反應(yīng)的數(shù)據(jù)類型和主體包含內(nèi)容長度頭是多大。在這個(gè)例子中，最后的修飾頭給出了當(dāng)資源的最后修改的日期和時(shí)間。在這里，狀態(tài)代碼是 200，這意味著請求成功執(zhí)行。它包括：它包括三件事：一個(gè)狀態(tài)行，響應(yīng)頭，和一個(gè) 可選的反應(yīng)機(jī)構(gòu)。若要瀏覽器中并沒有要求是如何處理不同，它所關(guān)心的是得到一個(gè)回應(yīng)。它可以通過簡單的內(nèi)部處理從文件系統(tǒng)讀取一個(gè) HTML 文件，也可以提出請求的一些組件，它是對資源的 URI 相應(yīng)責(zé)任。 Web 服務(wù)器被配置為地圖這些指定的名稱對應(yīng)指定的資源。這就是通用術(shù)語資源的使用。 資源標(biāo)識(shí)符（ URI ），并不一定對應(yīng)于一個(gè)靜態(tài)文件在服務(wù)器上。這些標(biāo)題可以用來適應(yīng)不同功能的瀏覽器和不同的用戶，如使用了一個(gè)受支持的圖像格式和首選語言。它也可以判斷客戶端以外的 HTML 瀏覽器使用，如無線標(biāo) 記語言（標(biāo)記語言）的瀏覽器的手機(jī)或 PDA 設(shè)備，并產(chǎn)生適當(dāng)?shù)姆磻?yīng)。服務(wù)器可以用它來傳送不同類型的反應(yīng)，不同類型的瀏覽器。服務(wù)器可能有多個(gè)名稱，因此這一信息是用來區(qū)分多個(gè)虛擬的網(wǎng)絡(luò)服務(wù)器共享相同的 Web 服務(wù)器進(jìn)程。不同的頭提供不同的資料。 enUS。 U。郵件正文是只包含在某些類型的 requests，如 POST 請求以后討論。這是默認(rèn)的請求方法，因此，如果您輸入網(wǎng)址在瀏覽器的地址欄，或者點(diǎn)擊一個(gè)鏈接，發(fā)送的請求是作為一個(gè) GET 請求到服務(wù)器。請求行以方法名稱的開頭，隨后進(jìn)行了資源標(biāo)識(shí)符和協(xié)議版本所使用的瀏覽器： GET / HTTP/ 最常用的方法是 GET。 瀏覽器使用 URL信息創(chuàng)造的請求消息使用指定的協(xié)議發(fā)送到指定的 服務(wù)器。我使用的 URI 作為一個(gè)通用術(shù)語的任何字符串，確定了資源，確定位置可以從上下文而不需要 URI。我 試圖使用條款所界定的 HTTP/ 規(guī)范（符合 RFC 2616 年），這是相當(dāng)接近，以他們是如何也用在 servlet和 JSP規(guī)范。 HTTP 只處理 URL 的不同。 URI 跟據(jù)地址確定部份資源，例如服務(wù)器，其中包含的資源。最后部分的 URL / ,確定了客戶端請求的資源。如果 Web服務(wù)器使用另一個(gè)端口， URL 必須跟據(jù)服務(wù)器名稱指定端口號。 Web 服務(wù)器等待請求將在某一特定的 TCP / IP 端口。 URL 必須跟據(jù) 服務(wù)器名詳細(xì)描術(shù)端口號，例如： 第一部分所顯示的 URL 中指定的 Requests 是使用 HTTP 協(xié)議的。用戶發(fā)送請求到服務(wù)器，通過點(diǎn)擊一個(gè)鏈接的網(wǎng)頁上，提交表單時(shí)，或輸入一個(gè)網(wǎng)頁地址在瀏覽器的地址欄。其他兩個(gè)問題，沒有及時(shí)反饋，也沒有詳細(xì)說明如何提出要求 這個(gè)更難處理，但是可以通過產(chǎn)生的反應(yīng)來獲取一些互動(dòng)，這些反應(yīng)包括客戶端代碼（代碼執(zhí)行的瀏覽器），如 JavaScript 或 Java 小程序。另外，服務(wù)器無法檢測什么時(shí)候用戶關(guān)閉瀏覽器。例如，不允許 HTTP Web 服務(wù)器來區(qū)分一個(gè)明確的要求所造成的點(diǎn)擊一個(gè)鏈接或提交表單和一個(gè)隱含的要求所造成的調(diào)整瀏覽器窗口或使用瀏覽器的后退按鈕。執(zhí)行請求 /響應(yīng)交流當(dāng)用戶選擇一個(gè)項(xiàng)目在一個(gè)列表框或填寫表單元素通常是過于繁重的帶寬提供給大多數(shù)的互聯(lián)網(wǎng)用戶。 Web 應(yīng)用程序無法輕易地提供即時(shí)反饋信息中常見的獨(dú)立的圖形用戶界面 應(yīng)用程序，如文字處理機(jī)或傳統(tǒng)客戶機(jī) /服務(wù)器應(yīng)用程序。 這種簡單的模式意味著你需要了解三個(gè)重要的事實(shí)： HTTP 是一種無狀態(tài)協(xié)議。其工作原理如下：客戶端，通常是一個(gè) Web 瀏覽器，發(fā)出了一個(gè)請求資源的服務(wù)器，服務(wù)器發(fā)回的 響應(yīng)相應(yīng)的資源（或響應(yīng)的錯(cuò)誤信息，如果它不能處理請求出于某種原因）。因此，我們期待在本章最后一節(jié)講到的 servlet的基礎(chǔ)。這兩種技術(shù)有著很多的術(shù)語和概念，所以知道有關(guān)的 servlet 知識(shí)可以幫助你，即使你開發(fā)純 JSP 應(yīng)用程序。 另外一個(gè)項(xiàng)目：這 本書是關(guān)于使用作為服務(wù)器端技術(shù)的 JSP。基本了解HTTP 的關(guān)鍵應(yīng)用，適合發(fā)展中國家的限制范圍內(nèi)的協(xié)議，無論哪個(gè)服務(wù)器端技術(shù)的使用。這正是超文本傳輸協(xié)議（ HTTP）的用途。這意味著同樣簡單的客戶端程序必須能夠與許多不同的服務(wù)器應(yīng)用通信，以及應(yīng)用程序必須能夠適用于許多不同類型的客戶。今天，最常見的客戶端是一個(gè)在PC 或工作站的網(wǎng)絡(luò)瀏覽器，但其他類型的客戶正在迅速加入，如無線掌上電腦，手機(jī)，以及其他專業(yè)設(shè)備。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)用程序這一章開始。s responsibility to convert the response created by the servlet into an HTTP response message and send it back to the client Servlet Contexts and Web Applications A Java web application is typically made up by a bination of several different types of resources: JSP pages, servlets, applets, static HTML pages, custom tag libraries and other Java class files. Containers pliant with the Servlet specification (or later), support a standard, portable way to package all these resources, along with a web application deployment descriptor containing information about how all the resources fit together. The deployment descriptor and all the other web application files are arranged in a welldefined hierarchy within an archive file, called a web application archive (WAR). All pliant containers provide tools for installing a WAR file or a special directory where a WAR file is automatically picked up (such as the webapps directory in Tomcat). Most containers also support web applications deployed directly in a filesystem using the same file structure as is defined for the WAR file, which can be convenient during development. Within the container, each web application is represented by a servlet context. The servlet context is associated 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。t municate with the server in the same insecure way. Servlet Containers A servlet container is the connection between a web server and the servlets. It provides the runtime environment for 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 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 servlet until the server is shut down. The container then gives the servlet a chance to release resources and save its state (for instance, information accumulated during its lifetime). There are many different types of servlet containers. Some containers are called addons, or plugins, 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 operatingsystem 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 environment. Containers can also be embedded in other servers, such as a climatecontrol system, to offer a webbased interface to the system. A container bundled as part of an application server can distribute the execution of s