亚洲AV永久无码精品久久

Servlet2.3規范

第一章：

servlet2.3規范用到了一下的一些規范：J2EE、JSP1.1、JNDI

在14章中講述了規范中的所有的classes類(lèi)或接口（改文中不講述）。對開(kāi)發(fā)者而言以下的有些相關(guān)的協(xié)議：URI、URL、HTTP/1.0、MIME、HTCPCP/1.0、XML

1.1 什么是servlet？

servlet是一個(gè)基于java技術(shù)的web組件，該組件被容器管理，能被編譯成字節碼被web服務(wù)調用；容器也被稱(chēng)之為引擎，是支持servlet功能的web服務(wù)的擴展。servlet之間的通信是通過(guò)客戶(hù)端請求被引擎執行成request/response對象進(jìn)行的。

1.2 什么是servlet引擎？

servlet引擎是web服務(wù)器或應用服務(wù)器的一部分，服務(wù)器能夠支持網(wǎng)絡(luò )的請求/響應，基于請求解析MIME，基于響應格式化MIME。servlet引擎是一個(gè)servlet容器，也掌管著(zhù)servlet的生命周期。

所有的servlet引擎都必須支持HTTP的請求/響應模式，但HTTPS的請求/響應模式也是被支持的。HTTP的版本最小要HTTP/1.0，最好是HTTP/1.1。servlet引擎也具有安全和權限的一些特性，這些特性其服務(wù)器應提供。

1.3 例子

一個(gè)典型的事件執行的順序是：

1) 客戶(hù)端向web服務(wù)器發(fā)起一個(gè)HTTP請求

2) HTTP請求被web服務(wù)器接受，并移交給servlet引擎，servlet引擎可以在主機的同一個(gè)進(jìn)程、不同的進(jìn)程或其他的web服務(wù)主機的進(jìn)程中啟動(dòng)。

3) servlet引擎根據servlet的配置檔確定調用的servlet，并把request對象、response對象傳給它。

4) 4．servlet通過(guò)request對象知道客戶(hù)端的使用者是誰(shuí)，客戶(hù)的請求信息是什么和其他的一些信息。servlet處理完請求后把要返回的信息放入response對象返回到客戶(hù)端

5）一旦servlet完成了請求的處理，servlet引擎就會(huì )刷新response，把控制權返回給web服務(wù)器

1.4與其它技術(shù)的比較

與其它服務(wù)相比servlet有以下的一些優(yōu)點(diǎn)

1) 運行速度上比CGI快，因為使用了多線(xiàn)程

2) servlet使用了標準的api，可被許多web服務(wù)支持

3) 與系統無(wú)關(guān)性，一次編譯多次使用

第二章

servlet接口是servlet api核心部分，所有的servlet都是直接或間接的實(shí)現了這些接口。兩個(gè)最重要的servlet api 接口是GenericServlete 和 HttpServlet，更多的開(kāi)發(fā)者都繼承HttpServlet去實(shí)現他們的servlet

2.1 Request 包含的方法

一個(gè)基本的servlet接口應該定義一個(gè)方法包含客戶(hù)端的信息，每次servlet引擎把一個(gè)request發(fā)送到一個(gè)servlet事例，這個(gè)方法都要被調用。

對于并發(fā)的請求，web應用需要設計者設計的servlet引擎能分配多個(gè)線(xiàn)程執行這個(gè)方法。

2.1.1 HTTP 請求處理的方法

HttpServlet是實(shí)現了Servlet接口的抽象類(lèi)，增加了一些新的方法，這些方法在處理HTTP請求時(shí)會(huì )被service方法自動(dòng)調用，這些方法是：

doGet 接受 HTTP 的GET請求

doPost 接受 HTTP 的POST請求

doPut 接受 HTTP的PUT請求

doDelete 接受 HTTP的DELETE請求

doHead 接受接受 HTTP的HEAD請求

doOptions 接受 HTTP的OPTIONS請求

doTrace 接受 HTTP的TRACE請求

一個(gè)開(kāi)發(fā)者只會(huì )涉及到doGet和doPost方法，其它的方法是為非常熟悉HTTP的設計師準備的

2.1.2

HTTP/1.0只定義了doGet，doHead，doPost方法，沒(méi)有定義PUT，DELETE，OPTIOONS和TRACE方法

2.1.3

HttpServlet接口定義了getLastModified方法

2.2 實(shí)例數

2.2.1

在分布式環(huán)境中servlet引擎為每個(gè)servlet只能聲明一個(gè)實(shí)例，當一個(gè)servlet實(shí)現了SingleThreadModel接口時(shí)，servlet引擎可以聲明多個(gè)實(shí)例去處理請求，servlet在應用服務(wù)的部署描述中定義發(fā)布.

2.2.2單線(xiàn)程servlet

SingleThreadModel接口保證了在同一時(shí)刻一個(gè)servlet實(shí)例的service方法只會(huì )被一個(gè)線(xiàn)程執行。這對于每個(gè)請求發(fā)送給每個(gè)實(shí)例是很重要的。引擎可以從對象池中選擇，對象池可以在同一時(shí)刻保持多個(gè)實(shí)例，如HttpSession可以被多個(gè)servlet在任何時(shí)候調用包括實(shí)現了SingleThreadModel接口的servlet

2.3 servlet的生命周期

一個(gè)好的生命周期的定義應該是servlet怎么被引入了，怎么實(shí)例化的，怎么初始化的？當請求從客戶(hù)端來(lái)的時(shí)候，是怎么從服務(wù)器中取出來(lái)的，這些在javax.servlet.Servlet的接口的init，service，destroy方法中都有明確的定義。

所有的servlet都必須實(shí)現GenericServlet或HttpServlet抽象類(lèi)

2.3.1 servlet的引入和實(shí)例化

servlet引擎會(huì )可靠的引入和實(shí)例化servlet，當servlet引擎被啟動(dòng)時(shí)servlet就被引入和實(shí)例化了，或者當一個(gè)servlet被請求時(shí)被引擎引入和實(shí)例化。

servlet引擎啟動(dòng)時(shí)，需要裝載的類(lèi)通過(guò)java的裝載類(lèi)進(jìn)行裝載，被裝載的類(lèi)可以在本地文件系統、遠程文件系統或網(wǎng)絡(luò )服務(wù)中。在裝載完后，引擎就實(shí)例化它們。

2.3.2 初始化

在servlet對象實(shí)例化后，引擎必須在這個(gè)servlet接受客戶(hù)段請求之前初始化，在初始化中servlet可以讀取固定的配置信息，一些昂貴的資源如數據庫連接和一次性激活的資源，引擎通過(guò)調用servlet接口的init方法初始化。每個(gè)serlet對象都實(shí)現了Servlet接口和ServletConfig接口,ServletConfig接口允許servlet接受web應用配置檔中配置的參數，還向servlet中傳入了一個(gè)描述servlelt運行環(huán)境的類(lèi)（ServletContext）

2.3.2.1 在初始化時(shí)發(fā)生錯誤

在初始化過(guò)程中，servlet實(shí)例能拋出UnavailableException 或ServletException異常。在這樣的情況下servlet不能被放入服務(wù)中，必須被引擎釋放，destroy方法沒(méi)有被調用。在初始化失敗后引擎可以在UnavailableException異常規定的最短無(wú)效時(shí)間后實(shí)例化新的一個(gè)實(shí)例，再初始化。

2.3.3 request

當servlet初始化完成后，引擎可以使用它去處理客戶(hù)端的請求了。請求被封裝在Servletrequest類(lèi)型的對象中，響應信息被封裝在ServletResponse類(lèi)型的對象中，這兩個(gè)對象以參數的形式傳給Servlet接口中的service方法。

2.3.3.1 多線(xiàn)程問(wèn)題

servlet引擎可以發(fā)送并發(fā)的請求給servlet的service方法，servlet開(kāi)發(fā)者必須提供足夠的線(xiàn)程來(lái)運行service方法。

對開(kāi)發(fā)者來(lái)說(shuō)一個(gè)可以選擇的方法是實(shí)現SingleThreadModel接口，以確保在同一時(shí)刻只有一個(gè)請求在service方法中。一個(gè)引擎要確保請求能夠在servlet中持續化，或維持在一個(gè)servlet實(shí)例池中，如果servlet是web應用服務(wù)的一部分，引擎可以在一個(gè)虛擬機中擁有一個(gè)servlet實(shí)例化的池。

對于沒(méi)有實(shí)現SingleThreadModel接口的servlet，如果service方法（或 doGet，doPost）被聲明為synchronized，引擎將不能用實(shí)例池的途徑，而必須持續化請求，強力建議開(kāi)發(fā)者不能聲明synchronize service方法，這樣會(huì )嚴重影響系統的性能。

2.3.3.2 request中的異常

