HTTP請求報文解剖

摘要： HTTP請求報文由3部分組成（請求行+請求頭+請求體）： 下面是一個實際的請求報文： ① 是請求方法，GET和POST是最多見的HTTP方法，除此之外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。不過，當前的大多數瀏覽器只支持GET和POST，Spring 3.0提供了一個...

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」的方式傳遞請求參數。

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

1.IE系
HttpWatch是強大的網頁數據分析工具，安裝後將集成到Internet Explorer工具欄中。它不用代理服務器或一些複雜的網絡監控工具，就能抓取請求及響應的完整信息，包括Cookies、消息頭、查詢參數、響應報文等，是Web應用開發人員的必備工具。
2.Chrome,firefox
自身的調試器已經很好用了，按F12就能夠看到(IE10以上也直接按F12就能夠調試了)

HTTP請求報文頭屬性

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

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

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

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

常見的HTTP請求報文頭屬性

**Accept **

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

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

Accept:text/plain

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

Cookie

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

Cookie:skin=blue; jsessionid=5F4771183629C9834F8382E23BE13C4C

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

Referer

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

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

Cache-Control

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

如如下設置，至關於讓服務端將對應請求返回的響應內容不要在客戶端緩存（固然響應報文也是經過響應報文頭通知瀏覽器客戶端的，這個下面再說）：

Cache-Control: no-cache

其它報文頭屬性

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

如何訪問請求報文頭

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

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

//獲取指定名稱的報文頭屬性的值
java.lang.String getHeader(java.lang.String name)

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

//獲取報文頭中的Cookie(讀取Cookie的報文頭屬性）
 Cookie[]   getCookies() ;

//獲取客戶端本地化信息（讀取 Accept-Language 的報文頭屬性）
java.util.Locale    getLocale() 

//獲取請求報文體的長度（讀取Content-Length的報文頭屬性）
int getContentLength();

HttpServletRequest能夠經過 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告訴你。

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

304 Not Modified

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

404 Not Found

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

500 Internal Server Error

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

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

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

常見的HTTP響應報文頭屬性

Cache-Control

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

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

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：

ETag: "737060cd8c284d8af7ad3082f209582d"

Location

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

Location: https://github.com/biezhi/jb

Set-Cookie

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

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

其它HTTP請求報文頭屬性

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

如何寫HTTP請求報文頭

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

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

像Cookie，Location這些響應頭是有福之人，HttpServletResponse爲它們都提供了VIP（非API 哈）：

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

//不但會設置Location的響應報文頭，還會生成303的狀態碼呢，二者天仙配呢
void    sendRedirect(String location)