【刷題】麪筋-網絡-HTTP請求行、請求頭、請求體詳解

目錄

• HTTP請求報文解剖
• HTTP請求報文頭屬性
  • 常見的HTTP請求報文頭屬性
  • 其它請求報文頭屬性
  • 如何訪問請求報文頭
• HTTP響應報文解剖
• 響應狀態碼
• 常見的HTTP響應報文頭屬性
• 如何寫HTTP請求報文頭
• HTTP請求頭--那些你須要記住的基礎知識
  • HTTP頭信息解讀
  • HTTP通用頭
  • HTTP請求頭
  • 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&param2=value2的鍵值對形式編碼成一個格式化串，它承載多個請求參數的數據。不但報文體能夠傳遞請求參數，請求URL也能夠經過相似於「/chapter15/user.html? param1=value1&param2=value2」的方式傳遞請求參數。

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

HTTP請求報文頭屬性

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

常見的HTTP請求報文頭屬性

• Accept

  • 請求報文可經過一個「Accept」報文頭屬性告訴服務端 客戶端接受什麼類型的響應。
  • 以下報文頭至關於告訴服務端，本客戶端可以接受的響應類型僅爲純文本數據啊，發其它什麼圖片啊，視頻啊，會歇菜的~~~：

Accept:text/plain`

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

• Cookie

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

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

• 服務端是怎麼知道客戶端的多個請求是隸屬於一個Session呢？

  • 注意到後臺的那個jsessionid=5F4771183629C9834F8382E23BE13C4C木有？
  • 原來就是經過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,其內部的機理是經過讀取請求報文頭中Cookie屬性的JSESSIONID的值，在服務端的一個會話Map中，根據這個JSESSIONID獲取對應的HttpSession的對象。（這樣，你就不會以爲HttpSession很神祕了吧)
  • HttpSession getSession()

=================================================

HTTP響應報文解剖

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

=================================================

響應狀態碼

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

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

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

• 注：

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

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

• 具體參考：HTTP的請求類型和狀態碼

=================================================

常見的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：

ETag: "737060cd8c284d8af7ad3082f209582d"

• Location

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

Location: http://www.iteye.com

• Set-Cookie

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

Set-Cookie: UserID=JohnDoe; 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)

=================================================

HTTP請求頭--那些你須要記住的基礎知識

HTTP頭信息解讀

　　HTTP的頭域包括通用頭、請求頭、響應頭和實體頭四個部分。每一個頭域由一個域名，冒號（:）和域值三部分組成。

　　通用頭部：是客戶端和服務器均可以使用的頭部，能夠在客戶端、服務器和其餘應用程序之間提供一些很是有用的通用功能，如Date頭部。

　　請求頭部：是請求報文特有的，它們爲服務器提供了一些額外信息，好比客戶端但願接收什麼類型的數據，如Accept頭部。

　　響應頭部：便於客戶端提供信息，好比，客服端在與哪一種類型的服務器進行交互，如Server頭部。

　　實體頭部：指的是用於應對實體主體部分的頭部，好比，能夠用實體頭部來講明實體主體部分的數據類型，如Content-Type頭部。

HTTP通用頭

　　通用頭域包含請求和響應消息都支持的頭域，通用頭域包含緩存頭部Cache-Control、Pragma及信息性頭部Connection、Date、Transfer-Encoding、Update、Via。

　　一、Cache-Control

　　Cache-Control指定請求和響應遵循的緩存機制。在請求消息或響應消息中設置 Cache-Control並不會修改另外一個消息處理過程當中的緩存處理過程。請求時的緩存指令包括no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached，響應消息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。各個消息中的指令含義以下：

　　no-cache：指示請求或響應消息不能緩存，其實是能夠存儲在本地緩存區中的，只是在與原始服務器進行新鮮度驗證以前，緩存不能將其提供給客戶端使用。　

　　no-store：緩存應該儘快從存儲器中刪除文檔的全部痕跡，由於其中可能會包含敏感信息。

　　max-age：緩存沒法返回緩存時間長於max-age規定秒的文檔，若不超規定秒瀏覽器將不會發送對應的請求到服務器，數據由緩存直接返回；超過這一時間段才進一步由服務器決定是返回新數據仍是仍由緩存提供。若同時還發送了max-stale指令，則使用期可能會超過其過時時間。

　　min-fresh：至少在將來規定秒內文檔要保持新鮮，接受其新鮮生命期大於其當前 Age 跟 min-fresh 值之和的緩存對象。

　　max-stale：指示客戶端能夠接收過時響應消息，若是指定max-stale消息的值，那麼客戶端能夠接收過時但在指定值以內的響應消息。

　　only-if-cached：只有當緩存中有副本存在時，客戶端纔會得到一份副本。

　　Public：指示響應可被任何緩存區緩存，能夠用緩存內容迴應任何用戶。

　　Private：指示對於單個用戶的整個或部分響應消息，不能被共享緩存處理，只能用緩存內容迴應先前請求該內容的那個用戶。

　　二、Pragma

　　Pragma頭域用來包含實現特定的指令，最經常使用的是Pragma:no-cache。在HTTP/1.1協議中，它的含義和Cache- Control:no-cache相同。

　　三、Connection

　　Connection表示是否須要持久鏈接。若是Servlet看到這裏的值爲「Keep-Alive」，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久鏈接），它就能夠利用持久鏈接的優勢，當頁面包含多個元素時（例如Applet，圖片），顯著地減小下載所須要的時間。要實現這一點，Servlet須要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，而後在正式寫出內容以前計算它的大小。

　　Close：告訴WEB服務器或者代理服務器，在完成本次請求的響應後，斷開鏈接，不要等待本次鏈接的後續請求了。

　　Keepalive：告訴WEB服務器或者代理服務器，在完成本次請求的響應後，保持鏈接，等待本次鏈接的後續請求。

　　Keep-Alive：若是瀏覽器請求保持鏈接，則該頭部代表但願 WEB 服務器保持鏈接多長時間（秒），如Keep-Alive：300。

　　四、Date

　　Date頭域表示消息發送的時間，服務器響應中要包含這個頭部，由於緩存在評估響應的新鮮度時要用到，其時間的描述格式由RFC822定義。例如，Date:Mon, 31 Dec 2001 04:25:57 GMT。Date描述的時間表示世界標準時，換算成本地時間，須要知道用戶所在的時區。

　　五、Transfer-Encoding

　　WEB 服務器代表本身對本響應消息體（不是消息體裏面的對象）做了怎樣的編碼，好比是否分塊（chunked），例如：Transfer-Encoding: chunked

　　六、Upgrade

　　它能夠指定另外一種可能徹底不一樣的協議，如HTTP/1.1客戶端能夠向服務器發送一條HTTP/1.0請求，其中包含值爲「HTTP/1.1」的Update頭部，這樣客戶端就能夠測試一下服務器是否也使用HTTP/1.1了。

　　七、Via

　　列出從客戶端到 OCS 或者相反方向的響應通過了哪些代理服務器，他們用什麼協議（和版本）發送的請求。

　　當客戶端請求到達第一個代理服務器時，該服務器會在本身發出的請求裏面添加 Via 頭部，並填上本身的相關信息，當下一個代理服務器 收到第一個代理服務器的請求時，會在本身發出的請求裏面複製前一個代理服務器的請求的Via頭部，並把本身的相關信息加到後面，以此類推，當 OCS 收到最後一個代理服務器的請求時，檢查 Via 頭部，就知道該請求所通過的路由。例如：Via：1.0 236-81.D07071953.sina.com.cn:80 (squid/2.6.STABLE13)

HTTP請求頭

　　請求頭用於說明是誰或什麼在發送請求、請求源於何處，或者客戶端的喜愛及能力。服務器能夠根據請求頭部給出的客戶端信息，試着爲客戶端提供更好的響應。請求頭域可能包含下列字段Accept、Accept-Charset、Accept- Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。對請求頭域的擴展要求通信雙方都支持，若是存在不支持的請求頭域，通常將會做爲實體頭域處理。

　　八、Accept

　　告訴WEB服務器本身接受什麼介質類型，/ 表示任何類型，type/* 表示該類型下的全部子類型，type/sub-type。

　　九、Accept-Charset

　　瀏覽器告訴服務器本身能接收的字符集。

　　十、Accept-Encoding

　　瀏覽器申明本身接收的編碼方法，一般指定壓縮方法，是否支持壓縮，支持什麼壓縮方法（gzip，deflate）。

　　十一、Accept-Language

　　瀏覽器申明本身接收的語言。語言跟字符集的區別：中文是語言，中文有多種字符集，好比big5，gb2312，gbk等等。

　　十二、Authorization

　　當客戶端接收到來自WEB服務器的 WWW-Authenticate 響應時，用該頭部來回應本身的身份驗證信息給WEB服務器。

　　1三、If-Match

　　若是對象的 ETag 沒有改變，其實也就意味著對象沒有改變，才執行請求的動做，獲取文檔。

　　1四、If-None-Match

　　若是對象的 ETag 改變了，其實也就意味著對象也改變了，才執行請求的動做，獲取文檔。

　　1五、If-Modified-Since

　　若是請求的對象在該頭部指定的時間以後修改了，才執行請求的動做（好比返回對象），不然返回代碼304，告訴瀏覽器該對象沒有修改。例如：If-Modified-Since：Thu, 10 Apr 2008 09:14:42 GMT

　　1六、If-Unmodified-Since

　　若是請求的對象在該頭部指定的時間以後沒修改過，才執行請求的動做（好比返回對象）。

　　1七、If-Range

　　瀏覽器告訴 WEB 服務器，若是我請求的對象沒有改變，就把我缺乏的部分給我，若是對象改變了，就把整個對象給我。瀏覽器經過發送請求對象的ETag 或者本身所知道的最後修改時間給 WEB 服務器，讓其判斷對象是否改變了。老是跟 Range 頭部一塊兒使用。

　　1八、Range

　　瀏覽器（好比 Flashget 多線程下載時）告訴 WEB 服務器本身想取對象的哪部分。例如：Range: bytes=1173546

　　1九、Proxy-Authenticate

　　代理服務器響應瀏覽器，要求其提供代理身份驗證信息。

　　20、Proxy-Authorization

　　瀏覽器響應代理服務器的身份驗證請求，提供本身的身份信息。

　　2一、Host

　　客戶端指定本身想訪問的WEB服務器的域名/IP 地址和端口號。如Host：rss.sina.com.cn

　　2二、Referer

　　瀏覽器向WEB 服務器代表本身是從哪一個網頁URL得到點擊當前請求中的網址/URL，例如：Referer：http://www.ecdoer.com/

　　2三、User-Agent

　　瀏覽器代表本身的身份（是哪一種瀏覽器）。例如：User-Agent：Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN;rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

HTTP響應頭

　　響應頭向客戶端提供一些額外信息，好比誰在發送響應、響應者的功能，甚至與響應相關的一些特殊指令。這些頭部有助於客戶端處理響應，並在未來發起更好的請求。響應頭域包含Age、Location、Proxy-Authenticate、Public、Retry- After、Server、Vary、Warning、WWW-Authenticate。對響應頭域的擴展要求通信雙方都支持，若是存在不支持的響應頭域，通常將會做爲實體頭域處理。

　　2四、Age

　　當代理服務器用本身緩存的實體去響應請求時，用該頭部代表該實體從產生到如今通過多長時間了。

　　2五、Server

　　WEB 服務器代表本身是什麼軟件及版本等信息。例如：Server：Apache/2.0.61 (Unix)

　　2六、Accept-Ranges

　　WEB服務器代表本身是否接受獲取其某個實體的一部分（好比文件的一部分）的請求。bytes：表示接受，none：表示不接受。

　　2七、Vary

　　WEB服務器用該頭部的內容告訴 Cache 服務器，在什麼條件下才能用本響應所返回的對象響應後續的請求。假如源WEB服務器在接到第一個請求消息時，其響應消息的頭部爲：Content-Encoding: gzip; Vary: Content-Encoding，那麼Cache服務器會分析後續請求消息的頭部，檢查其Accept-Encoding，是否跟先前響應的Vary頭部值一致，便是否使用相同的內容編碼方法，這樣就能夠防止Cache服務器用本身Cache 裏面壓縮後的實體響應給不具有解壓能力的瀏覽器。例如：Vary：Accept-Encoding。

HTTP實體頭

　　實體頭部提供了有關實體及其內容的大量信息，從有關對象類型的信息，到可以對資源使用的各類有效的請求方法。總之，實體頭部能夠告知接收者它在對什麼進行處理。請求消息和響應消息均可以包含實體信息，實體信息通常由實體頭域和實體組成。實體頭域包含關於實體的原信息，實體頭包括信息性頭部Allow、Location，內容頭部Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD五、Content-Range、Content-Type，緩存頭部Etag、Expires、Last-Modified、extension-header。

　　2八、Allow

　　服務器支持哪些請求方法（如GET、POST等）。

　　2九、Location

　　表示客戶應當到哪裏去提取文檔，用於將接收端定位到資源的位置（URL）上。Location一般不是直接設置的，而是經過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼爲302。

　　30、Content-Base

　　解析主體中的相對URL時使用的基礎URL。

　　3一、Content-Encoding

　　WEB服務器代表本身使用了什麼壓縮方法（gzip，deflate）壓縮響應中的對象。例如：Content-Encoding：gzip

　　3二、Content-Language

　　WEB 服務器告訴瀏覽器理解主體時最適宜使用的天然語言。

　　3三、Content-Length

　　WEB服務器告訴瀏覽器本身響應的對象的長度或尺寸，例如：Content-Length: 26012

　　3四、Content-Location

　　資源實際所處的位置。

　　3五、Content-MD5

　　主體的MD5校驗和。

　　3六、Content-Range

　　實體頭用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的範圍和整個實體長度。通常格式： Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth。例如，傳送頭500個字節次字段的形式：Content-Range:bytes0- 499/1234若是一個http消息包含此節（例如，對範圍請求的響應或對一系列範圍的重疊請求），Content-Range表示傳送的範圍，Content-Length表示實際傳送的字節數。

　　3七、Content-Type

　　WEB 服務器告訴瀏覽器本身響應的對象的類型。例如：Content-Type：application/xml

　　3八、Etag

　　就是一個對象（好比URL）的標誌值，就一個對象而言，好比一個html文件，若是被修改了，其Etag也會別修改，因此，ETag的做用跟Last-Modified的做用差很少，主要供WEB服務器判斷一個對象是否改變了。好比前一次請求某個html文件時，得到了其 ETag，當此次又請求這個文件時，瀏覽器就會把先前得到ETag值發送給WEB服務器，而後WEB服務器會把這個ETag跟該文件的當前ETag進行對比，而後就知道這個文件有沒有改變了。

　　3九、Expires

　　WEB服務器代表該實體將在何時過時，對於過時了的對象，只有在跟WEB服務器驗證了其有效性後，才能用來響應客戶請求。是 HTTP/1.0 的頭部。例如：Expires：Sat, 23 May 2009 10:02:12 GMT

　　40、Last-Modified

　　WEB服務器認爲對象的最後修改時間，好比文件的最後修改時間，動態頁面的最後產生時間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT

參考連接

• HTTP請求行、請求頭、請求體詳解
• HTTP請求頭--那些你須要記住的基礎知識

END