HTTP請求行、請求頭、請求體詳解
引用
學習Web開發不好好學習HTTP報文,將會“打拳不練功,到老一場空”,你花在犯迷糊上的時間比你沉下心來學習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¶m2=value2的鍵值對形式編碼成一個格式化串,它承載多個請求引數的資料。不但報文體可以傳遞請求引數,請求URL也可以通過類似於“/chapter15/user.html? param1=value1¶m2=value2”的方式傳遞請求引數。
對照上面的請求報文,我們把它進一步分解,你可以看到一幅更詳細的結構圖:
引用
HttpWatch是強大的網頁資料分析工具,安裝後將整合到Internet Explorer工具欄中。它不用代理伺服器或一些複雜的網路監控工具,就能抓取請求及響應的完整資訊,包括Cookies、訊息頭、查詢引數、響應報文等,是Web應用開發人員的必備工具。
HTTP請求報文頭屬性
報文頭屬性是什麼東西呢?我們不妨以一個小故事來說明吧。
引用
快到中午了,張三丰不想去食堂吃飯,於是打電話叫外賣:老闆,我要一份[魚香肉絲],要12:30之前給我送過來哦,我在江湖湖公司研發部,叫張三丰。
這裡,你要[魚香肉絲]相當於HTTP報文體,而“12:30之前送過來”,你叫“張三丰”等資訊就相當於HTTP的報文頭。它們是一些附屬資訊,幫忙你和飯店老闆順利完成這次交易。
請求HTTP報文和響應HTTP報文都擁有若干個報文關屬性,它們是為協助客戶端及服務端交易的一些附屬資訊。
常見的HTTP請求報文頭屬性
Accept
請求報文可通過一個“Accept”報文頭屬性告訴服務端 客戶端接受什麼型別的響應。
如下報文頭相當於告訴服務端,俺客戶端能夠接受的響應型別僅為純文字資料啊,你丫別發其它什麼圖片啊,視訊啊過來,那樣我會歇菜的~~~:
Java程式碼 收藏程式碼
Accept:text/plain
Cookie
客戶端的Cookie就是通過這個報文頭屬性傳給服務端的哦!如下所示:
Java程式碼 收藏程式碼
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程式碼 收藏程式碼
Cache-Control: no-cache
其它請求報文頭屬性
如何訪問請求報文頭
由於請求報文頭是客戶端發過來的,服務端當然只能讀取了,以下是HttpServletRequest一些用於讀取請求報文頭的API:
Java程式碼 收藏程式碼
//獲取請求報文中的屬性名稱
java.util.Enumeration<java.lang.String> getHeaderNames();
//獲取指定名稱的報文頭屬性的值
java.lang.String getHeader(java.lang.String name)
由於一些請求報文頭屬性“太著名”了,因此HttpServletRequest為它們提供了VIP的API:
Java程式碼 收藏程式碼
//獲取報文頭中的Cookie(讀取Cookie的報文頭屬性)
Cookie[] getCookies() ;
//獲取客戶端本地化資訊(讀取 Accept-Language 的報文頭屬性)
java.util.Locale getLocale()
//獲取請求報文體的長度(讀取Content-Length的報文頭屬性)
int getContentLength();
HttpServletRequest可以通過
Java程式碼 收藏程式碼
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去吧!
有些響應碼,Web應用伺服器會自動給生成。你可以通過HttpServletResponse的API設定狀態碼:
Java程式碼 收藏程式碼
//設定狀態碼,狀態碼在HttpServletResponse中通過一系列的常量預定義了,如SC_ACCEPTED,SC_OK
void setStatus(int sc)
常見的HTTP響應報文頭屬性
Cache-Control
響應輸出到客戶端後,服務端通過該報文頭屬告訴客戶端如何控制響應內容的快取。
下面,的設定讓客戶端對響應內容快取3600秒,也即在3600秒內,如果客戶再次訪問該資源,直接從客戶端的快取中返回內容給客戶,不要再從服務端獲取(當然,這個功能是靠客戶端實現的,服務端只是通過這個屬性提示客戶端“應該這麼做”,做不做,還是決定於客戶端,如果是自己宣稱支援HTTP的客戶端,則就應該這樣實現)。
Java程式碼 收藏程式碼
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程式碼 收藏程式碼
ETag: “737060cd8c284d8af7ad3082f209582d”
Location
我們在JSP中讓頁面Redirect到一個某個A頁面中,其實是讓客戶端再發一個請求到A頁面,這個需要Redirect到的A頁面的URL,其實就是通過響應報文頭的Location屬性告知客戶端的,如下的報文頭屬性,將使客戶端redirect到iteye的首頁中:
Set-Cookie
服務端可以設定客戶端的Cookie,其原理就是通過這個響應報文頭屬性實現的:
Java程式碼 收藏程式碼
Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
其它HTTP響應報文頭屬性
如何寫HTTP請求報文頭
在服務端可以通過HttpServletResponse的API寫響應報文頭的屬性:
Java程式碼 收藏程式碼
//新增一個響應報文頭屬性
void setHeader(String name, String value)
象Cookie,Location這些響應都是有福之人,HttpServletResponse為它們都提供了VIP版的API:
Java程式碼 收藏程式碼
//新增Cookie報文頭屬性
void addCookie(Cookie cookie)
//不但會設定Location的響應報文頭,還會生成303的狀態碼呢,兩者天仙配呢
void sendRedirect(String location)