HTTP請求報文

1.組成部分

HTTP請求報文有3部分組成，請求頭+請求行+請求體。

image

1. 請求方法。HTTP的請求方法常用的有GET/POST,除此之外還有DELETE、HEAD、OPTIONS、PUT、TRACE。不過，當(dāng)前的大多數(shù)瀏覽器只支持GET和POST。Spring 3.0提供了一個HiddenHttpMethodFilter，允許你通過“_method”的表單參數(shù)指定這些特殊的HTTP方法（實際上還是通過POST提交表單）。服務(wù)端配置了HiddenHttpMethodFilter后，Spring會根據(jù)_method參數(shù)指定的值模擬出相應(yīng)的HTTP方法，這樣，就可以使用這些HTTP方法對處理方法進行映射了。
2. 請求URL：跟HOST組成完整的請求URL。
3. HTTP協(xié)議：協(xié)議名稱和版本號。
4. HTTP報文頭：有屬性:屬性值,服務(wù)端可以獲取客戶端信息。
5. HTTP報文體：它承載多個請求參數(shù)的數(shù)據(jù)。不但報文體可以傳遞請求參數(shù)，請求URL也可以通過類似于“/chapter15/user.html? param1=value1&param2=value2”的方式傳遞請求參數(shù)。

2.HTTP請求報文頭屬性

Accept
請求報文通過Accept報文屬性頭告訴服務(wù)端，客戶端接受什么類型的相應(yīng)。
Accpet:text/plain表示只接受純文本數(shù)據(jù)
Accept屬性的值可以為一個或多個MIME類型的值，關(guān)于MIME類型，大家請參考：http://en.wikipedia.org/wiki/MIME_type

Cookie
客戶端的Cookie就是通過這個報文頭屬性傳給服務(wù)端
URL重寫功能,為了防止一些用戶把Cookie禁止而無法使用session而設(shè)置的功能.jsessionid后面的一長串就是你服務(wù)器上的session的ID號,這樣無需cookie也可以使用session

Referer
表示這個請求是從哪個URL過來的

Cache-Control
對緩存進行控制，如一個請求希望響應(yīng)返回的內(nèi)容在客戶端要被緩存一年，或不希望被緩存就可以通過這個報文頭達到目的。
如以下設(shè)置，相當(dāng)于讓服務(wù)端將對應(yīng)請求返回的響應(yīng)內(nèi)容不要在客戶端緩存（當(dāng)然響應(yīng)報文也是通過響應(yīng)報文頭通知瀏覽器客戶端的，這個下面再說）：
Cache-Control: no-cache

如何訪問請求報文頭

請求頭是客戶端發(fā)送過來的，服務(wù)端就只能讀取了，常用的是HttpServletRequest中的API讀取。

//獲取請求報文中的屬性名稱  
java.util.Enumeration<java.lang.String>   getHeaderNames();  
  
//獲取指定名稱的報文頭屬性的值  
java.lang.String getHeader(java.lang.String name)   

//獲取報文頭中的Cookie(讀取Cookie的報文頭屬性）  
 Cookie[]   getCookies() ;  
  
//獲取客戶端本地化信息（讀取 Accept-Language 的報文頭屬性）  
java.util.Locale    getLocale()   
  
//獲取請求報文體的長度（讀取Content-Length的報文頭屬性）  
int getContentLength();   

HttpServletRequest可以通過

 HttpSession getSession()

獲取請求所關(guān)聯(lián)的HttpSession,
其內(nèi)部的機理是通過讀取請求報文頭中Cookie屬性的JSESSIONID的值，在服務(wù)端的一個會話Map中，根據(jù)這個JSESSIONID獲取對應(yīng)的HttpSession的對象。

HTTP響應(yīng)報文

image

響應(yīng)報文也是有響應(yīng)頭+響應(yīng)體+響應(yīng)行組成
和請求報文相比，響應(yīng)報文多了一個“響應(yīng)狀態(tài)碼”，它以“清晰明確”的語言告訴客戶端本次請求的處理結(jié)果。
HTTP的響應(yīng)狀態(tài)碼由5段組成：

• 1xx 消息，一般是告訴客戶端，請求已經(jīng)收到了，正在處理，別急...
• 2xx 處理成功，一般表示：請求收悉、我明白你要的、請求已受理、已經(jīng)處理完成等信息.
• 3xx 重定向到其它地方。它讓客戶端再發(fā)起一個請求以完成整個處理。
• 4xx 處理發(fā)生錯誤，責(zé)任在客戶端，如客戶端的請求一個不存在的資源，客戶端未被授權(quán)，禁止訪問等。
• 5xx 處理發(fā)生，責(zé)任在服務(wù)端，如服務(wù)端拋出異常，路由出錯，HTTP版本不支持等。

303 See Other
我把你redirect到其它的頁面，目標(biāo)的URL通過響應(yīng)報文頭的Location告訴你。
304 Not Modified
告訴客戶端，你請求的這個資源至你上次取得后，并沒有更改，你直接用你本地的緩存吧

//設(shè)置狀態(tài)碼，狀態(tài)碼在HttpServletResponse中通過一系列的常量預(yù)定義了，如SC_ACCEPTED，SC_OK
void    setStatus(int sc) 

常見的HTTP響應(yīng)報文頭屬性

Cache-Control
響應(yīng)輸出到客戶端后，服務(wù)端通過該報文頭屬告訴客戶端如何控制響應(yīng)內(nèi)容的緩存。如果客戶再次訪問該資源，直接從客戶端的緩存中返回內(nèi)容給客戶，不要再從服務(wù)端獲取。
Cache-Control: max-age=3600 設(shè)置緩存時間6分鐘

ETag
ETag是HTTP1.1中才加入的一個屬性，用來幫助服務(wù)器控制Web端的緩存驗證。它的原理是這樣的，當(dāng)瀏覽器請求服務(wù)器的某項資源(A)時, 服務(wù)器根據(jù)A算出一個哈希值(3f80f-1b6-3e1cb03b)并通過 ETag 返回給瀏覽器，瀏覽器把"3f80f-1b6-3e1cb03b" 和 A 同時緩存在本地，當(dāng)下次再次向服務(wù)器請求A時，會通過類似 If-None-Match: "3f80f-1b6-3e1cb03b" 的請求頭把ETag發(fā)送給服務(wù)器，服務(wù)器再次計算A的哈希值并和瀏覽器返回的值做比較，如果發(fā)現(xiàn)A發(fā)生了變化就把A返回給瀏覽器(200)，如果發(fā)現(xiàn)A沒有變化就給瀏覽器返回一個304未修改。這樣通過控制瀏覽器端的緩存，可以節(jié)省服務(wù)器的帶寬，因為服務(wù)器不需要每次都把全量數(shù)據(jù)返回給客戶端。

Location
當(dāng)瀏覽器接受到頭信息中的 Location: xxxx 后，就會自動跳轉(zhuǎn)到 xxxx 指向的URL地址，這點有點類似用 js 寫跳轉(zhuǎn)。
但是這個跳轉(zhuǎn)只有瀏覽器知道，不管體內(nèi)容里有沒有東西，用戶都看不到。

Set-Cookie
服務(wù)端可以設(shè)置客戶端的Cookie，其原理就是通過這個響應(yīng)報文頭屬性實現(xiàn)的

/添加一個響應(yīng)報文頭屬性
void    setHeader(String name, String value) 

//添加Cookie報文頭屬性
void addCookie(Cookie cookie) 

//不但會設(shè)置Location的響應(yīng)報文頭，還會生成303的狀態(tài)碼
void    sendRedirect(String location)