在處理請求時(shí)servlet可以?huà)伋鯯ervletException或UnavailableException異常，一個(gè)ServletException異常會(huì )在處理一個(gè)請求出現錯誤時(shí)拋出，引擎將清除這個(gè)異常。當servlet一時(shí)或永久地不能獲得一個(gè)請求時(shí)就會(huì )拋出UnavailableException異常,如果是一個(gè)永久性異常時(shí)引擎將調用它的destroy方法從服務(wù)器中消除servlet實(shí)例，如果是暫時(shí)性異常時(shí)引擎在異常期間不發(fā)送請求給servlet。如果返回SERVICE_UNAVAILABLE(503)響應，在這期間引擎將不接受任何請求，直到header中出現Retry-After。引擎可以不區分永久性還是暫時(shí)性的異常把所有的UnavailableException作為永久性處理。

2.3.3.3 線(xiàn)程安全

執行request和response對象不能保證是線(xiàn)程安全的，意思是說(shuō)他們只能在請求的線(xiàn)程中使用，不能被其它線(xiàn)程中的對象使用。

2.3.4 結尾

servlet實(shí)例可能被引擎保存幾毫秒或和引擎一樣的生命時(shí)間或在這兩者之間。當引擎決定結束一個(gè)servlet時(shí)，調用它的destroy方法，在destroy中釋放任何長(cháng)久固定的資源。

在引擎調用desroy方法之前，必須保證運行在service方法中的線(xiàn)程都完成處理，或者超過(guò)了服務(wù)定義的執行時(shí)間。

一旦servlet實(shí)例的destroy方法被調用，引擎不在發(fā)送任何請求給這個(gè)實(shí)例。如果引擎再次使用這個(gè)servlet就必須再建一個(gè)這個(gè)servlet的實(shí)例。

在destroy方法執行完成后，引擎將釋放這個(gè)servlet實(shí)例，于是就符合垃圾回收機制的條件了。

3.1 介紹ServletContext接口

ServletContext接口定義了servlet運行環(huán)境的信息。引擎提供商有義務(wù)在servlet引擎中提供一個(gè)實(shí)現了ServletContext接口的對象。通過(guò)這個(gè)對象servlet能夠獲得log事件，資源的URL，設置或存儲servlet之間通信的變量。ServletContext在web服務(wù)中確定了一個(gè)所有請求開(kāi)始的路徑，是ServletContext的上下文路徑。

3.2 ServletContext 接口的作用范圍

每個(gè)web應用配置到容器中都會(huì )產(chǎn)生一個(gè)實(shí)現了ServvletContext接口的實(shí)例。如果是分布式的，將會(huì )在每個(gè)java虛擬機上產(chǎn)生一個(gè)ServletContext實(shí)例。容器中默認固有的web應用（不是發(fā)布上來(lái)的web應用）有一個(gè)默認的ServletContext，在分布式中這個(gè)默認的ServletContext只存在于一個(gè)虛擬機中，是不可分配的。

3.3 初始化參數

ServletContext接口的getInitParameter,getInitParameterNames方法接受部署描述文件中的初始化參數，這些參數可以是的安裝信息，或網(wǎng)站管理員的mail或名字或對系統的評論。

3.4 上下文屬性

servlet可以通過(guò)一個(gè)名稱(chēng)把對象邦定到servletContext中，幫定到ServletContext中的對象都能被同一個(gè)web服務(wù)中的其它對象引用。ServletContext中的屬性方法有：

setAttribute

getAttribute

getAttributeNames

removeAttribute

3.4.1 在分布式系統中上下文的屬性

上下文屬性是在本地的虛擬機中保存的，這防止了ServletContext屬性存在于分布式的內存中。當信息需要在一個(gè)分布式環(huán)境中共享的時(shí)候，信息應該被放在session中，或存在數據庫中，或存在一個(gè)實(shí)體bean中。

3.5 資源

ServletContext接口提供了獲取web服務(wù)中的靜態(tài)資源的方法：

getResource

getResourceAsStream

這些方法以一個(gè)“/”作為上下文的根目錄，后跟著(zhù)資源路徑的路徑為參數。這些資源可以在本地服務(wù)系統中也可以在另個(gè)web應用中，或在一個(gè)遠程的文件系統中。

這些方法不能用于去獲得一個(gè)動(dòng)態(tài)的資源，如要調用一個(gè)jsp頁(yè)面，getResource("/index.jsp")將返回index.jsp的原代碼，不能web顯示index.jsp。

要獲得資源列表可以用getResourcePaths(String path)方法

3.6 多主機和 Servlet 上下文

web服務(wù)中可能在一個(gè)IP上有多個(gè)邏輯主機的情況。在這種情況下每個(gè)邏輯主機必須有自己?jiǎn)为毜膕ervlet上下文，或者設置多個(gè)servlet 上下文，但在邏輯主機中不能共享這些servlet 上下文，一個(gè)主機只能單獨使用一個(gè)。

3.7

引擎提供類(lèi)重新裝載機制是必須的，必須確認應用中所有的類(lèi)和接口都可以在單類(lèi)裝載器中裝載；在session綁定監聽(tīng)事件中引擎會(huì )終止正在裝在的類(lèi)。以前版本的裝載器，引擎創(chuàng )建一個(gè)新的裝載器裝載一個(gè)servlet或class和類(lèi)裝載器裝載其他的servlet或類(lèi)截然不同；這可能裝載一個(gè)未知的類(lèi)或對象，產(chǎn)生不可預知的行為。這是新的類(lèi)裝載器中是應該注意預防的問(wèn)題。

3.7.1 臨時(shí)工作目錄

Servlet 上下文需要一個(gè)臨時(shí)存儲的目錄。servlet引擎必須為每個(gè)servlet 上下文提供一個(gè)私有臨時(shí)目錄，通過(guò)javax.servlet.context.tempdir的context屬性使目錄有效。與該屬性關(guān)聯(lián)的對象必須是java.io.File類(lèi)型。

在許多servlet引擎實(shí)現中提供請求可以識別的通用的機制。

當servlet引擎重起始不必維護臨時(shí)目錄中的內容，但要確保臨時(shí)目錄中的該上下文內容對于運行在該servlet引擎中的其它web應用中的servlet 上下文是不可見(jiàn)的。

4 requeset

request對象包含了客戶(hù)端的所有請求信息。在HTTP協(xié)議中，客戶(hù)端發(fā)送到服務(wù)端的信息都包含在請求的HTTP 頭和消息體中

4.1 HTTP 協(xié)議的參數

客戶(hù)端發(fā)送給servlet引擎的參數是包含在請求中的，引擎從客戶(hù)端請求的URI字符串中或POST數據中解析出請求的參數。參數以name-value的形式存儲的。任何一個(gè)name可以對應多個(gè)value。在ServletRequest接口的方法中：

getParameter

getParameterNames

getParameterValues

getParameterValues方法返回關(guān)聯(lián)到一個(gè)name上的一個(gè)String對象的數組。getParameter返回name對應的values數組中的第一個(gè)value。URI和POST體中的參數都會(huì )放入請求參數的set對象中。URI中的參數會(huì )在POST體之前被引入，如URI中的參數“a=hello”post體中的參數是a=goodbye&a=world,則參數set中的內容是a=(hello,goodbye,world).以HTTP GET請求的參數是不隱蔽的，參數必須通過(guò)getRequestURI或getPathInfo方法獲得參數字串。

4.1.1 參數什么時(shí)候有效

在post form中的數據參數被放入參數set之前的情況是這樣的：

1）請求是一個(gè)HTTP或一個(gè)HTTPS

2）HTTP方法是POST

3）內容的類(lèi)型是application/x-www-form-urlencoded

4）初始化過(guò)的servlet從request對象中調用getParameter方法（或getParameterNames，getParameterValues）。

Post form 中的數據符合條件的就放入參數set中，不符合的就放入request對象的輸入流中。

4.2 屬性

request的屬性是一個(gè)對象，引擎可以把API不能表達的信息放入屬性中，一個(gè)servlet也可以設置一個(gè)屬性信息用于servlet之間的通信。request對象中的屬性方法有：

getAttribute

getAttributeNames

setAttribute

一個(gè)屬性名稱(chēng)只能關(guān)聯(lián)一個(gè)value。屬性名以“java.”或“javax.”為前綴的是規范保留的，類(lèi)似的“sun.”“com.sun”是sun公司的保留字，這些保留的前綴是不能使用的。name建議使用統一的包命名規范名稱(chēng)。

4.3 頭

servlet通過(guò)HttpServletRequest接口的方法獲得HTTP的包頭信息，這些方法是：

getHeader

getHeaders

getHeaderNames

getHeader 方法返回頭的名稱(chēng)。一個(gè)名稱(chēng)可以關(guān)聯(lián)多個(gè)頭信息，如果在這種情況下，getHeader方法返回第一個(gè)頭信息。

getHeaders返回與一個(gè)名稱(chēng)關(guān)聯(lián)的所有頭信息存放在Enumeration對象中。HttpServletRequest提供了一些提取頭信息的類(lèi)型轉換方法，如：

getIntHeader 把頭信息中的數據轉換成int型，如果轉換失敗會(huì )報NumberFormatException錯誤。

getDateHeader 把頭信息中日期的數據轉換成date型，如果轉換失敗會(huì )報IllealArgumentException錯誤

4.4 請求路徑

