Servlet Specification V2.4——SRV.4 The Request

SRV.4 The Request

        Request對象壓縮了來自客戶端request的全部信息。根據HTTP協議，這些信息存放在HTTP header和request的message body中，從客戶端傳送至服務器。

 

 

SRV.4.1 HTTP Protocol Parameters

        做爲request的一部分，servlet的request參數是client發送給servlet container的字符串。當request是一個HttpServletRequest對象，而且知足SRV4.1.1 When Parameters Are Available的條件，container會從URI查詢字符串和POST-ed數據中取得參數。
        參數以name-value鍵值對的形式被存儲。任何給定的參數名均可以被賦予多個參數值。下面是 ServletRequest接口用來存取參數的方法：

• getParameter

• getParameterNames

• getParameterValues

• getParameterMap

        getParameterValues方法返回了一個包含了與指定參數名稱綁定的全部參數值String對象數組。getParameter方法的返回值必定是getParameterValues方法返回的String對象數組中的第一個String。getParameterMap方法返回了以java.util.Map表示的request中的全部參數，其中key爲參數名稱，map value是參數值。
        來自查詢字符串的數據和post body都存放在request的參數集合中。查詢字符串出如今post body以前。例如，一個request的query string爲a=hello，post body裏有a=goodbye&a=world，那麼結果參數集合就會以a=(hello, goodbye, world)的順序呈現。
        做爲GET request的一部分（由HTTP1.1定義），路徑參數並不被這些API暴露。他們必須經過getRequestURI方法或getPathInfo方法返回的String values被分析。

 

SRV.4.1.1 When Parameters Are Available

如下條件是在post form數據在被移至參數集合以前必須知足的條件：

1. request是HTTP/HTTPS request

2. HTTP method是POST。

3. content type是application/x-www-form-urlencoded。

4. servlet已經對request對象中全部getParameter能夠獲得的參數作了初始化調用。

        若是條件不知足而且post form數據並無包含在參數集合中，對於servlet來講，post數據仍然是可用的，能夠經過request對象的輸入流得到（the post data must still be available to the servlet via the request object's input stream）。當條件知足，post form數據將不能再從request對象的輸入流中直接讀取。

 

 

SRV.4.2 Atributes

        attribute是綁定在request上的一些對象。Attribute能夠由container set到request中，用來表達不能經過API表達的信息；或者由servlet set到request中，用來和其餘servlet通信（經過RequestDispatcher）。Attribute能夠經過ServletRequest接口的如下方法來存取：

• getAttribute

• getAttributeNames

• setAttribute

        attribute的value和name是一一對應的。
        根據規範的定義，前綴爲{[java.], [javax.]}的attribute是被本規範保留的。一樣的，前綴爲{[sun.], [com.sun.]}的attribute被sun公司保留。關於全部放到attribute集合中的attribute的命名，通常建議與Java Programming Language Specification關於package命名建議保持一致，也就是域名反序排列。

 

 

SRV.4.3 Header

Servlet能夠經過HttpServletRequest接口的如下方法存取HTTP request的header信息：

• getHeader

• getHeaders

• getHeaderNames

        getHeader方法返回以入參爲名稱的header。多個header能夠有一樣的名字，例如，Cache-Control headers，在HTTP request中。若是多個header擁有相同的名字，getHeader方法返回request中第一個header。getHeaders方法容許存取以入參爲header name的全部的header值，返回一個String對象的枚舉類型。
        Headers能夠包含int或者Date類型數據的String表達。如下是HttpServletRequest接口中能夠以某種格式存取header數據的便捷方法:

• getIntHeader

• getDateHeader

        若是getIntHeader方法不能把header中的值轉換成int類型的數據，就會拋出NumberFormatException。若是getDateHeader方法不能把header轉換成Date類型的數據，就會拋出IllegalArgumentException。

 

 

 

SRV4.4 Request Path Elements

        引導servlet處理request的request路徑由不少重要的部分組成。下面的元素經過request對象獲取request URI路徑再被解析而獲得：

• Context Path:context path前綴與當前servlet所屬的servlet context相關。若是這個context是位於web server的URL name space的根節點的「默認」context，那這個path就是一個空字符串。不然，若是context部位於server的URL name space根節點，那context path就是以字符'/'開始，以字符'/'結束但包括'/'的一段字符。

• Servlet Path:servlet path是直接激活request與servlet的映射的部分。以字符'/'開始，除了在request匹配'/*'模式的狀況下。在這種狀況下，它是個空字符串。

• PathInfo:這部分的request path既不是context path，也不是servlet path。它要麼在沒有額外的path時爲空，要麼就是以'/'開頭的字符串。

        如下爲HttpServletRequest的一些方法，用來存取這些信息：

• getContextPath

