HTTP請求行、請求頭、請求體詳解

 

 

HTTP請求報文解剖 

HTTP請求報文由3部分組成（請求行+請求頭+請求體）： 

 

下面是一個實際的請求報文： 

 

①是請求方法，GET和POST是最多見的HTTP方法，除此之外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。不過，當前的大多數瀏覽器只支持GET和POST，Spring 3.0提供了一個HiddenHttpMethodFilter，容許你經過「_method」的表單參數指定這些特殊的HTTP方法（實際上仍是經過POST提交表單）。服務端配置了HiddenHttpMethodFilter後，Spring會根據_method參數指定的值模擬出相應的HTTP方法，這樣，就可使用這些HTTP方法對處理方法進行映射了。 

②爲請求對應的URL地址，它和報文頭的Host屬性組成完整的請求URL，③是協議名稱及版本號。 

④是HTTP的報文頭，報文頭包含若干個屬性，格式爲「屬性名:屬性值」，服務端據此獲取客戶端的信息。 

⑤是報文體，它將一個頁面表單中的組件值經過param1=value1&param2=value2的鍵值對形式編碼成一個格式化串，它承載多個請求參數的數據。不但報文體能夠傳遞請求參數，請求URL也能夠經過相似於「/chapter15/user.html? param1=value1&param2=value2」的方式傳遞請求參數。 

對照上面的請求報文，咱們把它進一步分解，你能夠看到一幅更詳細的結構圖： 

 

 

引用

HttpWatch是強大的網頁數據分析工具，安裝後將集成到Internet Explorer工具欄中。它不用代理服務器或一些複雜的網絡監控工具，就能抓取請求及響應的完整信息，包括Cookies、消息頭、查詢參數、響應報文等，是Web應用開發人員的必備工具。

HTTP請求報文頭屬性 

報文頭屬性是什麼東西呢？咱們不妨以一個小故事來講明吧。 
 

引用

快到中午了，張三丰不想去食堂吃飯，因而打電話叫外賣：老闆，我要一份[魚香肉絲]，要12：30以前給我送過來哦，我在江湖湖公司研發部，叫張三丰。

這裏，你要[魚香肉絲]至關於HTTP報文體，而「12：30以前送過來」，你叫「張三丰」等信息就至關於HTTP的報文頭。它們是一些附屬信息，幫忙你和飯店老闆順利完成此次交易。 

請求HTTP報文和響應HTTP報文都擁有若干個報文關屬性，它們是爲協助客戶端及服務端交易的一些附屬信息。 


常見的HTTP請求報文頭屬性 

Accept 

請求報文可經過一個「Accept」報文頭屬性告訴服務端 客戶端接受什麼類型的響應。 

以下報文頭至關於告訴服務端，俺客戶端可以接受的響應類型僅爲純文本數據啊，你丫別發其它什麼圖片啊，視頻啊過來，那樣我會歇菜的~~~： 
 

Java代碼  

1. Accept:text/plain  

Accept屬性的值能夠爲一個或多個MIME類型的值，關於MIME類型，你們請參考：http://en.wikipedia.org/wiki/MIME_type 

Cookie 

客戶端的Cookie就是經過這個報文頭屬性傳給服務端的哦！以下所示： 

Java代碼  

1. Cookie: $Version=1; Skin=new;jsessionid=5F4771183629C9834F8382E23BE13C4C  

服務端是怎麼知道客戶端的多個請求是隸屬於一個Session呢？注意到後臺的那個jsessionid=5F4771183629C9834F8382E23BE13C4C木有？原來就是經過HTTP請求報文頭的Cookie屬性的jsessionid的值關聯起來的！（固然也能夠經過重寫URL的方式將會話ID附帶在每一個URL的後面哦）。 


Referer 

表示這個請求是從哪一個URL過來的，假如你經過google搜索出一個商家的廣告頁面，你對這個廣告頁面感興趣，鼠標一點發送一個請求報文到商家的網站，這個請求報文的Referer報文頭屬性值就是http://www.google.com。 

引用

唐僧到了西天. 
如來問：儂是否是從東土大唐來啊？ 
唐僧：厲害！你咋知道的！ 
如來：呵呵，我偷看了你的Referer... 

不少貌似神奇的網頁監控軟件（如著名的 我要啦），只要在你的網頁上放上一段JavaScript，就能夠幫你監控流量，全國訪問客戶的分佈狀況等報表和圖表，其原理就是經過這個Referer及其它一些HTTP報文頭工做的。 

Cache-Control 

對緩存進行控制，如一個請求但願響應返回的內容在客戶端要被緩存一年，或不但願被緩存就能夠經過這個報文頭達到目的。 

如如下設置，至關於讓服務端將對應請求返回的響應內容不要在客戶端緩存： 

Java代碼  

1. Cache-Control: no-cache  

其它請求報文頭屬性 

參見：http://en.wikipedia.org/wiki/List_of_HTTP_header_fields 

如何訪問請求報文頭 

因爲請求報文頭是客戶端發過來的，服務端固然只能讀取了，如下是HttpServletRequest一些用於讀取請求報文頭的API： 
 

Java代碼  

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

因爲一些請求報文頭屬性「太著名」了，所以HttpServletRequest爲它們提供了VIP的API： 
 