context路徑：這路徑是和ServletContext對象關(guān)聯(lián)的，在web服務(wù)中默認的上下文路徑是空的字符串，如果上下文路徑不是web服務(wù)的根目錄，則路徑以‘/’字符開(kāi)始，但不能以‘/’結束。

Servlet 路徑：與該請求匹配的servlet的路徑。該路徑以‘/’字符開(kāi)頭，或以‘/*’開(kāi)頭但后面為空字串。

路徑信息：是請求路徑的一部分，但不是context路徑的一部分，也不是Servlet路徑的一部分，它既不為null也不是以‘/’開(kāi)頭的字符串。

上一路徑在HttpServletRequest接口中對應的方法是：

getContextPath

getServletPath

getPathInfo

requestURI = contextPath + servletPath + pathInfo

上下文配置的例子：

Conteext Path /catalog

Servlet Mapping Pattern:/lawn/*

Servlet:LawnServlet

Servlet Mapping Pattern:/garden/*

Servlet:GardenServlet

Servlet Mapping Pattern:*.jsp

Servlet:JSPServlet

觀(guān)察下面的路徑

Request path path Elements

/catalog/lawn/index.htm ContextPath:/catalog

ServletPath:/lawn

PathInfo:/index.html

/catalog/garden/implements/

ContextPath:/catalog

ServletPath:/garden

PathInfo:/implements/

/catalog/help/feedback.jsp

ContextPath:/catalog

ServletPath:/help/feedback.jsp

PathInfo:null

4.5 路徑轉換

在A(yíng)PI中有兩個(gè)簡(jiǎn)單的方法允許開(kāi)發(fā)者獲得文件系統的路徑：

ServletContext.getRealPath

HttpServletRequet.getPathTranslated

getRealPath(String aPath)方法返回本地文件系統的絕對路徑。getPathTranslated方法計算出請求pathInfo中的絕對路徑。

以上的兩個(gè)方法，servlet引擎不能辨認文件的路徑是否有效，當web應用調用一個(gè)不確定遠程文件系統，或數據庫路徑中的文件時(shí)，會(huì )返回null

4.6 Cookies

HttpServletRequest接口中提供了getCookies方法返回請求中的cookies數組，在每次客戶(hù)端請求時(shí)cookies數據就從客戶(hù)端發(fā)送給服務(wù)?？蛻?hù)端返還的部分cookie信息是cookie的name和cookie的value。當cookie被送入瀏覽器時(shí)，cookie的其它信息就可以設置了。

4.7 SSL 屬性

如果一個(gè)請求被轉給一個(gè)安全的協(xié)議，如HTTPS，這些信息必須暴露給ServletRequest接口的isSecure方法。web引擎必須把下面的信息暴露給servlet開(kāi)發(fā)者：

Attribute Attribute Name javaType

Cipher suite javax.servlet.request.cipher_suite String

bit size of the algo-rithm javax.servlet.request.key_size Integer

如果一個(gè)SSL證書(shū)伴隨著(zhù)一個(gè)請求，servlet引擎必須把它作為一個(gè)數組對象暴露給servlet開(kāi)發(fā)者，該數組中有

java.security.cert.X509Certificate對象和放在ServletRequest屬性中的javax.servlet.request.X509Certificate對象。

數組排列的順序是升序，在鏈中的證書(shū)的順序就是客戶(hù)端設置的順序。

4.8 國際化

ServletRequest接口的方法中提供了的方法：

getLocale

getLocales

getLocale方法將返回客戶(hù)端將從中獲得內容的首選的locale。要想知道更多的關(guān)于A(yíng)ccept-Language header 怎么解釋客戶(hù)端首選的語(yǔ)言的，請看14.4章

getLocales方法返回一個(gè)Locale objects的Enumeration,從首選的locale開(kāi)始遞減。

如果客戶(hù)端沒(méi)有制定首選的locale，servlet引擎一定要提供一個(gè)默認的locale供getLocale方法返回，getLocales方法必須包含一個(gè)默認的locale的locale element

4.9 Request 數據的編碼

有許多web瀏覽器不能發(fā)送一個(gè)編碼的頭內容，所以把編碼留給解讀HTTP請求的Read去做。對于默認的請求編碼，引擎通常創(chuàng )建一個(gè)reader用“ISO-8859-1”去解析POST的數據，如果客戶(hù)端沒(méi)有指明編碼，或者客戶(hù)端發(fā)送失敗，getCharacterEncoding方法就返回null。

如果客戶(hù)端沒(méi)有設置編碼，而請求需被另外一種編碼，可用ServletRequest接口中的setCharacterEncoding(String enc) 方法。必須在解析post數據或讀取請求流之前調用這些方法。

4.10 Request對象的生命周期

每個(gè)request對象僅在servlet的service方法或filter中的doFilter方法中有效，引擎重用request對象是為了降低創(chuàng )建request對象的性能消耗。

開(kāi)發(fā)者必須清楚request對象在給定的范圍外的一些不確定的行為。

第五章

response對象封裝著(zhù)服務(wù)端送給客戶(hù)端的信息，從服務(wù)端傳回的信息可以包含在請求的頭和消息體重。

5.1 緩存

servlet引擎支持應答緩存，典型的servlet會(huì )默認的執行緩存，servlet可以指定緩存參數。

設置緩存信息的方法在ServletResponse接口中的方法有：

getBufferSize

setBufferSize

isCommitted

Reset

resetBuffer

flushBuffer

這些方法只有在servlet調用ServletOutputStream 或Writer之前有效。

getBufferSize返回緩存的大小，如果沒(méi)有緩存，該方法返回0。

setBufferSize可以設置緩存的大小，但不是必須的。servlet會(huì )根據請求放置適當的緩存大小。這方法必須在servlet調用ServletOutputStream 或Writer方法之前被調用。如果在之后調用就會(huì )拋出IllegalStateException錯誤。

isCommitted返回一個(gè)boolen值，標志是否有任何一個(gè)字節的數據被返回給客戶(hù)端了。flushBuffer方法強制把緩存中的信息寫(xiě)到客戶(hù)端。

當response沒(méi)有提交緩存內容時(shí)調用reset方法就會(huì )清除緩存中的信息，包括頭信息和狀態(tài)碼。resetBuffer方法會(huì )清除緩存中的信息，但不會(huì )清除頭和狀態(tài)碼。在commit之后調用reset或resetBuffer都會(huì )拋出IllegalStateException錯誤，緩存中的內容不受影響。

使用緩存時(shí)，當緩存滿(mǎn)時(shí)response就必須立刻刷新把緩存中的內容發(fā)送給客戶(hù)端；只要第一個(gè)字節到了客戶(hù)端，commit的狀態(tài)就為true。

5.2 Headers

servlet能夠通過(guò)HttpServletResponse的一些方法設置HTTP響應的頭信息，這些方法有：

setHeader

addHeader

setHeader方法會(huì )把給定的一個(gè)name-values放到頭信息中，頭信息中只能有一個(gè)name-values，后面setHeader會(huì )覆蓋前面setHeader方法中的內容，一個(gè)name可以有多個(gè)value。

addHeader方法可以增加一個(gè)value到已有的name上，如果name不同就會(huì )新建一個(gè)name-values

頭可以包含一些信息，如日期或數字對象。

以下的一些方法用適當的數據類(lèi)型設置頭信息：

setIntHeader

setDateHeader

addIntHeader

addDateHeader

在響應被發(fā)送到客戶(hù)端之前，頭信息是必須被設置的，如果沒(méi)有設置頭信息，servlet引擎將不會(huì )發(fā)送該請求到客戶(hù)端。HTTP1.1規范沒(méi)有規定必須設置響應的頭信息。當程序員沒(méi)有設置響應體的Content-Type時(shí)，servlet引擎也不需要設置一個(gè)默認的類(lèi)型。

5.3 其他一些方法

HttpServletResonse接口中還有其他的一些方法：

sendRedirect

sendError

sendRedirect方法將設置合適的頭和體信息，用于重定向客戶(hù)端到另一個(gè)URL。如果sendRedirect參數是個(gè)相對路徑，則在底層servlet引擎中會(huì )把這相對路徑轉換成絕對路徑返回給客戶(hù)端的。

如果相對路徑不能被引擎轉換成絕對路徑就會(huì )拋出IllegalArgumentException錯誤。

sendError方法會(huì )把一條錯誤信息作為頭和體信息發(fā)送給客戶(hù)端。

如果在調用sendRedirect或sendError之前設置了頭和體信息，再調用sendRedirect或sendError時(shí)，之前的頭和體中的數據信息都將沒(méi)用，不會(huì )被發(fā)送到客戶(hù)端。如果使用了緩存，在調用sendRedirect或sendError時(shí)，之前的信息都將被清除。如果在commit之后調用sendRedirect或sendError就會(huì )拋出IllegalStateException錯誤。

5.4 國際化

當客戶(hù)端用一特殊的語(yǔ)言（或客戶(hù)端設置了語(yǔ)言）發(fā)出請求時(shí)，servlet會(huì )設置相應的響應語(yǔ)言信息，ServletResponse接口中設置響應語(yǔ)言的方法是setLocale。這個(gè)方法會(huì )設置一個(gè)合適的Content-Language到頭信息中。最好是開(kāi)發(fā)者在調用getWriter方法之前調用setLocale方法，確保返回的PrintWriter已經(jīng)被設置好了語(yǔ)言信息。如果在調用setLocale之后又調用了setContentType，setLocale中的內容將被setContentType中的字符集覆蓋。

response默認的編碼方式是“ISO-8859-1”。

5.5 response對象的關(guān)閉

當response被關(guān)閉時(shí)，引擎必須刷新該response緩存中的所有內容到客戶(hù)端。關(guān)閉的順序是：

1）關(guān)閉servlet的service方法

2）response 中setContentLength方法設置的指定數量的信息被寫(xiě)入response

3）調用sendError方法

4）調用sendRedirect方法

5.6 response對象的生命周期

每個(gè)response對象僅在servlet的serrvice方法或filter的doFilter的方法中有效。引擎重復使用reponse對象，是為了降低創(chuàng )建response對象的開(kāi)銷(xiāo)。開(kāi)發(fā)者必須注意response對象在指定范圍外可能出現的一些意外的行為。

6 Filtering

Fileter是servlet2.3新增的部分。這一章介紹Filter類(lèi)和方法，以及在web工程中的配置。

6.1什么是Fileter

Filter是重復使用的，用于變換HTTP請求和響應以及頭信息中的內容。Filter不能像servlet那樣創(chuàng )建response響應，但可以修改請求和響應的內容。

6.1.1例舉一些Filter

驗證Filter

登陸，審核Filter

圖像處理Filter

數據壓縮Filter

加密Filter

XSL/T Filter

MIME Filter

6.2 主要觀(guān)念

開(kāi)發(fā)者通過(guò)創(chuàng )建實(shí)現javax.servlet.Filter接口的類(lèi)，并提供一個(gè)沒(méi)有參數的構造函數來(lái)創(chuàng )建一個(gè)Filter。

在描述文件中Fileter用filter表示，調用方法用filter-mapping進(jìn)行配置。

6.3 Filter生命周期

在web工程發(fā)布后，在請求使引擎訪(fǎng)問(wèn)一個(gè)web資源之前，引擎必須定位Filter列表；引擎必須確保為列表中的每一個(gè)Filter建立了一個(gè)實(shí)例，并調用了他們的init(FilterConfig config)方法。在這過(guò)程中可以?huà)伋霎惓！?/span>

部署描述文件中定義的所有filter，僅會(huì )在引擎中產(chǎn)生一個(gè)實(shí)例。

引擎為filter提供了一個(gè)FilterConfig類(lèi)，該類(lèi)附有ServletContext和一個(gè)帶有初始化參數的set。

當引擎接受一個(gè)請求時(shí)，引擎就會(huì )調用filter列表中第一個(gè)filter的doFilter方法，把ServletRequest，ServletResponse和FilterChain作為參數傳給它。

filter中doFilter方法典型的處理步驟是：

1）檢查請求頭信息

2）開(kāi)發(fā)者創(chuàng )建一個(gè)實(shí)現了ServletRequest或HttpServletRequest的類(lèi)，去包裝request對象，以便修改請求的頭信息或體數據。

3）開(kāi)發(fā)者創(chuàng )建一個(gè)實(shí)現了ServletReqponse或HttpServletResponse的類(lèi)，去包裝response對象，以便修改請求的頭信息或體數據。

4)filter可以調用鏈中的下一個(gè)實(shí)體，下一個(gè)實(shí)體是另一個(gè)filter，如果該filter是列表中最后的一個(gè)，則它的下一個(gè)實(shí)體就是一個(gè)目標web資源。如果要調用下一個(gè)filter的doFilter方法，把request，和response對象傳給FilterChain對象的doFilter方法中就可以了。

Filter chain 的doFilter方法是由引擎提供的，引擎在該方法中會(huì )定位filter列表中的下一個(gè)filter，調用它的doFilter方法，把傳來(lái)的request和response對象傳給它。

5）在調用chain.doFilter之后，filter可以檢測響應的頭信息

6）在這些過(guò)程中，filter可以?huà)伋霎惓?。當在調用doFilter過(guò)程中拋出UnavailableException異常時(shí)，引擎重復嘗試處理下面的filter chain的方法，如過(guò)時(shí)后還沒(méi)請求到filter chain 就會(huì )關(guān)閉對filter chain的請求。

當filter是列表中最后一個(gè)filter時(shí)，它的下一個(gè)實(shí)體是描述配置文件中filter后面的servlet或其它資源。

在引擎刪除一個(gè)Filter之前，引擎必須調用Filter的destroy方法，來(lái)釋放資源。

6.3.1 包裝Requests 和Responsees

過(guò)濾的中心觀(guān)念是對request或response的包裝，在這種模式下，開(kāi)發(fā)者不僅可以改寫(xiě)存在的方法，還可以創(chuàng )建自己的新方法，用于特殊的過(guò)濾任務(wù)，例如：開(kāi)發(fā)者希望擴展response對象，希望有個(gè)更高層次的輸出流對象（writer）。

為了支持包裝模式，引擎不許保證在整個(gè)過(guò)濾鏈中，傳遞的request和response對象都是同一個(gè)對象。

6.3.2 Filter的環(huán)境

Filter的初始參數可以在描述配置文件中用init-params元素來(lái)配置，在運行時(shí)中，用FilterConfig的getInitParameter和getInitParamesterNames方法得到配置參數。

6.3.3 Filter在web工程中的配置

在部署描述文件中：

filter-name:filter名稱(chēng)

filter-class:filter類(lèi)路徑

init-params:用于初始化參數

如果開(kāi)發(fā)者在部署描述中為一個(gè)filter類(lèi)描述了兩個(gè)定義，則引擎會(huì )創(chuàng )建這個(gè)filter類(lèi)的兩個(gè)實(shí)例。

下面是個(gè)配置的例子:

<filter-name>Image Filter</filter-name>

<filter-class>com.acme.ImageServlet</fiflter-class>

</filter>

一旦filter在部署描述中定義，filter-mapping就可以被定義了，filter-mapping在web應用中是定義關(guān)聯(lián)filter的servlet和靜態(tài)資源的。

如：

<filter-mapping>

<filter-name>Image Filter</filter-name>

<servlet-name>ImageServlet</servlet-name>

</filter-mapping>

Image Filter 的 Filter就和ImageServlet 的Servlet建立了關(guān)聯(lián)。

Filter 可以和一群servlet和靜態(tài)資源關(guān)聯(lián)，用url-pattern。如：

<filter-mapping>

<filter-name>Loging Filter</filter-name>

<url-pattern>/*</url-pattern>

<filter-mapping>

引擎建立特殊請求URI的Filter鏈的順序是:

1)url-pattern映射fiter-mapping的順序和描述文件中定義的順序是一樣的。

2）servlet-name映射filter-mapping的順序和描述文件中定義的順序是一樣的。

這種需求要求引擎在接受請求時(shí)：

.識別符合SRV.11.2規則的web資源。

.如果一些filter是servlet和有servlet-name的web資源匹配的，引擎就會(huì )創(chuàng )建一個(gè)和描述文件中映射servlet-name的順序一樣的filter鏈。

.如果一些filter是rul-pattern關(guān)聯(lián)的，引擎就會(huì )創(chuàng )建一個(gè)和描述文件中映射url-pattern的順序一樣的efilter鏈。

一個(gè)高性能的web容器將會(huì )緩存filter鏈。

第七章 Sessions

超文本傳輸協(xié)議（HTTP）是無(wú)狀態(tài)的協(xié)議。要建立一個(gè)有效的web應用，客戶(hù)端之間的通信是需要的。有很多會(huì )話(huà)跟蹤的策略，

但是直接使用這些技術(shù)都很難使用。servlet規范中提供了一個(gè)簡(jiǎn)單的HttpSession接口，不需要開(kāi)發(fā)者關(guān)心會(huì )話(huà)跟蹤的具體細節。

7.1 會(huì )話(huà)跟蹤機制

下面描述了幾種會(huì )話(huà)的跟蹤機制

7.1.1 Cookies

HTTP cookies是最常用的會(huì )話(huà)跟蹤機制，所有的servlet引擎都應該支持這種方法。

引擎發(fā)送一個(gè)cookie到客戶(hù)端，客戶(hù)端就會(huì )在以后的請求中把這個(gè)cookie返回給服務(wù)器。用戶(hù)會(huì )話(huà)跟蹤的cookie的名字必須是JSESSIONID

7.1.2 SSL Sessions

在安全套接字層，加密技術(shù)用在了HTTPS協(xié)議，從一個(gè)客戶(hù)端來(lái)的多個(gè)請求允許用一個(gè)含糊的標識，servlet引擎就用這個(gè)數據定義一個(gè)Session。

7.1.3 URL重寫(xiě)

URL重寫(xiě)是最低性能的通用會(huì )話(huà)跟蹤方法。當一個(gè)客戶(hù)端不能接受cookie時(shí)，URL重寫(xiě)就會(huì )作為基本的會(huì )話(huà)跟蹤方法；URL重寫(xiě)包括一個(gè)附加的數據，一個(gè)session id，這樣的URL會(huì )被引擎解析和一個(gè)session相關(guān)聯(lián)。一個(gè)session id是作為URL的一個(gè)被編碼的參數傳輸的，這個(gè)參數名字必須是jsessionid.如下面的例子：

http://www.myserver.com/catalog/index.html;jsessionid=1234

7.1.4 會(huì )話(huà)的完整性

一個(gè)web容器必須支持HTTP 會(huì )話(huà)。而當cookies方法不被支持時(shí)，通常使用URL重寫(xiě)方法。

7.2 創(chuàng )建一個(gè)會(huì )話(huà)

servlet設計者必須考慮到一個(gè)客戶(hù)端不能加入session的情況。

7.3 會(huì )話(huà)范圍

HttpSession對象只在應用程序級有效，通常用于session的cookie可以服務(wù)于不同的上下文，但一個(gè)HttpSession實(shí)例只服務(wù)于一個(gè)會(huì )話(huà)。舉個(gè)例子：如一個(gè)servlet A用RequestDispatcher去調用另一個(gè)web應用中的另一個(gè)servlet B，用于A(yíng)和B的會(huì )話(huà)一定是兩個(gè)不同的會(huì )話(huà)。

7.4 Session屬性的邦定

一個(gè)servlet可以通過(guò)一個(gè)name邦定一個(gè)對象到HttpSession實(shí)例中；只要獲得包含同一個(gè)會(huì )話(huà)的請求對象，任何邦定到會(huì )話(huà)中的對象在同一個(gè)ServletContext中對于其它的servlet都是可用的。

當把一個(gè)對象放入session或從session刪除時(shí)可能要通知其它對象，這些信息能夠被實(shí)現了HttpSessionBindingListener接口的對象獲得，這個(gè)接口定義了一下的一些方法。

valueBound

valueUnbound

valueBound方法在HttpSession接口調用getAttribute方法獲得一個(gè)有效的對象之前調用。valueUnbound方法在HttpSession接口調用getAttribute方法獲得一個(gè)不再有效的對象后調用。

7.5 會(huì )話(huà)超時(shí)

在HTTP協(xié)議中，當客戶(hù)端不再有效時(shí)，沒(méi)有清楚的定義終止信號。這就意味著(zhù)通常只能采用時(shí)間超時(shí)來(lái)表明客戶(hù)端不再有效。

默認的超時(shí)時(shí)間是servlet引擎定義的，通過(guò)HttpSession的getMaxInactiveInterval方法可以得到超時(shí)的時(shí)間；開(kāi)發(fā)者可用用setMaxInactiveInterval方法來(lái)設置超時(shí)的時(shí)間，以秒定義的。如果一個(gè)session的超時(shí)時(shí)間被設置為-1，則這個(gè)session將永遠有效。

7.6 最后訪(fǎng)問(wèn)時(shí)間

在當前的請求中用HttpSession接口的getLastAccessedTime可以獲得最后一次訪(fǎng)問(wèn)session的時(shí)間。

7.7 重要session

7.7.1 線(xiàn)程問(wèn)題

在一個(gè)可以配置的應用中，所有的請求都是一個(gè)會(huì )話(huà)的一部分，引擎一定能夠取出通過(guò)setAttribute或putValue放入HttpSession對象中的對象。注意以下的情況：

.引擎一定能夠訪(fǎng)問(wèn)實(shí)現了Serializable接口的對象。

.引擎可以選擇存儲HttpSession對象中指定的對象，如EJB組件和事務(wù)。

.引擎能夠監聽(tīng)到會(huì )話(huà)的變動(dòng)。

如果放入session中的對象沒(méi)有被Seializable或沒(méi)有效，servlet可以?huà)伋鯥llegalArgumentException；如果引擎不支持Session存儲對象的機制，引擎一定會(huì )拋出IllegalArgumentException。

這些限制意味著(zhù)，在一個(gè)分布式引擎中，不會(huì )有額外的并發(fā)問(wèn)題。

如果引擎為了service的品質(zhì)持續化或遷移session，使用本地持續化的HttpSession或它的屬性是不受限制的，開(kāi)發(fā)者要想確保放入session中的屬性對象能夠可用，最好對象實(shí)現Serializable接口。

在遷移一個(gè)session時(shí)引擎必須通知session中實(shí)現了HttpSessinActivationListener的屬性對象，必須通知在序列化前鈍化的或序列化后激活的session的監聽(tīng)器。

開(kāi)發(fā)分布式的開(kāi)發(fā)者應該清楚的是，一旦引擎運行在超過(guò)一個(gè)JVM的時(shí)候，就不能用static 表明變量來(lái)存儲應用狀態(tài)，應該用EJB或數據庫賴(lài)存儲。

7.7.3客戶(hù)端

因為cookies或SSL證書(shū)都是被web瀏覽器訪(fǎng)問(wèn)過(guò)程控制的，與任何特殊的window瀏覽器是沒(méi)有關(guān)系的。所以從所有window客戶(hù)端到一個(gè)servlet引擎的請求是同一個(gè)會(huì )話(huà)的一部分。最好是開(kāi)發(fā)者總是設想所有的window客戶(hù)端是一起參與同一個(gè)會(huì )話(huà)的。

第八章 Dispatching Requests

當建立一個(gè)web應用時(shí)，把一個(gè)請求傳給另一個(gè)servlet或在response中包含另一個(gè)servlet的輸出是經(jīng)常使用的。RequestDispatcher接口就提供了一些方法。

8.1 獲得RequestDispatcher

實(shí)現了接口RequesetDispatcher接口的對象可以在ServletContext的getRequestDispatcher或getNamedDispatchcer方法得到。

getRequestDispatcher的參數是一個(gè)以根目錄‘/’開(kāi)始的一個(gè)路徑，該方法會(huì )查找路徑下的servlet，并把它封裝成RequestDispatchcer對象返回。

getNamedDispatcher方法把一個(gè)ServletContext知道的servlet名字作為參數，如果找到servlet，該servlet就被封裝成RequestDispatcher對象返回，如果沒(méi)有找到則返回null。

RequestDispatcher對象中使用相對路徑也是可以的。在ServletRequest中提供了getRequestDispatcher方法；這個(gè)方法和ServletContext中同名的方法功能類(lèi)似。servlet引擎會(huì )用request的信息把相對路徑轉化成完整路徑的。如ServleltRequest.getRequestDispatcher("header.html")和ServletConext.getRequestDispatcher("/garden/headere.html")是等效的。

8.1.1 在Request Dispatcher 路徑中附加字符串

在ServletContext和ServletRequest創(chuàng )建RequestDispatcher方法中參數都可以帶字符串如：

Context.getRequestDispatcher("/raisons.jsp?orderno=5");

8.2 Request Dispatcher的使用

對于使用Request Dispatcher 而言就是一個(gè)servlet調用include或forward方法，這些方法的參數是Servlet接口傳來(lái)的request和response對象實(shí)例。引擎必須確保調用Request Dispatcher的處理過(guò)程是在同一個(gè)JVM的同一個(gè)線(xiàn)程中。

8.3 include 方法

RequestDispatcher接口的include方法可以在任何時(shí)候被調用；目標servlet可以包含所有外的request對象，不過(guò)response對象的使用是有限制的：

response只能寫(xiě)信息到ServletOutputStream 或者Writer中，調用response對象的flushBuffer方法進(jìn)行提交。不能夠設置頭信息，任何方法都不會(huì )影響到response的頭信息。

8.3.1 被包含的request參數

除了可以用getNamedDispatcher方法包含一個(gè)servlet外，以下的屬性可以被設置：

Java.servlet.include.request_uri

Java.servlet.include.context_path

Java.servlet.include.servlet_path

Java.servlet.include.path_info

Java.servlet.include.query_string

用request對象的getAttribute方法可以獲取被包含servlet的以上屬性。

如果被包含的servlet能后通過(guò)getNamedDispatcher方法找到就不必設置以上屬性了。

8.4 Forward 方法

RequestDispatcher接口中的forward方法，只有servlet沒(méi)有提交響應到客戶(hù)端時(shí)才可用；如果響應buffer中有數據還沒(méi)有提交，當調用forward方法中目標servlet的service方法前，buffer中的內容會(huì )被清空；如果buffer中的數據提交了，則發(fā)生IllegalStateException錯誤。

request對象的路徑必須放映獲取RequestDispatcher對象的路徑。

有個(gè)例外，如果RequestDispatcher是通過(guò)getNamedDispatcher方法得到的，request對象必須反映原始request的路徑。

在RequestDispatcher接口方法forward返回前，response的內容必須被提交，并由引擎關(guān)閉該servlet。

8.4.1 query String

在Request Dispatcher中創(chuàng )建的路徑是可以帶參數的。

8.5 錯誤

如果request Dispatcher的目標servlet拋出運行時(shí)錯誤或ServletException 或IOException，錯誤就會(huì )被傳給調用的servlet；在上傳之到調用的servlet之前，所有其他的exception都應該包裝成ServletExceptions。

第九章 web 應用

一個(gè)web應用是一堆servlet，html頁(yè)面，類(lèi)和其他資源的集合。web應用可以被發(fā)布運行在很多服務(wù)提供商的多種引擎下。

9.1 web服務(wù)器

在web服務(wù)中一個(gè)web應用的根目錄是一個(gè)特殊的路徑，例如：一個(gè)網(wǎng)站目錄可以以http://www.mycorp.com/登錄，所有的請求都將以這個(gè)作為前綴發(fā)送到以這個(gè)前綴描述的servletContext環(huán)境中。

在任何時(shí)候一個(gè)web應用的實(shí)例只能運行在一個(gè)JVM中。

9.2 和servletContext的關(guān)系

servlet引擎會(huì )強迫web應用和ServletContext的通信，一個(gè)ServletContext對象提供了一個(gè)servlet使得該應用可見(jiàn)。

9.3 web應用中的元素

一個(gè)web應用包含以下的元素：

.Servlets

.JSP

.Utility Classes

.Static documents(html,images,sounds,etc)

.Client side Java applets,beans,and classes

.Descriptive meta informateion

9.4 部署層次

這個(gè)協(xié)議定義了一個(gè)層次結構，用于部署和打包，這個(gè)結構存在于一個(gè)文件中。

9.5 目錄結構

一個(gè)web應用存在一個(gè)目錄層次結構。文件根目錄是應用的一部分。例如：一個(gè)web應用的上下文路徑是/catalog，web應用的index.html文件就能被/catalog/index.html請求訪(fǎng)問(wèn)。URL和上下文路徑的匹配規則將在11章討論。servlet引擎必須拒絕一個(gè)具有現在沖突的上下文路徑的web應用，這種情況是有的，如：兩個(gè)web應用發(fā)布在同一個(gè)上下文路徑中，或一個(gè)web應用的上下文路徑是另一個(gè)web應用上下文路徑的子路徑。

有一個(gè)特殊的目錄（“WEB-INF”）在應用中存在，這個(gè)目錄包含所有與應用相關(guān)，又不在根目錄中的事物?？梢灾苯颖灰嫣峁┙o客戶(hù)端的文件不放在WEB-INF中，但WEB-INF目錄對于調用ServletContext的getResource和getResourceAsStream方法的servlet 代碼是有效的。如果開(kāi)發(fā)者想用servlet代碼調用一個(gè)不希望暴露給客戶(hù)端的一個(gè)配置信息，就可以把這個(gè)配置信息放在WEB-INF目錄下。請求都是和資源相匹配的；敏感的匹配如客戶(hù)端的請求是“/WEB-INF/foo”和“/Web-iNf/foo”，但不應該把定位于/WEB-INF下的內容作為結果返回。

WEB-INF目錄下的內容有：

./WEB-INF/web.xml 部署描述文件

./WEB-INF/classes/ 存放servlet class

./WEB-INF/lib/*.jar 是jar包的目錄

應用的classloader先load WEB-INF/classes目錄下的class后load WEB-INF/lib目錄下的jar包

9.5.1 目錄結構的一個(gè)例子

一個(gè)簡(jiǎn)單web應用的目錄結構：

/index.html

/howto.jsp

/images/banner.gif

/images/jumping.gif

/WEB-INF/web.xml

/WEB-INF/lib/jspbean.jar

/WEB-INF/classes/com/mycorp/servlets/MyServlet.class

/WEB-INF/classes/com/util/MyUtils.class

9.6 web應用的存檔文件

一個(gè)web應用可以被java打包工具打包成war文件，當被打包后包中就會(huì )有一個(gè)額外META-INF目錄，該目錄下存放了打包工具的一些信息。

9.7 web應用部署描述

下面是web應用部署描述中的配置類(lèi)型：

.ServletContext Init Parameters

.Session Configuration

.Servlet / JSP Definitions

.Servlet / JSP Mappings

.MIME Type Mappings

.Welcome File list

.Error Pages

.Security

9.7.1 可靠的擴展

web容器須提供一種機制使得web應用知道jar文件中包含的有用資源或代碼。

引擎因該提供編輯、配置庫文件的程序。

在WAR中提供一個(gè)MANIFEST.MF文件，描述擴展名列表是比較好的。標準的JAR是應該有的，這個(gè)文件描述的擴展名應該遵循Http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html中的規定。web容器應該能夠識別WEB-INF/lib文件夾中的任何文件的擴展名，如果不能夠識別就應該拒絕該應用程序，并報出錯誤。

9.7.2 web應用的classloader

引擎用于裝載war中的servlet的裝載器必須能夠讓開(kāi)發(fā)者裝載jar庫中的任何資源。但裝載的資源禁止覆蓋j2se或servlet API中的類(lèi)；通常建議的做法是裝載器不允許war中的servlet去訪(fǎng)問(wèn)web引擎中的類(lèi)。

還有一個(gè)被推薦的做法是實(shí)現應用類(lèi)裝載器，war中被裝載的類(lèi)或資源就會(huì )被放到container-wide JAR庫的特定類(lèi)或資源中。

9.8 替換web應用

一個(gè)服務(wù)器可能會(huì )在不重新啟動(dòng)引擎的情況下用一個(gè)新版本的應用替換原有的應用。當一個(gè)應用被替換時(shí)，引擎應提供一個(gè)robust方法去保存該應用中的session

9.9 錯誤句柄

9.9.1 request Attributes

web應用必須列出在使用中資源發(fā)生的錯誤，這些資源在部署描述中都有定義。

如果錯誤在一個(gè)servlet或一個(gè)jsp頁(yè)面中發(fā)生，則在第9.1章中的如下的請求屬性就會(huì )被設置：

Request Attributes Type

Javax.servlet.error.status_code java.lang.Integer

Javax.servlet.error.exception_type java.lang.Class

Javax.servlet.error.message java.lang.String

Javax.servlet.error.exception java.lang.Throwable

Javax.servlet.error.request_uri java.lang.String

Javax.servlet.error.servlet_name java.lang.String

這些屬性允許這個(gè)servlet根據這些狀態(tài)碼、錯誤類(lèi)型、錯誤信息、被拋出的錯誤對象、錯誤產(chǎn)生的servlet被訪(fǎng)問(wèn)的URI（可以用getRequestURI得到）、或錯誤產(chǎn)生的servlet的邏輯名稱(chēng)產(chǎn)生特殊的內容。

在2.3版本中錯誤類(lèi)型和錯誤信息屬性是多余的，他們被保留只是為了向下兼容以前的版本。

9.9.2 錯誤頁(yè)面

當一個(gè)servlet產(chǎn)生錯誤時(shí)，開(kāi)發(fā)者可以訂制錯誤內容返回給客戶(hù)端。部署描述文件定義了一個(gè)錯誤頁(yè)面列表。servlet在response中設置錯誤狀態(tài)碼或產(chǎn)生的異?；蝈e誤被引擎支持時(shí)，引擎就會(huì )從部署描述文件中調用相應的配置的錯誤資源。

如果一個(gè)錯誤碼被設置在了response中，引擎在部署描述文件的錯誤頁(yè)面列表中用status-code方式匹配對應的資源，如果找到就調用本地的資源。

在一個(gè)請求被處理的過(guò)程中servlet可以?huà)伋鲆韵碌漠惓＃?/span>

.runtime exceptions or errors

.ServletExceptions or subclasses thereof

.IOException or subclasses thereof

web應用可以用exception-type元素來(lái)描述錯誤頁(yè)面，在這種情況下引擎會(huì )通過(guò)比較用exception-type元素定義的error-page列表中的異常來(lái)匹配產(chǎn)生的異常。匹配的結果是返回定義的與錯誤匹配的本地資源。在繼承類(lèi)中，最近的類(lèi)將被調用。

如果沒(méi)有一個(gè)error-page包含的exception-type與class-heirarchy相匹配。拋出的ServletException或其子類(lèi)異常，被引擎通過(guò)ServletException.getRootCause方法獲得，獲得后用這個(gè)異常再去配置的error page列表中去匹配。

在部署描述文件中用exception-type元素定義的Error-page中exception-type的類(lèi)名必須是唯一的。

當錯誤發(fā)生在servlet調用的RequestDispatcher中時(shí)error page機制是不能夠干預到的；這樣的情況如：一個(gè)servlet用RequestDispatcher去調用另一個(gè)有錯誤的servlet。

如果一個(gè)servlet產(chǎn)生的錯誤沒(méi)有被描述的錯誤頁(yè)面機制所抓到，引擎必須設置response的狀態(tài)碼為500

9.10 Welcome Files

web應用可以在部署描述文件中定義一個(gè)welcome files調用的URI列表，這個(gè)機制的目的是允許開(kāi)發(fā)者定義自己的訪(fǎng)問(wèn)首頁(yè)。

如果沒(méi)有在部署描述中配置welcome 文件,引擎將把局部請求（沒(méi)有指明具體訪(fǎng)問(wèn)資源，如www.cacolg.com/index.html,請求訪(fǎng)問(wèn)時(shí)用www.cacolg.com/訪(fǎng)問(wèn)的）發(fā)送到適當的資源中，如：一個(gè)可能默認的servlet，或列出該目錄下的文件列表，或返回404響應錯誤。

一個(gè)例子：

1）在部署描述中定義index.html和default.jsp為welcome files

2）定義一個(gè)servlet的mapping路徑為/foo/

WAR中有的文件如下：

/foo/index.html

/foo/default.html

/foo/orderform.html

/foo/home.gif

/catalog/default.jsp

/catalog/products/shop.jsp

/catalog/products/register.jsp

3）請求的URI為處理后的URI

/foo 或 /foo/ /foo/index.html

/catalog/ /catalog/default.jsp

/catalog/index.html 404 not found

/catalog/products/ 404 not found 也可能返回shop.jsp and /or register.jsp 列表。

9.11 web應用環(huán)境

j2EE定義的命名環(huán)境能夠使得應用在不需要知道外部信息怎么命名的情況下比較方便的訪(fǎng)問(wèn)資源或外部信息。

servlet作為j2EE完整的一部分，使web應用部署描述文件提供了一個(gè)servlet可以訪(fǎng)問(wèn)資源和EJB，這些部署描述元素有：

.env-entry

.ejb-ref

.ejb-local-ref

.resource-ref

.resource-env-ref

開(kāi)發(fā)者使用這些元素描述web應用中需要用到的對象，這些對象都要在web容器運行時(shí)注冊到JNDI命名空間。

在J2EE1.3版本j2EE的環(huán)境需求中，servlet引擎不是J2EE技術(shù)的一部分，web環(huán)境要提供的功能在J2EE規范中有描述。如果沒(méi)有實(shí)現支持環(huán)境所要提供的功能，在發(fā)布應用時(shí)，web容器就會(huì )拋出警告。

實(shí)現servlet引擎在J2EE中是需要的，應該被納入J2EE1.3中。J2EE1.3應該提供更多的內容。

servlet引擎必須支持對象的lookup方法，查找對象并在引擎控制的線(xiàn)程中實(shí)例化。

servlet引擎應該支持開(kāi)發(fā)者創(chuàng )建的線(xiàn)程，因為應用創(chuàng )建的線(xiàn)程不是很輕便，開(kāi)開(kāi)發(fā)者不得不依賴(lài)于這些功能有限的線(xiàn)程。這些需求將被加入到下一個(gè)版本的servlet規范中。

第十章應用周期事件

10.1 介紹

事件是servlet2.3種新添的內容。應用事件使得web開(kāi)發(fā)者能夠控制ServletContext和HttpSession對象的信息交互，使得管理web使用的資源更有效，方便。

10.2 事件監聽(tīng)器

事件監聽(tīng)器是實(shí)現了servlet事件監聽(tīng)接口的類(lèi)。在web發(fā)布是這些監聽(tīng)類(lèi)就被實(shí)例化和注冊在web容器中。

servlet事件監聽(tīng)器提供了在ServletContext和HttpSerssion對象狀態(tài)發(fā)生改變時(shí)觸發(fā)的事件。Servlet cotext監聽(tīng)器用于管理應用的資源或虛擬機的狀態(tài)。HTTP session監聽(tīng)器管理與會(huì )話(huà)關(guān)聯(lián)的資源。

可以有多個(gè)監聽(tīng)器監聽(tīng)每一個(gè)事件類(lèi)型。開(kāi)發(fā)者可以指定引擎調用監聽(tīng)類(lèi)的順序。

10.2.1 事件類(lèi)型和監聽(tīng)接口

Event Type ListenerInterface 說(shuō)明

Lifecycle javax.servlet.ServletContextListener 當servlet context被創(chuàng )建并有效的接受第一個(gè)請求

或servlet context銷(xiāo)毀前

Changes to attributees javax.servlet.ServletContextAttributesListener 當servlet context中的屬性發(fā)生added,removed,replaced

Lifecycle javax.servlet.http.HttpSessionListener 當HttpSession被創(chuàng )建，無(wú)效或超時(shí)

Changes to attributes javax.servlet.HttpSessionAttributesListener 當屬性added,removed或replaced時(shí)

10.2.2 一個(gè)使用監聽(tīng)的例子

一個(gè)簡(jiǎn)單的web應用中有servlet要訪(fǎng)問(wèn)數據庫，開(kāi)發(fā)者提供一個(gè)context 監聽(tīng)類(lèi)管理數據庫連接。

1）web應用啟動(dòng)時(shí)，監聽(tīng)類(lèi)被裝載，登陸數據庫，在servlet context中保存數據庫連接。

2）servlet訪(fǎng)問(wèn)數據庫連接

3）當web服務(wù)銷(xiāo)毀時(shí)，或應用從web服務(wù)中刪除時(shí)，關(guān)閉數據庫連接。

10.3 監聽(tīng)類(lèi)的配置

10.3.1 對監聽(tīng)類(lèi)的規定

web開(kāi)發(fā)者提供實(shí)現了以上監聽(tīng)接口的類(lèi)，每個(gè)類(lèi)應該有一個(gè)沒(méi)有參數的構造器函數。監聽(tīng)類(lèi)放在WEB-INF/classes下或以一個(gè)jar文件放在WEB-INF/lib下都可以。

10.3.2 部署描述

web容器對每個(gè)監聽(tīng)類(lèi)只會(huì )創(chuàng )建一個(gè)實(shí)例，在第一個(gè)請求到來(lái)之前實(shí)例化并注冊。web容器注冊監聽(tīng)類(lèi)的順序根據他們實(shí)現的接口和在部署描述文件中定義的順序。web應用調用監聽(tīng)實(shí)例的順序按照他們注冊的順序。

10.3.4 在銷(xiāo)毀時(shí)的事件

當應用銷(xiāo)毀時(shí)監聽(tīng)事件的執行順序按部署描述中的順序，先執行session中的監聽(tīng)事件再執行context中的監聽(tīng)事件。session的無(wú)效事件必須在context的銷(xiāo)毀事件之前被調用。

10.4 部署描述的例子

下面給出注冊?xún)蓚€(gè)servlet cocntext lifecycle監聽(tīng)器和一個(gè)HttpSession監聽(tīng)器的例子。

Com.acme.MyconnectionManager和com.acme.MyLoggingMoudule都實(shí)現了javax.servletServletContextListener接口,com.acme.MyloggingModule另外還實(shí)現了javax.servlet.HttpSessionListener接口。開(kāi)發(fā)者希望com.acme.MyConnectionManager在com.acme.MyLoggingModule之前管理者servlet context 的生命周期事件。部署描述文件如下：

<web-app>

<display-name>MyListeningApplication</display-name>

<listener-class>com.acme.MyConnectionManager</listener-class>

</listenrer>

<listenrer-class>com.acme.MyLoggingModele</listener-class>

</listener>

<display-name>RegistrationServlet</display-name>

..etc

</servlet>

</web-app>

10.5 監聽(tīng)器的實(shí)例和線(xiàn)程

在第一個(gè)請求被web容器接受之前實(shí)例化并注冊好監聽(tīng)器類(lèi)是必須的。監聽(tīng)器在整個(gè)web應用生命周期中都要使用。

ServletContext和HttpSession對象屬性的改變可能會(huì )同時(shí)產(chǎn)生，引擎不需要同步這些屬性類(lèi)的事件。

10.6 分布式容器組

在分布式web容器組中，HttpSession和ServletContext實(shí)例只活動(dòng)與它們本地的JVM中。在分布式web容器中，監聽(tīng)實(shí)例會(huì )在每一個(gè)web容器中創(chuàng )建實(shí)例。

10.7 session事件

監聽(tīng)器使得開(kāi)發(fā)者可以跟蹤web應用中的session。知道session是否變得無(wú)效是經(jīng)常被用到的，因為session超時(shí)時(shí)引擎會(huì )使session變得無(wú)效，或應用會(huì )調用invalidate方法。

第十一章請求到servlet的映射

11.1 URI的使用

web容器根據客戶(hù)端的請求決定要調用的資源。

URL路徑映射規則是第一個(gè)匹配成功就不再匹配了。

1）引擎將盡力為每一個(gè)請求一個(gè)servlet的路徑匹配一個(gè)servlet

2）引擎將遞歸的匹配最長(cháng)的路徑前綴（在一個(gè)目錄樹(shù)中）

3）如果在URL路徑中的最后一節有擴展名（例如：.jsp），則servlet引擎將會(huì )匹配一個(gè)適當的servlet獲取請求對象

4）如果沒(méi)有一個(gè)servlet能夠匹配請求，引擎將用一個(gè)適當的資源來(lái)處理該請求。如：在應用中配置了默認的servlet，就會(huì )被用來(lái)處理匹配不到資源的請求。

11.2 匹配規則

在web應用描述文件中，匹配的定義如下：

.以‘/‘開(kāi)始，以‘/*‘為結尾的字符串,用作路徑匹配

.以‘*.‘開(kāi)始的字符串，用作擴展名匹配

.包含‘/‘字符串，定義一個(gè)默認的servlet。如匹配的servlet路徑是請求URI路徑的最小上下文路徑，路經(jīng)的info為空。

.其它的字符串用作精確的匹配。

11.2.1 絕對匹配

servlet引擎能夠匹配任何精確的資源，如后綴為*.jsp的匹配，引擎中有JSP引擎的話(huà)，就會(huì )把所有的JSP頁(yè)面和與之對象的資源相匹配。

11.2.2 匹配的例子：

path pattern servlet

/foo/bar/* servlet1

/baz/* servlet2

/catalog servlet3

*.bop servlet4

incoming path servlet handling request

/foo/bar/index.html servlet1

/foo/bar/index.bop servlet1

/baz servlet2

/baz/index.html servlet2

/catalog servlet3

/catalog/racecar.bop servlet4

/index.bop servlet4

第十二章安全

12.1介紹

web應用的資源能夠被很多的用戶(hù)訪(fǎng)問(wèn)，這些資源經(jīng)常沒(méi)有保護的暴露在網(wǎng)絡(luò )中，因此一個(gè)穩定的web應用需要一個(gè)安全的環(huán)境。

提高安全性有以下的幾個(gè)方面：

.認證：訪(fǎng)問(wèn)一個(gè)實(shí)例前需要一個(gè)特殊的ID進(jìn)行授權認證后才能訪(fǎng)問(wèn)該實(shí)例

.資源的訪(fǎng)問(wèn)控制：一些機密資源或局部資源只限制給某些用戶(hù)或程序使用。

.數據完整性：在傳輸過(guò)程中數據不能被意外的改變。

.機密性：確定信息只能被授權過(guò)的用戶(hù)使用。

12.2 公共安全

安全性聲明是指表明應用是有安全結構的；包括權限、訪(fǎng)問(wèn)控制、認證。在web應用中部署描述是安全聲明的主要工具。

開(kāi)發(fā)者應該為應用運行時(shí)配一個(gè)邏輯安全策略，在運行時(shí)中，servlet引擎用這個(gè)安全策略去驗證授權請求。

安全模塊應該適用web應用的靜態(tài)內容，當servlet用RequestDispatcher調用一個(gè)靜態(tài)資源或servlet用forward或include,時(shí)安全模塊不適用。

12.3 程序級安全

當應用的安全模塊不能充分的表明安全時(shí)程序安全就可以被使用。

程序安全有以下部分組成：

HttpServletRequest接口：

.getRemoteUser

.isUserInRole

.getUserPrincipal

getRemoteUser方法返回客戶(hù)端用戶(hù)的名稱(chēng)，用于授權。

isUserInRole方法判斷遠程用戶(hù)是否在一個(gè)安全的角色內。

getUserPrincipal方法返回一個(gè)java.security.Principal對象，表明當前用戶(hù)的主要名稱(chēng)。這個(gè)API允許servlet根據這個(gè)信息處理一些業(yè)務(wù)邏輯。

如果用戶(hù)沒(méi)有授權，getRemoteUser返回null，isUserInRole返回false，getUserPrincipal返回null。

isUserInRole以一個(gè)role-name為參數。一個(gè)security-role-ref元素為在部署描述文件中定義，role-name子元素包含角色名稱(chēng)。Security-role包含一個(gè)子元素role-link,role-link的value值是客戶(hù)端用戶(hù)將匹配的安全角色。當用isUserInRole時(shí)引擎將調用security-role-ref到security-role的匹配。

舉個(gè)例子：

<security-role-ref>

<role-name>FOO</role-name>

<role-link>manager</role-link>

</security-role-ref>

當一個(gè)用戶(hù)屬于“manager”角色是調用isUsesrInRole("FOO")返回true

如果匹配一個(gè)security-role元素的security-role-ref沒(méi)有被定義，引擎必須找出一個(gè)與security-role列表不同的roel-name元素作為web應用默認的安全角色。但默認的安全角色限制了變換角色名稱(chēng)不需要重新編譯的機動(dòng)性。

12.4 角色

一個(gè)安全角色是一組用戶(hù)的邏輯名稱(chēng)。當應用發(fā)布時(shí)，角色就部署在web應用的運行時(shí)環(huán)境中了。在基于安全屬性的請求到來(lái)時(shí)，servlet引擎就會(huì )執行公共安全或程序級安全。安全請求在以下的一些情況中會(huì )產(chǎn)生：

1）開(kāi)發(fā)者給用戶(hù)群配置了一個(gè)安全角色。

2）開(kāi)發(fā)者把一個(gè)安全角色配置給一個(gè)安全域中的一個(gè)主要名稱(chēng)。

12.5 驗證

web客戶(hù)端可以用以下的一些機制驗證用戶(hù)：

.HTTP Basic Authentication

.HTTP Digest Authentication

.HTTPS Client Authentication

.Form Based Authentication

12.5.1 HTTP Basic Authentication

HTTP Basic Authentication是基于用戶(hù)名和密碼的驗證機制，是在HTTP/1.0規范中定義的。web服務(wù)要求客戶(hù)端驗證用戶(hù)，web服務(wù)用一個(gè)realm字符串作為請求的一部分，用戶(hù)通過(guò)這個(gè)realm字符串被驗證。realm字符串不會(huì )和任何安全域相關(guān)聯(lián)?？蛻?hù)端獲得用戶(hù)名稱(chēng)和密碼發(fā)送到服務(wù)端。然后服務(wù)端用一個(gè)特殊的realm去驗證該用戶(hù)。

Basic Authentication 不是安全的驗證協(xié)議。用戶(hù)的密碼是用base64編碼的，服務(wù)端是不能夠識別的。一些附加的安全措施可以被使用，這些協(xié)議有：HTTPS安全傳輸協(xié)議或網(wǎng)絡(luò )安全標準（如IPSEC協(xié)議、VPN策略）。

12.5.2 HTTP Digest Authentication

和HTTP Basic Authentication一樣，HTTP Digest Authentication 也是驗證用戶(hù)名和密碼的。然而這種驗證是把密碼加密傳輸的，要比Basic Authentication的base64編碼要安全的多。Digest Authentication 沒(méi)有被廣泛的運用，建議servlet引擎支持這種驗證，但不是必須的。

12.5.3 Form Based Authentication

web應用部署描述文件包含登陸表單和錯誤頁(yè)面。登陸表單必須包含用戶(hù)名和用戶(hù)密碼字段，這兩個(gè)字段必須以j_username和j_password命名。當一個(gè)用戶(hù)要訪(fǎng)問(wèn)一個(gè)被保護的資源時(shí)，引擎就會(huì )驗證該用戶(hù)信息，如果該用戶(hù)驗證通過(guò)就會(huì )調用保護的資源，如果沒(méi)有驗證通過(guò)，以下的步驟就會(huì )發(fā)生：

1）登陸表單被送到客戶(hù)端，啟動(dòng)這個(gè)驗證的URL路徑將被引擎保存。

2）用戶(hù)被要求填寫(xiě)用戶(hù)名和密碼

3）客戶(hù)端重新post表單到服務(wù)端

4）引擎嘗試著(zhù)重新去驗證該用戶(hù)的信息

5）如果驗證有失敗，響應被設置為401的錯誤頁(yè)面將被返回

6）如果驗證成功，如果該訪(fǎng)問(wèn)的資源在一個(gè)授權角色中，將進(jìn)一步驗證。

7）如果用戶(hù)是授權用戶(hù)，客戶(hù)端將用保存的URL路徑重新定向到訪(fǎng)問(wèn)的資源。

發(fā)送到驗證失敗的用戶(hù)的錯誤頁(yè)面包含了失敗的信息。

Form Based Authentication 和 Basic Authentication 有一樣的弊端，密碼是用簡(jiǎn)單的文本傳輸的，不能夠被服務(wù)端驗證。附加的一些協(xié)議可以增強這部分功能。如HTTPS傳輸協(xié)議，或網(wǎng)路安全標準（如IPSEC協(xié)議或VPN策略）。

12.5.3.1 登陸表單的一些注意事項

登陸的表單和跟蹤session的URL實(shí)現上是有限制的。

登陸表單只能在cookies或SSL跟蹤session的方式下才能使用。

登陸表單要進(jìn)行驗證的話(huà)，表單的action就必須為j_security_check。這個(gè)約束使得登陸表單訪(fǎng)問(wèn)的資源沒(méi)有問(wèn)題，也避免了把表單外的字段提交進(jìn)請求中。

在HTML頁(yè)面中登陸表單的一個(gè)例子如下：

</form>

當登陸表單因為HTTP請求被調用時(shí)，原始的請求參數必須被引擎存儲，在驗證成功后重新定向請求的資源。

如果用登陸表單的用戶(hù)被驗證通過(guò)，創(chuàng )建了一個(gè)session,當session超時(shí)或調用了失效方法，使得登陸者推出了。后續來(lái)的請求就必須重新對用戶(hù)進(jìn)行驗證。

12.5.4 HTTPS Client Authentication

用HTTPS驗證用戶(hù)是很強的驗證機制。這個(gè)驗證需要用戶(hù)擁有一個(gè)公共鑰匙（PKC）。servlet引擎不需要支持HTTPS協(xié)議。

12.6 驗證信息的跟蹤

基本的身份驗證實(shí)在運行時(shí)環(huán)境中進(jìn)行的：