(轉存 作者未知)深入理解HTML協議

標籤：常用   file   工作   傳遞   index   hive   種類   註解   請求方式   

深入理解HTML協議http協議學 習系列1. 基礎概念篇1.1 介紹 HTTP是Hyper Text Transfer Protocol（超文字傳輸通訊協定 (HTTP)）的縮寫。它的發展是全球資訊網協會（World Wide Web Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結果，（他們）最終發布了一系 列的RFC，RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。HTTP協議（HyperText Transfer Protocol，超文字傳輸通訊協定 (HTTP)）是用於從WWW伺服器傳輸超文本到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網路傳輸減少。它不僅保證計算 機正確快速地傳輸超文字文件，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先於圖形)等。HTTP是一個應用程式層協議，由請求和響應構成，是一個標準的用戶端服 務器模型。HTTP是一個無狀態的協議。1.2 在TCP/IP協議棧中的位置HTTP協議通常承載於TCP協 議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了我們常說的HTTPS。如所示： 預設HTTP的連接埠 號為80，HTTPS的連接埠號碼為443。1.3 HTTP的請求響應模型HTTP協議永遠都是用戶端發起請求，伺服器回送響應。見： 這樣就限制了使用HTTP協議，無法實現在用戶端沒有發起請求的時候，伺服器將訊息推送給用戶端。HTTP協議是一個無狀態的協議，同一個用戶端的這次請求和上次請求 是沒有對應關係。1.4 工作流程一次HTTP操作稱為一個事務，其工作過程可分為四步：1）首先客戶機與伺服器需要建立串連。只要單擊某個超級連結，HTTP的工作開始。2）建立串連後，客戶機發送一個請求給伺服器，請求方式的格式為：統一資源識別項（URL）、協議版本號碼，後邊是MIME資訊包括請求修飾符、客戶機資訊和可能的內容。3）伺服器接到請求後，給予相應的響應資訊，其格式為一個狀態行，包括資訊的協議版本號碼、一個成功或錯 誤的代碼，後邊是MIME資訊包括伺服器資訊、實體資訊和可能的內容。4）用戶端接收伺服器所返回的資訊通過瀏覽器顯示在使用者的顯示屏上，然後客戶機與伺服器中斷連線。如果在以上過程中的某一步出現錯誤，那麼產生錯誤的資訊將返回到用戶端，有顯示屏輸 出。對於使用者來說，這些過程是由HTTP自己完成的，使用者只要用滑鼠點擊，等待資訊顯示就可以了。1.5 使用Wireshark抓TCP、http包開啟Wireshark，選擇工具列上的“Capture”->“Options”，介面選擇1所 示： 圖1 設定Capture選項一般讀者只需要選擇最上邊的下拉框，選擇合適的Device，而後點擊“Capture Filter”，此處選擇的是“HTTP TCP port（80）”，選擇後 點擊的“Start”開始抓包。 圖2 選擇Capture Filter例如在瀏覽器中開啟http://image.baidu.com/，抓包3所示： http://www.blogjava.net/images/blogjava_net/amigoxie/40799/o_http%e5%8d%8f%e8%ae%ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-3.jpg圖3 抓包在中，可清晰的看到用戶端瀏覽器（ip為192.168.2.33）與伺服器的互動過程：1）No1：瀏覽器（192.168.2.33）向伺服器（220.181.50.118）發出串連請求。此為TCP三向交握第一步，此時可以看出，為SYN，seq:X （x=0）2）No2：伺服器（220.181.50.118）回應了瀏覽器（192.168.2.33）的請求，並要求確認，此時為：SYN，ACK，此時seq：y（y為0），ACK：x+1（為1）。此為三向交握的第二步；3）No3：瀏覽器（192.168.2.33）回應了伺服器（220.181.50.118）的確認，串連成功。為：ACK，此時seq：x+1（為1），ACK：y+1（為1）。此為三向交握的第三步；4）No4：瀏覽器（192.168.2.33）發出一個頁面HTTP請求；5）No5：伺服器（220.181.50.118）確認；6）No6：伺服器（220.181.50.118）發送資料；7）No7：用戶端瀏 覽器（192.168.2.33）確認；8）No14：用戶端 （192.168.2.33）發出一個圖片HTTP請求；9）No15：伺服器 （220.181.50.118）發送狀態響應碼200 OK……1.6 頭域每個頭域由一個網域名稱，冒號（:）和域值三部分組成。網域名稱是大小寫無關的，域值前可以添加任何數量的空格符，頭域可以被擴充為多 行，在每行開始處，使用至少一個空格或定位字元。在抓包的圖中，No14點開可看到4所 示： http://www.blogjava.net/images/blogjava_net/amigoxie/40799/o_http%e5%8d%8f%e8%ae%ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-4.jpg圖4 http請求訊息 回應的訊息5所示： 圖5 http狀態響應資訊1.6.1 host頭域Host頭域指定請求資源的Intenet主機和連接埠號碼，必須表示請求url的原始伺服器或網關的位置。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀態代碼返回。圖5中host那行為： 1.6.2 Referer頭域Referer頭域允許用戶端指定請求uri的源資源地址，這可以允許伺服器產生回退鏈表，可用來登陸、最佳化cache等。他也允許廢除的或錯誤的串連由於維護的目的被追蹤。如果請求的uri沒有自己的uri地址，Referer不能被發送。如果指定的是部分uri地址，則此地址應該是一個相對位址。在圖4中，Referer行 的內容為： 1.6.3 User-Agent頭域User-Agent頭域的內容包含發出請求的使用者資訊。在圖4中，User-Agent行的內容為： http://www.blogjava.net/images/blogjava_net/amigoxie/40799/o_http%e5%8d%8f%e8%ae%ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-8.jpg1.6.4 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。在圖5中的該頭域為： 1.6.5 Date頭域Date頭域表示訊息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的 時間表示世界標準時，換算成本地時間，需要知道使用者所在的時區。圖5中，該頭域如所示： 1.7 HTTP的幾個重要概念1.7.1連 接：Connection一個傳輸層的實際環流，它是建立在兩個相互連訊的應用程式之間。在http1.1，request和reponse頭中都有可能出現一個connection的頭，此header的 含義是當client和server通訊時對於長連結如何進行處理。在http1.1中，client和server都是預設對方支援長連結的， 如果client使用http1.1協議，但又不希望使用長連結，則需要在header中指明connection的值為close；如果server方也不想支援長連結，則在response中也需要明確說明connection的值為close。 不論request還是response的header中包 含了值為close的connection，都表明當前正在使用的tcp連結在當天請求處理完畢後會被斷掉。以後client再進行新 的請求時就必須建立新的tcp連結了。1.7.2消 息：MessageHTTP通訊的基本單位，包括一個結構化的八元組序列並通過串連傳輸。1.7.3請 求：Request一個從用戶端到伺服器的請求資訊包括應用於資源的方法、資源的標識符和協議的版本 號。1.7.4響 應：Response一個從伺服器返回的資訊包括HTTP協議的版本號碼、請求的狀態(例如“成功”或“沒找到”)和文檔的MIME類 型。1.7.5資 源：Resource由URI標識的網路資料對象或服務。1.7.6實 體：Entity資料資源或來自服務資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應信 息中。一個實體包括實體頭資訊和實體的本身內容。1.7.7客戶 機：Client一個為發送請求目的而建立連線應用程式程式。1.7.8使用者 代理：UserAgent初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它使用者工具。1.7.9服務 器：Server一個接受串連並對請求返回資訊的應用程式。1.7.10源服 務器：Originserver是一個給定資源可以在其上駐留或被建立的伺服器。1.7.11代 理：Proxy一個中間程式，它可以充當一個伺服器，也可以充當一個客戶機，為其它客戶機建立請 求。請求是通過可能的翻譯在內部或經過傳遞到其它的伺服器中。一個代理在發送請求資訊之前，必須解釋並且如果可能重寫它。代理經常作為通過防火牆的客戶機端的門戶，代理還可以作為一個協助應用來通過協議處 理沒有被使用者代理程式完成的請求。1.7.12網 關：Gateway一個作為其它伺服器中間媒介的伺服器。與代理不同的是，網關接受請求就好象對被請求 的資源來說它就是原始伺服器；發出請求的客戶機並沒有意識到它在同網關打交道。網關經常作為通過防火牆的伺服器端的門戶，網關還可以作為一個協議翻譯器以便存取那 些儲存在非HTTP系統中的資源。1.7.13通 道：Tunnel是作為兩個串連中繼的中介程式。一旦啟用，通道便被認為不屬於HTTP通訊，儘管通道可能是被一個HTTP請求初始化的。當被中繼的串連兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經常使用。1.7.14緩 存：Cache反應資訊的局域儲存。 附錄：參考資料《http_百度百科》：http://baike.baidu.com/view/9472.htm《結果編碼和http狀態響應碼》：http://blog.tieniu1980.cn/archives/377《分析TCP的三向交握》：http://cache.baidu.com/c?m=9f65cb4a8c8507ed4fece763104c8c711923d030678197027fa3c215cc7905141130a8e5747e0d548d98297a5ae91e03f7f63772315477e3cacdd94cdbbdc42225d82c36734f844315c419d891007a9f34d507a9f916a2e1b065d2f48193864353bb15543897f1fb4d711edd1b86033093b1e94e022e67adec40728e2e605f983431c5508fe4&p=c6769a46c5820efd08e2973b42&user=baidu《使用Wireshark來檢測一次HTTP連 接過程》：http://blog.163.com/wangbo_tester/blog/static/12806792120098174162288/《http協議的幾個重要概念》：http://nc.mofcom.gov.cn/news/10819972.html《http協議中connection頭的作用》： http://blog.csdn.net/barfoo/archive/2008/06/05/2514667.aspx 2. 協議詳解篇2.1 HTTP/1.0和HTTP/1.1的比較RFC 1945定義了HTTP/1.0版本，RFC 2616定義了HTTP/1.1版本。筆者在blog上提 供了這兩個RFC中文版的。RFC1945：http://www.blogjava.net/Files/amigoxie/RFC1945（HTTP）中文 版.rarRFC2616：http://www.blogjava.net/Files/amigoxie/RFC2616（HTTP）中文 版.rar2.1.1建立串連方面HTTP/1.0 每次請求都需要建立新的TCP串連，串連不能複用。HTTP/1.1 新的請求可以在上次請 求建立的TCP串連之上發送，串連可以複用。優點是減少重複進行TCP三向交握的開銷，提高效率。注意：在同一個TCP連 接中，新的請求需要等上次請求收到響應後，才能發送。2.1.2 Host域HTTP1.1在Request消 息頭裡頭多了一個Host域, HTTP1.0則沒有這個域。Eg： GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org 可能HTTP1.0的時候認為，建立TCP串連的時候已經指定了IP地址，這個IP地址上只有一個host。2.1.3日期時間戳記(接收方向)無論是HTTP1.0還 是HTTP1.1，都要能解析下面三種date/time stamp：Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036Sun Nov 6 08:49:37 1994 ; ANSI C‘s asctime() format (發送方向)HTTP1.0要求不能產生第三種asctime格式的date/time stamp；HTTP1.1則要求只產生RFC 1123(第一種)格式的date/time stamp。2.1.4狀態響應碼狀態響應碼100 (Continue) 狀態碼的使用，允許用戶端在發request訊息body之前先 用request header試探一下server，看server要 不要接收request body，再決定要不要發request body。用戶端在Request頭部中包含Expect: 100-continue Server看到之後呢如果回100 (Continue) 這個狀態碼，用戶端就繼續發request body。這個是HTTP1.1才有的。另外在HTTP/1.1中還增加了101、203、205等等性狀態 響應碼2.1.5請求方式HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE, CONNECT這些Request方 法. Method = "OPTIONS" ; Section 9.2 | "GET" ; Section 9.3 | "HEAD" ; Section 9.4 | "POST" ; Section 9.5 | "PUT" ; Section 9.6 | "DELETE" ; Section 9.7 | "TRACE" ; Section 9.8 | "CONNECT" ; Section 9.9 | extension-method extension-method = token2.2 HTTP請求訊息2.2.1請求訊息格式請求訊息格式如下所示：請求行通用資訊頭|要求標頭|實體頭CRLF(斷行符號換行)實體內容其中“請求行”為：請求行 = 方法 [空格] 請求URI [空格] 版本號碼 [斷行符號換行]請求行執行個體：Eg1：GET /index.html HTTP/1.1 Eg2：POST http://192.168.2.217:8080/index.jsp HTTP/1.1HTTP請求訊息執行個體：GET /hello.htm HTTP/1.1Accept: */*Accept-Language: zh-cnAccept-Encoding: gzip, deflateIf-Modified-Since: Wed, 17 Oct 2007 02:15:55 GMTIf-None-Match: W/"158-1192587355000"User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)Host: 192.168.2.162:8080Connection: Keep-Alive2.2.2要求方法 HTTP的要求方法包括如下幾種：q GETq POSTq HEADq PUTq DELETEq OPTIONSq TRACEq CONNECT2.3 HTTP響應訊息2.3.1響應訊息格式HTTP響應訊息的格式如下所示：狀態行通用資訊頭|回應標頭|實體頭CRLF實體內容其中：狀態行 = 版 本號 [空格] 狀態代碼 [空格] 原因 [斷行符號換行]狀態行舉例：Eg1：HTTP/1.0 200 OK Eg2：HTTP/1.1 400 Bad Request HTTP響應訊息執行個體如下所示：HTTP/1.1 200 OKETag: W/"158-1192590101000"Last-Modified: Wed, 17 Oct 2007 03:01:41 GMTContent-Type: text/htmlContent-Length: 158Date: Wed, 17 Oct 2007 03:01:59 GMTServer: Apache-Coyote/1.12.3.2 http的狀態響應碼2.3.2.1 1**：請求收到，繼續處理100——客戶必須繼續發出請求101——客戶要求伺服器根據請求轉換HTTP協議版本2.3.2.2 2**：操作成功收到，分析、接受200——交易成功201——提示知道新檔案的URL202——接受和處理、但處理未完成203——返回資訊不確定或不完整204——請求收到，但返回資訊為空白205——伺服器完成了請求，使用者代理程式必須複位當前已經瀏覽 過的檔案206——伺服器已經完成了部分使用者的GET請求2.3.2.3 3**：完成此請求必須進一步 處理300——請求的資源可在多處得到301——刪除請求資料302——在其他地址發現了請求資料303——建議客戶訪問其他URL或訪問方式304——用戶端已經執行了GET，但檔案未變化305——請求的資源必須從伺服器指定的地址得到306——前一版本HTTP中使用的代碼，現行版本中不再使用307——申明請求的資源臨時性刪除2.3.2.4 4**：請求包含一個錯誤文法 或不能完成400——錯誤請求，如語法錯誤401——未授權HTTP 401.1 - 未授權：登入失敗　　HTTP 401.2 - 未授權：伺服器配置問題導致登入失敗　　HTTP 401.3 - ACL 禁止訪問資源　　HTTP 401.4 - 未授權：授權被篩選器拒絕HTTP 401.5 - 未授權：ISAPI 或 CGI 授權失敗402——保留有效ChargeTo頭響應403——禁止訪問HTTP 403.1 禁止訪問：禁止可執行訪問　　HTTP 403.2 - 禁止訪問：禁止讀訪問　　HTTP 403.3 - 禁止訪問：禁止寫訪問　　HTTP 403.4 - 禁止訪問：要求 SSL　　HTTP 403.5 - 禁止訪問：要求 SSL 128　　HTTP 403.6 - 禁止訪問：IP 位址被拒絕　　HTTP 403.7 - 禁止訪問：要求客戶認證　　HTTP 403.8 - 禁止訪問：禁止網站訪問　　HTTP 403.9 - 禁止訪問：串連的使用者過多　　HTTP 403.10 - 禁止訪問：配置無效　　HTTP 403.11 - 禁止訪問：密碼更改　　HTTP 403.12 - 禁止訪問：映射器拒絕訪問　　HTTP 403.13 - 禁止訪問：客戶認證已被吊銷　　HTTP 403.15 - 禁止訪問：客戶訪問許可過多　　HTTP 403.16 - 禁止訪問：客戶認證不可信或者無效HTTP 403.17 - 禁止訪問：客戶認證已經到期或 者尚未生效404——沒有發現檔案、查詢或URl405——使用者在Request-Line欄位定義的方法不允許406——根據使用者發送的Accept拖，請求資源不可訪問407——類似401，使用者必須首先在Proxy 伺服器上得到授權408——用戶端沒有在使用者指定的餓時間內完成請求409——對當前資源狀態，請求不能完成410——伺服器上不再有此資源且無進一步的參考地址411——伺服器拒絕使用者定義的Content-Length屬性請求412——一個或多個要求標頭欄位在當前請求中錯誤413——請求的資源大於伺服器允許的大小414——請求的資源URL長於伺服器允許的長度415——請求資源不支援要求項目格式416——請求中包含Range要求標頭欄位，在當前請求資源範圍內沒有range指示值，請求也不包含If-Range要求標頭欄位417——伺服器不滿足請求Expect頭欄位指定的期望值，如果是Proxy 伺服器，可能是下一級伺服器不能滿足請求長。2.3.2.5 5**：伺服器執行一個完全有 效請求失敗　　HTTP 500 - 內部伺服器錯誤　　HTTP 500.100 - 內部伺服器錯誤 - ASP 錯誤　　HTTP 500-11 伺服器關閉　　HTTP 500-12 應用程式重新啟動　　HTTP 500-13 - 伺服器太忙　　HTTP 500-14 - 應用程式無效　　HTTP 500-15 - 不允許請求 global.asa　　Error 501 - 未實現HTTP 502 - 網關錯誤2.4 使用telnet進行http測試 在Windows下，可使用命令視窗進行http簡單測試。 輸入cmd進入命令視窗，在命令列鍵入如下命令後按斷行符號：telnet www.baidu.com 80 而後在視窗中按下“Ctrl+]”後按斷行符號可讓返回結果回顯。接著開始發請求訊息，例如發送如下請求訊息請求baidu的首頁訊息，使用的HTTP協議為HTTP/1.1：GET /index.html HTTP/1.1 注意：copy如上的訊息到命令視窗後需要按兩個斷行符號換行才能得到響應的訊息，第一個斷行符號換行是在命令後鍵入斷行符號換 行，是HTTP協議要求的。第二個是確認輸入，發送請求。可看到返回了200 OK的訊息，如所示： 可看到， 當採用HTTP/1.1時，串連不是在請求結束後就斷開的。若採用HTTP1.0，在命令視窗鍵入：GET /index.html HTTP/1.0 此時可以看到請求結束之後馬上斷開。 讀者還可 以嘗試在使用GET或POST等時，帶上頭域資訊，例如鍵入如下資訊：GET /index.html HTTP/1.1connection: closeHost: www.baidu.com2.5 常用的請求方式 常用的請 求方式是GET和POST.l GET方式：是以實體的方式得到由請求URI所指定資源的資訊，如果請求URI只是一個資料產生過程，那麼最終要在響應實體中返回的是處理過程的結果所指向的資源，而不是處理過 程的描述。l POST方式：用來向目的伺服器發出請求，要求它接受被附在請求後的實體，並把它當作請求隊列中請求URI所指定資源的附加新子項，Post被設計成用統一的方法實現下列功能：1：對現有資源的解釋；2：向電子公告欄、新聞群組、郵件清單或類似討論群組發資訊；3：提交資料區塊；4：通過附加操作來擴充資料庫 。從上面描述可以看出，Get是向伺服器發索取資料的一種請求；而Post是向伺服器提交數 據的一種請求，要提交的資料位元於資訊頭後面的實體中。GET與POST方法有以 下區別：（1） 在用戶端，Get方式在通過URL提交資料，資料在URL中可以看到；POST方式，資料放置在HTML HEADER內提交。（2） GET方式提交的資料最多隻能有1024位元組，而POST則 沒有此限制。（3） 安全性問題。正如在（1）中提到，使用 Get 的時候，參數會顯示在地址欄上，而 Post 不會。所以，如 果這些資料是中文資料而且是非敏感性資料，那麼使用 get；如果使用者輸入 的資料不是中文字元而且包含敏感性資料，那麼還是使用 post為好。（4） 安全的和等冪的。所謂安全的意味著該操作用於擷取資訊而非修改資訊。等冪的意味著對同 一 URL 的多個請求應該返回同樣的結果。完整的定義並不像看起來那樣 嚴格。換句話說，GET 請求一般不應產生副作用。從根本上講，其目標是 當使用者開啟一個連結時，她可以確信從自身的角度來看沒有改變資源。比如，新聞網站的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認為 是安全的和等冪的，因為它總是返回當前的新聞。反之亦然。POST 請求 就不那麼輕鬆了。POST 表示可能改變伺服器上的資源的請求。仍然以新 聞網站為例，讀者對文章的註解應該通過 POST 請求實現，因為在註解 提交之後網站已經不同了（比方說文章下面出現一條註解）。 2.6 要求標頭HTTP最常見的要求標頭如下：l Accept：瀏覽器可接受的MIME類型；l Accept-Charset：瀏覽器可接受的字元集；l Accept-Encoding：瀏覽器能夠進行解碼的資料編碼方式，比如gzip。Servlet能 夠向支援gzip的瀏覽器返回經gzip編碼的HTML頁 面。許多情形下這可以減少5到10倍的下載時間；l Accept-Language：瀏覽器所希望的語言種類，當伺服器能夠提供一種以上的語言版本時要用到；l Authorization：授權資訊，通常出現在對伺服器發送的WWW-Authenticate頭的應答中；l Connection：表示是否需要持久串連。如果Servlet看到這裡的值為“Keep-Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1默 認進行持久串連），它就可以利用持久串連的優點，當頁麵包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點，Servlet需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然後在正式寫出內容之前計算它的大小；l Content-Length：表示請求訊息本文的長度；l Cookie：這是最重要的要求標頭資訊之一；l From：請求寄件者的email地址，由一些特殊的Web客戶程式使用，瀏覽器不會用到它；l Host：初始URL中的主 機和連接埠；l If-Modified-Since：只有當所請求的內容在指定的日期之後又經過修改才返回它，否則返回304“Not Modified”應答；l Pragma：指定“no-cache”值表示伺服器必須返回一個重新整理後的文檔，即使它是Proxy 伺服器而且已經有了頁面的本地拷貝；l Referer：包含一個URL， 使用者從該URL代表的頁面出發訪問當前請求的頁面。l User-Agent：瀏覽器類型，如果Servlet返回的內容與瀏覽器類型有關則該值非常有用；l UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏 覽器所發送的非標準的要求標頭，表示螢幕大小、色彩深度、作業系統和CPU類 型。2.7 回應標頭HTTP最常見的回應標頭如下所示：l Allow：伺服器支援哪些要求方法（如GET、POST等）；l Content-Encoding：文檔的編碼（Encode）方法。只有在解碼之後才可以得到Content-Type頭 指定的內容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支援它。因此，Servlet應該通過查看Accept-Encoding頭（即request.getHeader("Accept-Encoding")）檢查瀏覽器是否支援gzip，為支援gzip的瀏覽器返回經gzip壓縮的HTML頁 面，為其他瀏覽器返回普通頁面；l Content-Length：表示內容長度。只有當瀏覽器使用持久HTTP串連時才需要這個資料。如果你想要利用持久串連的優勢，可以把輸出文檔寫入ByteArrayOutputStram，完成後查看其大小，然後把該值放入Content-Length頭，最後通過byteArrayStream.writeTo(response.getOutputStream()發送內容；l Content-Type： 表示後面的文檔 屬於什麼MIME類型。Servlet預設為text/plain，但通常需要顯式地指定為text/html。由於經常要設定Content-Type，因此HttpServletResponse提供了一個專用的方法setContentTyep。 可在web.xml檔案中配置副檔名和MIME類型的對應關係；l Date：當前的GMT時 間。你可以用setDateHeader來設定這個頭以避免轉換時間格式 的麻煩；l Expires：指明應該在什麼時候認為文檔已經到期，從而不再緩衝它。l Last-Modified：文檔的最後改動時間。客戶可以通過If-Modified-Since要求標頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲於指定時間的文檔才會返回，否則返回一個304（Not Modified）狀態。Last-Modified也可用setDateHeader方法來設定；l Location：表示客戶應當到哪裡去提取文檔。Location通常不是直接設定的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設定狀態碼為302；l Refresh：表示瀏覽器應該在多少時間之後重新整理文檔，以秒計。除了重新整理當前文檔之外，你還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。注意這種功能通常是通過設定HTML頁面HEAD區的實現，這是因為，自動重新整理或重新導向對於那些不能使用CGI或Servlet的HTML編寫者十分重要。但是，對於Servlet來說，直接設定Refresh頭更加方便。注意Refresh的意義是“N秒之後重新整理本頁面或訪問指定頁面”，而不是“每隔N秒重新整理本頁面或訪問指定頁面”。因此，連續重新整理要求每次都發送一個Refresh頭，而發 送204狀態碼則可以阻止瀏覽器繼續重新整理，不管是使用Refresh頭還是。注意Refresh頭不屬於HTTP 1.1正式規範的一部分，而是一個擴充，但Netscape和IE都支援它。2.8實體頭實體頭用坐實體內容的元資訊，描述了實體內容的屬性，包括實體資訊類型，長度，壓縮方法，最後一次修 改時間，資料有效性等。l Allow：GET,POSTl Content-Encoding：文檔的編碼（Encode）方法，例如：gzip，見“2.5 回應標頭”；l Content-Language：內容的語言類型，例如：zh-cn；l Content-Length：表示內容長度，eg：80，可參考“2.5響 應頭”；l Content-Location：表示客戶應當到哪裡去提取文檔，例如：http://www.dfdf.org/dfdf.html，可參考“2.5響 應頭”；l Content-MD5：MD5 實體的一 種MD5摘要，用作校正和。發送方和接受方都計算MD5摘要，接受方將其計算的值與此頭標中傳遞的值進行比較。Eg1：Content-MD5:

(轉存 作者未知)深入理解HTML協議