Java代碼  

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

HttpServletRequest能夠經過 

Java代碼  

1. HttpSession getSession()   

獲取請求所關聯的HttpSession,其內部的機理是經過讀取請求報文頭中Cookie屬性的JSESSIONID的值，在服務端的一個會話Map中，根據這個JSESSIONID獲取對應的HttpSession的對象。（這樣，你就不會以爲HttpSession很神祕了吧，你本身也能夠作一個相似的會話管理  ） 

HTTP響應報文解剖 

響應報文結構 

HTTP的響應報文也由三部分組成（響應行+響應頭+響應體）： 

 

如下是一個實際的HTTP響應報文： 

 

①報文協議及版本； 
②狀態碼及狀態描述； 
③響應報文頭，也是由多個屬性組成； 
④響應報文體，即咱們真正要的「乾貨」。 

響應狀態碼 

和請求報文相比，響應報文多了一個「響應狀態碼」，它以「清晰明確」的語言告訴客戶端本次請求的處理結果。 

HTTP的響應狀態碼由5段組成： 
 

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

如下是幾個常見的狀態碼： 

200 OK 

你最但願看到的，即處理成功！ 

303 See Other 

我把你redirect到其它的頁面，目標的URL經過響應報文頭的Location告訴你。 

引用

悟空：師傅給個桃吧，走了一天了 
唐僧：我哪有桃啊！去王母娘娘那找吧

304 Not Modified 

告訴客戶端，你請求的這個資源至你上次取得後，並無更改，你直接用你本地的緩存吧，我很忙哦，你能不能少來煩我啊！ 

404 Not Found 

你最不但願看到的，即找不到頁面。如你在google上找到一個頁面，點擊這個連接返回404，表示這個頁面已經被網站刪除了，google那邊的記錄只是美好的回憶。 

500 Internal Server Error 

看到這個錯誤，你就應該查查服務端的日誌了，確定拋出了一堆異常，別睡了，起來改BUG去吧！ 


其它的狀態碼參見：http://en.wikipedia.org/wiki/List_of_HTTP_status_codes 


有些響應碼，Web應用服務器會自動給生成。你能夠經過HttpServletResponse的API設置狀態碼： 
 

Java代碼  

1. //設置狀態碼，狀態碼在HttpServletResponse中經過一系列的常量預約義了，如SC_ACCEPTED，SC_OK  
2. void    setStatus(int sc)   

常見的HTTP響應報文頭屬性 

Cache-Control 

響應輸出到客戶端後，服務端經過該報文頭屬告訴客戶端如何控制響應內容的緩存。 

下面，的設置讓客戶端對響應內容緩存3600秒，也即在3600秒內，若是客戶再次訪問該資源，直接從客戶端的緩存中返回內容給客戶，不要再從服務端獲取（固然，這個功能是靠客戶端實現的，服務端只是經過這個屬性提示客戶端「應該這麼作」，作不作，仍是決定於客戶端，若是是本身宣稱支持HTTP的客戶端，則就應該這樣實現）。 
 

Java代碼  

1. Cache-Control: max-age=3600  

ETag 

一個表明響應服務端資源（如頁面）版本的報文頭屬性，若是某個服務端資源發生變化了，這個ETag就會相應發生變化。它是Cache-Control的有益補充，可讓客戶端「更智能」地處理何時要從服務端取資源，何時能夠直接從緩存中返回響應。 

關於ETag的說明，你能夠參見：http://en.wikipedia.org/wiki/HTTP_ETag。 
Spring 3.0還專門爲此提供了一個org.springframework.web.filter.ShallowEtagHeaderFilter（實現原理很簡單，對JSP輸出的內容MD5，這樣內容有變化ETag就相應變化了），用於生成響應的ETag，由於這東東確實能夠幫助減小請求和響應的交互。 

下面是一個ETag： 

Java代碼  

1. ETag: "737060cd8c284d8af7ad3082f209582d"  

Location 

咱們在JSP中讓頁面Redirect到一個某個A頁面中，實際上是讓客戶端再發一個請求到A頁面，這個須要Redirect到的A頁面的URL，其實就是經過響應報文頭的Location屬性告知客戶端的，以下的報文頭屬性，將使客戶端redirect到iteye的首頁中： 
 

Java代碼  

1. Location: http://www.iteye.com  

Set-Cookie 

服務端能夠設置客戶端的Cookie，其原理就是經過這個響應報文頭屬性實現的： 
 

Java代碼  

1. Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1  

其它HTTP響應報文頭屬性 

更多其它的HTTP響應頭報文，參見：http://en.wikipedia.org/wiki/List_of_HTTP_header_fields 


如何寫HTTP請求報文頭 

在服務端能夠經過HttpServletResponse的API寫響應報文頭的屬性： 
 

Java代碼  

1. //添加一個響應報文頭屬性  
2. void    setHeader(String name, String value)   

象Cookie，Location這些響應都是有福之人，HttpServletResponse爲它們都提供了VIP版的API： 

Java代碼  

1. //添加Cookie報文頭屬性  
2. void addCookie(Cookie cookie)   
3.   
4. //不但會設置Location的響應報文頭，還會生成303的狀態碼呢，二者天仙配呢  
5. void    sendRedirect(String location)