• getServletPath

• getPathInfo

        重點須要注意的是，除了URL編碼不一樣於request URI和路徑部分，如下的方程式爲恆等式：requestURI =  contextPath + servletPath + pathInfo

        如下是一些例子，用來闡明以上的要點：見圖SRV.4.4 - 01.png，SRV.4.4 - 02.png

 

 

SRV.4.5 Path Translation Methods

        開發者能夠地經過API中的兩個便捷方法來得到等價於特定路徑的文件系統路徑(obtain the file system path equivalent to a particular path)。這些方法是：

• ServletContext.getRealPath

• HttpServletRequest.getPathTranslated

        getRealPath方法以一個String爲參數，返回一個表明了本地文件系統上的文件的String表達形式，一個符合文件位置的路徑。getPathTranslated方法計算了request的pathInfo的真實路徑。
        在servlet container不能爲這些方法找到一個和法文件路徑的狀況下，好比web應用程序從一個存檔文件中被執行，在本地無發存取的遠程文件系統上，或者在數據庫中，這些方法會返回null。

 

 

SRV.4.6 Cookies

        HttpServletRequest接口提供了getCookies方法來得到request中現存的cookie數組。這些cookie是每一次客戶端發起請求時client發起送至server的的數據。通常來講，做爲cookie的一部分client返回的惟一信息就是cookie的name和value。其餘在cookie被髮送至瀏覽器是能夠被set的cookie屬性，好比註釋，並非典型的返回信息。

 

 

SRV.4.7 SSL Attributes

        若是request經過安全協議傳送，就像HTTPS，這個信息必須經過ServletRequest接口的isSecure方法被呈現。Web container必定會呈現如下的attribute給servlet程序員：見圖SRV.4.7 - 01.png。

        若是有一個SSL證書與request相關聯，它必定會被servlet container做爲java.security.cert.X509Certificate類型的對象數組展現給servlet開發者，而且經過ServletRequest的attribute javax.servlet.request.X509Certificate被訪問。
        數組定義的書序是配用來驗證的列表(The order of this array is defined as being in ascending order of trust)。數組中的第一個證書是被客戶端set的，接下來的一個用來驗證第一個證書，這樣一直日後排。

 

 

SRV.4.8 Internationalization

        若是願意，客戶端能夠選擇以它喜歡的語言得到從web服務器返回的response。服務器可使用Accept_Language header從客戶端得到這些信息並進行通信，經過使用HTTP/1.1規範中描述的其餘機制。(This information can be communicated from the client using the Accept-Language header along with other mechanisms described in the HTTP/1.1 specification)。ServletRequest接口提供了一下方法來決定request的語言偏好(the preferred locale)：

• getLocal

• getLocales

        getLocal方法會返回客戶端設置的response content的語言偏好(the preferred locale)。參見RFC 2616(HTTP/1.1)的14.4節以獲取更多關於Accept-Language header如何須須解析來決定客戶端的語言偏好（how the Accept-Language header must interpreted to determine the preferred language of the client）。
        getLocales方法會返回一個語言偏好對象的枚舉，以客戶端選擇的語言偏好開始降序排列，這些偏好是客戶端能夠接受的(return an Enumeration of Locale objects indicating, in decreasing order starting with the preferred locale, the locales that are acceptable to the client)。
        若是客戶端沒有選擇語言偏好，那getLocale方法返回的語言偏好就會爲servlet container的默認偏好，而getLocales方法返回的枚舉類型必須只包含一個元素，就是默認偏好。

 

 

SRV4.9 Request data encoding

        目前，不少瀏覽器發送字符不用content-type header限定編碼，而把字符編碼的決定權公開給HTTP request讀取。若是沒有被client request設定的話，Container用來建立request reader和解析POST數據的默認request編碼是「ISO-8859-1」。若是client發送字符編碼失敗，getCharacterEncoding方法會返回null。
        若是client沒有設定字符編碼而且request數據被編碼爲與以上說起的默認編碼不一致的編碼，就會發生錯誤。爲了解決這種狀況，ServletRequest接口中加入了一個新的方法setCharacterEncoding(String enc)。開發者能夠經過調用這個方法override container支持的字符編碼。setCharacterEncoding方法會在從request中傳送任何post數據和讀取任何輸入以前被調用。若是數據在方法調用前被讀取，則不會對字符編碼產生影響。

 

 

SRV4.10 Lifetime of the Request Object

        每一個request對象都只在對應的servlet的service方法的範圍內有效，或者在filter的doFilter方法的範圍內有效。爲了不request對象建立的性能開銷過大，container通常會回收request對象。開發者必須清楚的是，在以上描述的範圍以外維護request對象的引用是不被推薦的，由於這有可能引發不可預知的結果。