HTTP狀態碼完整介紹

 

HTTP狀態碼是什麼?HTTP狀態碼有什麼用處?如何處理HTTP狀態碼可以和搜索引擎更友好?技巧在哪裏?更有利於網站優化?HTTP狀態碼如何監測?這些都是許多剛入門seo優化這個行業的新手常常問的問題，下面

HTTP狀態碼是什麼?HTTP狀態碼有什麼用處?如何處理HTTP狀態碼可以和搜索引擎更友好?技巧在哪裏?更有利於網站優化?HTTP狀態碼如何監測?這些都是許多剛入門seo優化這個行業的新手常常問的問題，下面咱們一一作出解答。 　　 Seo技巧_HTTP狀態碼是什麼? 　　HTTP協議是典型請求/響應模式，客戶端請求服務器，客戶端和服務器創建鏈接。 　　客戶端發送一段數據給服務器例以下面的一段請求： 　　Host: download.microtool.de 　　Accept: */* 　　Pragma: no-cache 　　Cache-Control: no-cache 　　User-Agent: Mozilla/4.04[en](Win95;I;Nav) 　　Range: bytes=554554- 　　服務器在接受到這個請求後向客戶端發出響應數據以下： 　　HTTP/1.0 200 OK 　　Date:Mon,31Dec200104:25:57GMT 　　Server:Apache/1.3.14(Unix) 　　Content-type:text/html 　　Last-modified:Tue,17Apr200106:46:28GMT 　　Etag:"a030f020ac7c01:1e9f" 　　Content-length:39725426 　　Content-range:bytes554554-40279979/40279980 　　服務器返回的響應中有這樣的一段數據：「HTTP/1.0 200 OK」說明客戶端請求成功，返回服務器成功狀態碼，注意如今HTTP狀態碼出現了，若是服務器發現，客戶端所請求的頁面不存在，那麼應該返回的是這段數據「HTTP/1.0404OK」下面咱們列出經常使用的HTTP狀態碼對照表： 　　 用來幫助各位seo對照本身的狀態碼。 　　Seo技巧_HTTP狀態碼有什麼用處? 　　HTTP狀態碼的做用是幫助客戶端(瀏覽器，搜索引擎)瞭解請求/響應服務器的狀態。 　　 Seo技巧_如何處理HTTP狀態碼可以和搜索引擎更友好? 　　在網站設計中，出現錯誤頁面是常常會發生的，當搜索引擎爬蟲來訪問一個網站本不存在的一個頁面時或者網站URL生成規則更改時，都會返回404錯誤頁面，這樣搜索引擎都會自動刪除搜索引擎關於這個URL的信息，問題出現了：若是是某個訪問者來到了這個404頁面，咱們怎麼辦?咱們要白白放走本身的訪客(有可能成爲本身的客戶)，不行，不能放走這個潛在的客戶，咱們seo也想到了解決的辦法，本身製做404頁面，不只提示沒有找到改網頁，咱們還在本身製做的404頁面上作一個欄目導航，供訪客再一次的點擊，可是404頁面的製做，不是幾句話能說明白的，咱們將在下一節專門介紹404頁面的製做，而且保證服務器返回的狀態碼也是404，而不是別的狀態碼。 　　301狀態碼對搜索引擎算是比較友好的，若是出現要轉移權重，建議用301永久定位。 　　好比：你有兩個域名www.xxxx.com 和xxxx.com(搜索引擎看來這是2個域名) ，爲了可以不丟失在瀏覽器中輸入seo10e的訪客，也爲了可以把權重轉移到www.xxxx.com 咱們就應該設置服務器，把xxxx.com永久定位到www.xxxx.com 。 　　總之一句話，http狀態碼技巧若是處理好，對網站優化有益無害，若是處理很差，可能會下降您的網站的權重，更有可能讓搜索殷勤爬蟲感到您的網站不太友好。 　　Seo技巧_HTTP狀態碼如何監測? 　　http狀態碼的監測，有2種方法： 　　1. 查看網站日誌 　　221.201.77.63 - - [02/Jul/2006:15:30:41 +0800] 「GET /seoblog/2006/04/17/user-friendly-website/HTTP/1.1″ 200 19031 「http://www.baidu.com/s? wd=%C2%EA%D1%C5%B2%BF%C2%E4&cl=3&tn=baiduerr″ 「Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;SV1; Alexa Toolbar)」 　　221.201.77.63 這個IP地址在 某一時刻，用get請求方式，請求過GET /seoblog/2006/04/17/user-friendly-website/HTTP/1.1 的內容，而且服務器返回了「200」狀態碼。 　　2. 經過一些網站HTTP分析軟件 httpwatch 能夠看見在訪問網站時整個頁面的請求和響應，也能看見狀態碼。若是發現那個頁面出現狀態碼問題能夠及時解決調影響seo優化對搜索引擎不友好的因素。 　　總結：HTTP狀態碼seo技巧應該注意404狀態碼和301狀態碼，若是處理很差會影響到網站和搜索引擎的友好度 服務器http請求的成功與否會返回一系列數據代碼，稱爲狀態碼，用戶客戶端和搜索引擎都會識別這寫狀態碼從而做出正確的反映！  Successful ================================= 200 OK 指示客服端的請求已經成功收到，解析，接受。 201 Created 請求已經完成並一個新的返回資源被建立。被建立的資源多是一個URI資源，一般URI資源在Location頭指定。回送應該包含一個實體數據 而且包含資源特性以及location經過用戶或者用戶代理來選擇合適的方法。實體數據格式經過煤體類型來指定即content-type頭。最開始服務器 必須建立指定的資源在返回201狀態碼以前。若是行爲沒有被馬上執行，服務器應該返回202。 202 Accepted 請求已經被接受用來處理。可是處理並無完成。請求可能或者根本沒有遵守執行，由於處理實際執行過程當中可能被拒絕。 203 Non-Authoritative Information 204 No Content 服務器已經接受請求而且不必返回實體數據，可能須要返回更新信息。回送可能包含新的或更新信息由entity-headers呈現。 205 Reset Content 服務器已經接受請求而且用戶代理應該從新設置文檔視圖。 206 Partial Content 服務器已經接受請求GET請求資源的部分。請求必須包含一個Range頭信息以指示獲取範圍可能必須包含If-Range頭信息以成立請求條件。 Redirection ================================== 300 Multiple Choices 請求資源符合任何一個呈現方式。 301 Moved Permanently 請求的資源已經被賦予一個新的URI。 302 Found 經過不一樣的URI請求資源的臨時文件。 303 See Other 304 Not Modified 若是客服端已經完成一個有條件的請求而且請求是容許的，可是這個文檔並無改變，服務器應該返回304狀態碼。304 狀態碼必定不能包含信息主體，從而一般經過一個頭字段後的第一個空行結束。 305 Use Proxy 海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo 請求的資源必須經過代理（由Location字段指定）來訪問。Location資源給出了代理的URI。 306 Unused 307 Temporary Redirect Client Error ===================== 400 Bad Request 由於錯誤的語法致使服務器沒法理解請求信息。 401 Unauthorized 若是請求須要用戶驗證。回送應該包含一個WWW-Authenticate頭字段用來指明請求資源的權限。 402 Payment Required 保留狀態碼 403 Forbidden 服務器接受請求，可是被拒絕處理。 404 Not Found 服務器已經找到任何匹配Request-URI的資源。 405 Menthod Not Allowed Request-Line請求的方法不被容許經過指定的URI。 406 Not Acceptable 407 Proxy Authentication Required 408 Reqeust Timeout 客服端沒有提交任何請求在服務器等待處理時間內。 409 Conflict 410 Gone 411 Length Required 服務器拒絕接受請求在沒有定義Content-Length字段的狀況下。 412 Precondition Failed 413 Request Entity Too Large 服務器拒絕處理請求由於請求數據超過服務器可以處理的範圍。服務器可能關閉當前鏈接來阻止客服端繼續請求。 414 Request-URI Too Long 服務器拒絕服務當前請求由於URI的長度超過了服務器的解析範圍。 415 Unsupported Media Type 服務器拒絕服務當前請求由於請求數據格式並不被請求的資源支持。 416 Request Range Not Satisfialbe 417 Expectation Failed Server Error =================================== 500 Internal Server Error 服務器遭遇異常阻止了當前請求的執行 501 Not Implemented 服務器沒有相應的執行動做來完成當前請求。 502 Bad Gateway 503 Service Unavailable 由於臨時文件超載致使服務器不能處理當前請求。 504 Gateway Timeout 505 Http Version Not Supported （一）初識HTTP消息頭 但凡搞WEB開發的人都離不開HTTP（超文本傳輸協議），而要了解HTTP，除了HTML自己之外，還有一部分不可忽視的就是HTTP消息頭。 作 過Socket編程的人都知道，當咱們設計一個通訊協議時，「消息頭/消息體」的分割方式是很經常使用的，消息頭告訴對方這個消息是幹什麼的，消息體告訴對方 怎麼幹。HTTP傳輸的消息也是這樣規定的，每個HTTP包都分爲HTTP頭和HTTP體兩部分，後者是可選的，而前者是必須的。每當咱們打開一個網 頁，在上面點擊右鍵，選擇「查看源文件」，這時看到的HTML代碼就是HTTP的消息體，那麼消息頭又在哪呢？IE瀏覽器不讓咱們看到這部分，但咱們能夠 經過截取數據包等方法看到它。 下面就來看一個簡單的例子： 首先製做一個很是簡單的網頁，它的內容只有一行： <html><body>hello world</body></html> 把它放到WEB服務器上，好比IIS，而後用IE瀏覽器請求這個頁面（http://localhost:8080/simple.htm），當咱們請求這個頁面時，瀏覽器實際作了如下四項工做： 1 解析咱們輸入的地址，從中分解出協議名、主機名、端口、對象路徑等部分，對於咱們的這個地址，解析獲得的結果以下： 協議名：http 主機名：localhost 端口：8080 對象路徑：/simple.htm 2 把以上部分結合本機本身的信息，封裝成一個HTTP請求數據包 3 使用TCP協議鏈接到主機的指定端口（localhost, 8080），併發送已封裝好的數據包 4 等待服務器返回數據，並解析返回數據，最後顯示出來 由截取到的數據包咱們不難發現瀏覽器生成的HTTP數據包的內容以下： GET /simple.htm HTTP/1.1<CR> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*<CR> Accept-Language: zh-cn<CR> Accept-Encoding: gzip, deflate<CR> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)<CR> Host: localhost:8080<CR> Connection: Keep-Alive<CR> <CR> 爲了顯示清楚我把全部的回車的地方都加上了「<CR>」，注意最後還有一個空行加一個回車，這個空行正是HTTP規定的消息頭和消息體的分界線，第一個空行如下的內容就是消息體，這個請求數據包是沒有消息體的。 消 息的第一行「GET」表示咱們所使用的HTTP動做，其餘可能的還有「POST」等，GET的消息沒有消息體，而POST消息是有消息體的，消息體的內容 就是要POST的數據。後面/simple.htm就是咱們要請求的對象，以後HTTP1.1表示使用的是HTTP1.1協議。 第二行表示咱們所用的瀏覽器能接受的Content-type，三四兩行則是語言和編碼信息，第五行顯示出本機的相關係信息，包括瀏覽器類型、操做系統信息等，不少網站能夠顯示出你所使用的瀏覽器和操做系統版本，就是由於能夠從這裏獲取到這些信息。 第六行表示咱們所請求的主機和端口，第七行表示使用Keep-Alive方式，即數據傳遞完並不當即關閉鏈接。 服務器接收到這樣的數據包之後會根據其內容作相應的處理，例如查找有沒有「/simple.htm」這個對象，若是有，根據服務器的設置來決定如何處理，若是是HTM，則不須要什麼複雜的處理，直接返回其內容便可。但在直接返回以前，還須要加上HTTP消息頭。 服務器發回的完整HTTP消息以下： HTTP/1.1 200 OK<CR> Server: Microsoft-IIS/5.1<CR> X-Powered-By: ASP.NET<CR> Date: Fri, 03 Mar 2006 06:34:03 GMT<CR> Content-Type: text/html<CR> Accept-Ranges: bytes<CR> Last-Modified: Fri, 03 Mar 2006 06:33:18 GMT<CR> ETag: "5ca4f75b8c3ec61:9ee"<CR> Content-Length: 37<CR> <CR> <html><body>hello world</body></html> 海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo 一樣，我用「<CR>」來表示回車。能夠看到，這個消息也是用空行切分紅消息頭和消息體兩部分，消息體的部分正是咱們前面寫好的HTML代碼。 消息頭第一行「HTTP/1.1」也是表示所使用的協議，後面的「200 OK」是HTTP返回代碼，200就表示操做成功，還有其餘常見的如404表示對象未找到，500表示服務器錯誤，403表示不能瀏覽目錄等等。 第 二行表示這個服務器使用的WEB服務器軟件，這裏是IIS 5.1。第三行是ASP.Net的一個附加提示，沒什麼實際用處。第四行是處理此請求的時間。第五行就是所返回的消息的content-type，瀏覽器 會根據它來決定如何處理消息體裏面的內容，例如這裏是text/html，那麼瀏覽器就會啓用HTML解析器來處理它，若是是image/jpeg，那麼 就會使用JPEG的解碼器來處理。 消息頭最後一行「Content-Length」表示消息體的長度，從空行之後的內容算起，以字節爲單位，瀏覽器接收到它所指定的字節數的內容之後就會認爲這個消息已經被完整接收了。 理解HTTP消息頭 （二） 常見的HTTP返回碼 上一篇文章裏我簡要的說了說HTTP消息頭的格式，注意到在服務器返回的HTTP消息頭裏有一個「HTTP/1.1 200 OK」，這裏的200是HTTP規定的返回代碼，表示請求已經被正常處理完成。瀏覽器經過這個返回代碼就能夠知道服務器對所發請求的處理狀況是什麼，每一 種返回代碼都有本身的含義。這裏列舉幾種常見的返回碼。 1 403 Access Forbidden 若是咱們試圖請求服務器上一個文件夾，而在WEB服務器上這個文件夾並無容許對這個文件夾列目錄的話，就會返回這個代碼。一個完整的403回覆多是這樣的：（IIS5.1） HTTP/1.1 403 Access Forbidden Server: Microsoft-IIS/5.1 Date: Mon, 06 Mar 2006 08:57:39 GMT Connection: close Content-Type: text/html Content-Length: 172 <html><head><title>Directory Listing Denied</title></head> <body><h1>Directory Listing Denied</h1>This Virtual Directory does not allow contents to be listed.</body></html> 2 404 Object not found 當咱們請求的對象在服務器上並不存在時，就會給出這個返回代碼，這可能也是最多見的錯誤代碼了。IIS給出的404消息內容很長，除了消息頭之外還有一個完整的說明「爲何會這樣」的網頁。APACHE服務器的404消息比較簡短，以下： HTTP/1.1 404 Not Found Date: Mon, 06 Mar 2006 09:03:14 GMT Server: Apache/2.0.55 (Unix) PHP/5.0.5 Content-Length: 291 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL /notexist was not found on this server.</p> <hr> <address>Apache/2.0.55 (Unix) PHP/5.0.5 Server at localhost Port 8080</address> </body></html> 也許你會問，不管是404仍是200，都會在消息體內給出一個說明網頁，那麼對於客戶端來講兩者有什麼區別呢？一個比較明顯的區別在於200是 成功請求，瀏覽器會記錄下這個地址，以便下次再訪問時能夠自動提示該地址，而404是失敗請求，瀏覽器只會顯示出返回的頁面內容，並不會記錄此地址，要再 次訪問時還須要輸入完整的地址。 3 401 Access Denied 當WEB服務器不容許匿名訪問，而咱們又沒有提供正確的用戶名/密碼時，服務器就會給出這個返回代碼。在IIS中，設置IIS的安全屬性爲不容許匿名訪問（以下圖），此時直接訪問的話就會獲得如下返回結果： HTTP/1.1 401 Access Denied Server: Microsoft-IIS/5.1 Date: Mon, 06 Mar 2006 09:15:55 GMT WWW-Authenticate: Negotiate WWW-Authenticate: NTLM Connection: close Content-Length: 3964 Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html dir=ltr> …… 此時瀏覽器上給出的提示以下圖，讓咱們輸入用戶名和密碼： 因返回信息中消息體較長，只取前面兩行內容。注意，若是是用localhost來訪問本機的IIS，因IE能夠直接取得當前用戶的身份，它會和服務器間直接進行協商，因此不會看到401提示。 當咱們在輸入了用戶名和密碼之後，服務器與客戶端會再進行兩次對話。首先客戶端向服務器索取一個公鑰，服務器端會返回一個公鑰，兩者都用BASE64編碼，相應的消息以下（編碼部分已經作了處理）： GET / HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: 192.168.0.55:8080 Connection: Keep-Alive Authorization: Negotiate ABCDEFG…… HTTP/1.1 401 Access Denied Server: Microsoft-IIS/5.1 Date: Mon, 06 Mar 2006 09:20:53 GMT WWW-Authenticate: Negotiate HIJKLMN…… Content-Length: 3715 Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html dir=ltr> …… 客戶端拿到公鑰以後使用公鑰對用戶名和密碼進行加密碼，而後把加密之後的結果從新發給服務器： GET / HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Accept-Language: zh-cn 海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: 192.168.0.55:8080 Connection: Keep-Alive Authorization: Negotiate OPQRST…… 這樣，若是驗證經過，服務器端就會把請求的內容發送過來了，也就是說禁止匿名訪問的網站會通過三次請求才能夠看到頁面。但由於客戶端瀏覽器已經緩存了公鑰，用同一個瀏覽器窗口再次請求這個網站上的其它頁面時就能夠直接發送驗證信息，從而一次交互就能夠完成了。 4 302 Object Moved 用過ASP的人都知道ASP中頁面重定向至少有Redirect和Transfer兩種方法。二的區別在於Redirect是客戶端重定向，而Transfer是服務器端重定向，那麼它們具體是如何經過HTTP消息頭實現的呢？ 先來看一下Transfer的例子： 例如ASP文件1.asp只有一行 <% Server.Transfer "1.htm" %> HTML文件1.htm也只有一行： <p>this is 1.htm</p> 若是咱們從瀏覽器裏請求1.asp，發送的請求是： GET /1.asp HTTP/1.1 Accept: */* Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: localhost:8080 Connection: Keep-Alive Cookie: ASPSESSIONIDACCTRTTT=PKKDJOPBAKMAMBNANIPIFDAP 注意請求的文件確實是1.asp，而獲得的迴應則是： HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 Date: Mon, 06 Mar 2006 12:52:44 GMT X-Powered-By: ASP.NET Content-Length: 20 Content-Type: text/html Cache-control: private <p>this is 1.htm</p> 不難看出，經過Server.Transfer語句服務器端已經作了頁面重定向，而客戶端對此一無所知，表面上看上去獲得的就是1.asp的結果。 若是把1.asp的內容改成： <% Response.Redirect "1.htm" %> 再次請求1.asp，發送的請求沒有變化，獲得的迴應卻變成了： HTTP/1.1 302 Object moved Server: Microsoft-IIS/5.1 Date: Mon, 06 Mar 2006 12:55:57 GMT X-Powered-By: ASP.NET Location: 1.htm Content-Length: 121 Content-Type: text/html Cache-control: private <head><title>Object moved</title></head> <body><h1>Object Moved</h1>This object may be found <a HREF="">here</a>.</body> 注意HTTP的返回代碼由200變成了302，表示這是一個重定向消息，客戶端須要根據消息頭中Location字段的值從新發送請求，因而就有了下面一組對話： GET /1.htm HTTP/1.1 Accept: */* Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: localhost:8080 Connection: Keep-Alive If-Modified-Since: Thu, 02 Mar 2006 06:50:13 GMT If-None-Match: "b224758ec53dc61:9f0" Cookie: ASPSESSIONIDACCTRTTT=PKKDJOPBAKMAMBNANIPIFDAP HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 X-Powered-By: ASP.NET Date: Mon, 06 Mar 2006 12:55:57 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Mon, 06 Mar 2006 12:52:32 GMT ETag: "76d85bd51c41c61:9f0" Content-Length: 20 <p>this is 1.htm</p> 很明顯，兩種重定向方式雖然看上去結果很像，但在實現原理上有很大的不一樣。 5 500 Internal Server Error 500號錯誤發生在服務器程序有錯誤的時候，例如，ASP程序爲 <% if %> 顯然這個程序並不完整，因而獲得的結果爲： HTTP/1.1 500 Internal Server Error Server: Microsoft-IIS/5.1 Date: Mon, 06 Mar 2006 12:58:55 GMT X-Powered-By: ASP.NET Content-Length: 4301 Content-Type: text/html Expires: Mon, 06 Mar 2006 12:58:55 GMT Set-Cookie: ASPSESSIONIDACCTRTTT=ALKDJOPBPPKNPCNOEPCNOOPD; path=/ Cache-control: private <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html dir=ltr> …… 服務器發送了500號錯誤，而且後面經過HTML的方式說明了錯誤的緣由。 理解HTTP消息頭 （三） （三） 客戶端發送的內容 這一次主要來觀察HTTP消息頭中客戶端的請求，從中找到一些有意思的內容。 1 HTTP_REFERER 寫兩個簡單的網頁： a.htm： <a href=b.htm>to page b</a> b.htm： haha 內容很簡單，就是網頁A中有一個到B的連接。把它們放到IIS上，並訪問網頁A，從中再點擊到B的連接，因而看到了B頁的「haha」。那麼這兩次請求有什麼不一樣嗎？觀察它們所發送的HTTP消息頭，最明顯的區別就是訪問B頁時比訪問A頁時多了一行： Referer: http://localhost/a.htm 這一行就表示，用戶要訪問的B頁是從A頁連接過來的。 服務器端要想取得這個值也是很容易的，以ASP爲例，只須要寫一句 <% =Request.ServerVariables("HTTP_REFERER") %> 就能夠了。 一 些網站經過HTTP_REFERER來作安全驗證，判斷用戶是否是從容許的頁面連接來的，而不是直接從瀏覽器上打URL或從其餘頁面連接過來，這樣能夠從 必定程度上防止網頁被作非法使用。但從上述原理來看，想要騙過服務器也並不困難，只要手工構造輸入的HTTP消息頭就能夠了，其餘經常使用的手段還有經過 HOSTS文件僞造域名等。 除了超連接之外，還有其餘幾種方式會致使HTTP_REFERER信息被髮送，如： 內聯框架：<iframe src=b.asp></iframe> 框架集：<frameset><frame src=b.asp></frameset> 表單提交：<form action=b.asp><input type=submit></form> SCRIPT引用：<script src=b.asp></script> 海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo CSS引用：<link rel=stylesheet type=text/css href=b.asp> XML數據島：<xml src=b.asp></xml> 而如下形式不會發送HTTP_REFERER： script轉向：<script>location.href="b.asp"</script> script開新窗口：<script>window.open("b.asp");</script> META轉向：<meta http-equiv="refresh" content="0;URL=b.asp"> 引入圖片：<img src=b.asp> 2 COOKIE COOKIE是你們都很是熟悉的了，經過它能夠在客戶端保存用戶狀態，即便用戶關閉瀏覽器也能繼續保存。那麼客戶端與服務器端是如何交換COOKIE信息的呢？沒錯，也是經過HTTP消息頭。 首先寫一個簡單的ASP網頁： <% Dim i i =  Request.Cookies("key") Response.Write i Response.Cookies("key") = "haha" Response.Cookies("key").Expires = #2007-1-1# %> 第 一次訪問此網頁時，屏幕上一片白，第二次訪問時，則會顯示出「haha」。經過閱讀程序不難發現，屏幕上顯示的內容其實是COOKIE的內容，而第一次 訪問時尚未設置COOKIE的值，因此不會有顯示，第二次顯示的是第一次設置的值。那麼對應的HTTP消息頭應該是什麼樣的呢？ 第一次請求時沒什麼不一樣，略過 第一次返回時消息內容多了下面這一行： Set-Cookie: key=haha; expires=Sun, 31-Dec-2006 16:00:00 GMT; path=/ 很明顯，key=haha表示鍵名爲「key」的COOKIE的值爲「haha」，後面是這則COOKIE的過時時間，由於我用的中文操做系統的時區是東八區，2007年1月1日0點對應的GMT時間就是2006年12月31日16點。 第二次再訪問此網頁時，發送的內容多了以下一行： Cookie: key=haha 它的內容就是剛纔設的COOKIE的內容。可見，客戶端在從服務器端獲得COOKIE值之後就保存在硬盤上，再次訪問時就會把它發送到服務器。發送時並無發送過時時間，由於服務器對過時時間並不關心，當COOKIE過時後瀏覽器就不會再發送它了。 如 果使用IE6.0瀏覽器而且禁用COOKIE功能，能夠發現服務器端的set-cookie仍是有的，但客戶端並不會接受它，也不會發送它。有些網站，特 別是在線投票網站經過記錄COOKIE防止用戶重複投票，破解很簡單，只要用IE6瀏覽器並禁用COOKIE就能夠了。也有的網站經過COOKIE值爲某 值來判斷用戶是否合法，這種判斷也很是容易經過手工構造HTTP消息頭來欺騙，固然用HOSTS的方式也是能夠欺騙的。 3 SESSION HTTP協議自己是無狀態的，服務器和客戶端都不保證用戶訪問期間鏈接會一直保 持，事實上保持鏈接是HTTP1.1纔有的新內容，當客戶端發送的消息頭中有「Connection: Keep-Alive」時表示客戶端瀏覽器支持保持鏈接的工做方式，但這個鏈接也會在一段時間沒有請求後自動斷開，以節省服務器資源。爲了在服務器端維持 用戶狀態，SESSION就被髮明出來了，如今各主流的動態網頁製作工具都支持SESSION，但支持的方式不徹底相同，如下皆以ASP爲例。 當用戶請求一個ASP網頁時，在返回的HTTP消息頭中會有一行： Set-Cookie: ASPSESSIONIDCSQCRTBS=KOIPGIMBCOCBFMOBENDCAKDP; path=/ 服 務器經過COOKIE的方式告訴客戶端你的SESSIONID是多少，在這裏是「KOIPGIMBCOCBFMOBENDCAKDP」，而且服務器上保留 了和此SESSIONID相關的數據，當同一用戶再次發送請求時，還會把這個COOKIE再發送回去，服務器端根據此ID找到此用戶的數據，也就實現了服 務器端用戶狀態的保存。因此咱們用ASP編程時能夠使用「session("name")=user」這樣的方式保存用戶信息。注意此COOKIE內容裏 並無過時時間，這表示這是一個當關閉瀏覽器時當即過時的COOKIE，它不會被保存到硬盤上。這種工做方式比單純用COOKIE的方式要安全不少，由於 在客戶端並無什麼能讓咱們修改和欺騙的值，惟一的信息就是SESSIONID，而這個ID在瀏覽器關閉時會當即失效，除非別人能在你瀏覽網站期間或關閉 瀏覽器後很短期內知道此ID的值，才能作一些欺騙活動。由於服務器端判斷SESSION過時的方式並非斷開鏈接或關閉瀏覽器，而是經過用戶手工結束 SESSION或等待超時，當用戶關閉瀏覽器後的一段時間裏SESSION尚未超時，因此這時若是知道了剛纔的SESSIONID，仍是能夠欺騙的。因 此最安全的辦法仍是在離開網站以前手工結束SESSION，不少網站都提供「Logout」功能，它會經過設置SESSION中的值爲已退出狀態或讓 SESSION當即過時從而起到安全的目的。 SESSION和COOKIE的方式各有優缺點。SESSION的優勢是比較安全，不容易被欺騙，缺 點是過時時間短，若是用過在超過過時時間裏沒有向服務器發送任何信息，就會被認爲超過過時了；COOKIE則相反，根據服務器端設置的超時時間，能夠長時 間保留信息，即便關機再開機也可能保留狀態，而安全性天然大打折扣。不少網站都提供兩種驗證方式相結合，若是用戶臨時用這臺電腦訪問此訪問則須要輸入用戶 名和密碼，不保存COOKIE；若是用戶使用的是本身的我的電腦，則可讓網站在本身硬盤上保留COOKIE，之後訪問時就不須要從新輸入用戶名和密碼 了。 4 POST 瀏覽器訪問服務器經常使用的方式有GET和POST兩種，GET方式只發送HTTP消息 頭，沒有消息體，也就是除了要GET的基本信息以外不向服務器提供其餘信息，網頁表單（FROM）的默認提交方式就是用GET方式，它會把全部向服務器提 交的信息都做爲URL後面的參數，如a.asp?a=1&b=2這樣的方式。而當要提交的數據量很大，或者所提交內容不但願別人直接看到時，應該 使用POST方式。POST方式提交的數據是做爲HTTP消息體存在的，例如，寫一個網頁表單： <form method=post> <input type=text name=text1> <input type=submit> </form> 訪問此網頁，並在表單中填入一個「haha」，而後提交，能夠看到這次提交所發送的信息以下： POST /form.asp HTTP/1.1 Accept: */* Referer: http://localhost:8080/form.asp Accept-Language: zh-cn 海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: localhost:8080 Content-Length: 10 Connection: Keep-Alive Cache-Control: no-cache Cookie: key=haha; ASPSESSIONIDCSQCRTBS=LOIPGIMBLMNOGCOBOMPJBOKP text1=haha 前 面關鍵字從「GET」變爲了「POST」，Content-Type變成了「application/x-www-form-urlencoded」，後 面內容並沒有大變化，只是多了一行：Content-Length: 10，表示提交的內容的長度。空行後面是消息體，內容就是表單中所填的內容。注意此時發送的內容只是「Name=Value」的形式，表單上其餘的信息不 會被髮送，因此想直接從服務器端取得list box中全部的list item是辦不到的，除非在提交前用一段script把全部的item內容都連在一塊兒放到一個隱含表單域中。 若是是用表單上傳文件，狀況就要複雜一些了，首先是表單聲明中要加上一句話：enctype=’multipart/form-data’，表示這個表單將提交多段數據，並用HTML：input type=file來聲明一個文件提交域。 表單內容以下： <form method=post enctype=’multipart/form-data’> <input type=text name=text1> <input type=file name=file1> <input type=submit> </form> 咱們爲text1輸入文字：hehe，爲file1選擇文件haha.txt，其內容爲「ABCDEFG」，而後提交此表單。提交的徹底信息爲： POST /form.asp HTTP/1.1 Accept: */* Referer: http://localhost:8080/form.asp Accept-Language: zh-cn Content-Type: multipart/form-data; boundary=—————————7d62bf2f9066c Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: localhost:8080 Content-Length: 337 Connection: Keep-Alive Cache-Control: no-cache Cookie: key=haha; ASPSESSIONIDCSQCRTBS=LOIPGIMBLMNOGCOBOMPJBOKP —————————–7d62bf2f9066c Content-Disposition: form-data; name="text1" hehe —————————–7d62bf2f9066c Content-Disposition: form-data; name="file1"; filename="H:\Documents and Settings\Administrator\桌面\haha.txt" Content-Type: text/plain ABCDEFG —————————–7d62bf2f9066c– 顯然這個提交的信息要比前述的複雜不少。Content-Type變成了「multipart/form-data」，後面還多了一個 boundary，此值是爲了區分POST的內容的區段用的，只要在內容中遇到了此值，就表示下面要開始一個新的區段了，每一個區段的內容相對獨立。若是遇 到的是此值後面連着兩個減號，則表示所有內容到此結束。每一個段也分爲段頭和段體兩部分，用空行隔開，每段都有本身的類型和相關信息。如第一區段是 text1的值，它的名稱是「text1」，值爲「hehe」。第二段是文件內容，段首裏代表了此文件域的名稱「file1」和此文件在用戶磁盤上的位 置，後面就是文件的內容。 若是咱們想要本身寫一個上傳文件組件來接收HTML表單傳送的文件數據，那麼最核心的任務就是解析此數據包，從中取得須要的信息。 理解HTTP消息頭 （四） 服務器返回的消息 服務器返回的HTTP消息也分爲消息頭和消息體兩部分。前面連載的第二篇裏已經介紹了返回消息中常見返回代碼的含義。對於非正常的返回代碼的處理比較簡單，只要照着要求去作就行了，而對於正常的返回代碼（200），其處理方式就多種多樣了。 1 Content-Type Content-Type是返回消息中很是重要的內容，它標識出這個返回內容的類型，其值爲「主類型/子類型」的格式，例如最多見的就是 text/html，它的意思是說返回的內容是文本類型，這個文本又是HTML格式的。原則上瀏覽器會根據Content-Type來決定如何顯示返回的 消息體內容。常見的內容類型有： text/html HTML文本 image/jpeg JPG圖片 image/gif GIF圖片 application/xml XML文檔 audio/x-mpegurl MP3文件列表，若是安裝了Winamp，則能夠直接把它當面M3U文件來打開 更多的內容類型能夠在註冊表「HKCR\MIME\Database\Content Type」下看到 對於IE6瀏覽器來講，若是Content-Type中的類型和實際的消息體類型不一致，那麼它會根據內容中的類型來分析實際應該是什麼類型，對於JPG、GIF等經常使用圖片格式均可以正確的識別出來，而無論Content-Type中寫的是什麼。 如 果Content-Type中指定的是瀏覽器能夠直接打開的類型，那麼瀏覽器就會直接打開其內容顯示出來，若是是被關聯到其它應用程序的類型，這時就要查 找註冊表中關於這種類型的註冊狀況，若是是容許直接打開而不須要詢問的，就會直接調出這個關聯的應用程序來打開這個文件，但若是是不容許直接打開的，就會 詢問是否打開。對於沒有關聯到任何應用程序的類型，IE瀏覽器不知道它該如何打開，此時IE6就會把它當成XML來嘗試打開。 2 Content-Disposition 若是用AddHeader的方法在HTTP消息頭中加入Content-Disposition段，並指定其值爲「attachment」，那 麼不管這個文件是何類型，瀏覽器都會提示咱們下載此文件，由於此時它認爲後面的消息體是一個「附件」，不須要由瀏覽器來處理了。例如，在ASP.Net中 寫入以下語句： Response.AddHeader("Content-Disposition: attachment"); 請求此頁面是獲得的結果如： HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 Date: Thu, 23 Mar 2006 07:54:53 GMT Content-Disposition: attachment Cache-Control: private Content-Type: text/html; charset=utf-8 …… 也 就是說，經過AddHeader函數能夠爲HTTP消息頭加入咱們自定義的內容。使用這種方法能夠強制讓瀏覽器提示下載文件，即便這個文件是咱們已知的類 型，基因而HTML網頁。若是想要讓用戶下載時提示一個默認的文件名，只須要在前面一句話後加上「filename=文件名」便可。例如： 海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo Response.AddHeader("Content-Disposition: attachment; filename=mypage.htm"); 3 Content-Type與Content-Disposition 若是把Content-Type和Content-Disposition結合在一塊兒使用會怎麼樣呢？ 打開一個網頁時，瀏覽器會首先看是否有Content-Disposition: attachment這一項，若是有，不管Content-Type的值是什麼，都會提示文件下載。 如 果指定了filename，就會提示默認的文件名爲此文件名。注意到在IE6中除了「保存」按扭外還有「打開」按扭，此時打開文件的類型是由在 filename中指定的文件擴展名決定的，例如讓filename=mypic.jpg，瀏覽器就會查找默認的圖片查看器來打開此文件。 若是沒 有指定filename，那麼瀏覽器就根據Content-Type中的類型來決定文件的類型，例如Content-Type類型爲image/gif， 那麼就會去查找默認的看GIF圖片的工具，而且設置此文件的名字爲所請求的網頁的主名（不帶擴展名）加上對應於此文件類弄擴展名，例如請求的 mypage.aspx，就會自動變成mypage.gif。若是並無指定Content-Type值，那麼就默認它爲「text/html」，而且保 存的文件名就是所請求的網頁文件名。 但若是沒有指定Content-Disposition，那麼就和前面關於Content-Type中所討論的狀況是同樣的了。 4 Cache 返回消息中的Cache用於指定網頁緩存。咱們常常能夠看到這樣的狀況，打開一個網頁時速度不快，但再次打開時就會快不少，緣由是瀏覽器已經對此頁 面進行了緩存，那麼在同一瀏覽器窗口中再次打開此頁時不會從新從服務器端獲取。網頁的緩存是由HTTP消息頭中的「Cache-control」來控制 的，常見的取值有private、no-cache、max-age、must-revalidate等，默認爲private。其做用根據不一樣的從新瀏 覽方式分爲如下幾種狀況： （1） 打開新窗口 若是指定cache-control的值爲private、no-cache、must-revalidate，那麼打開新窗口訪問時都會從新訪問服務器。而若是指定了max-age值，那麼在此值內的時間裏就不會從新訪問服務器，例如： Cache-control: max-age=5 表示當訪問此網頁後的5秒內再次訪問不會去服務器 （2） 在地址欄回車 若是值爲private或must-revalidate（和網上說的不同），則只有第一次訪問時會訪問服務器，之後就再也不訪問。若是值爲no-cache，那麼每次都會訪問。若是值爲max-age，則在過時以前不會重複訪問。 （3） 按後退按扭 若是值爲private、must-revalidate、max-age，則不會重訪問，而若是爲no-cache，則每次都重複訪問 （4） 按刷新按扭 不管爲什麼值，都會重複訪問 當指定Cache-control值爲「no-cache」時，訪問此頁面不會在Internet臨時文章夾留下頁面備份。 另外，經過指定「Expires」值也會影響到緩存。例如，指定Expires值爲一個早已過去的時間，那麼訪問此網時若重複在地址欄按回車，那麼每次都會重複訪問： Expires: Fri, 31 Dec 1999 16:00:00 GMT 在ASP中，能夠經過Response對象的Expires、ExpiresAbsolute屬性控制Expires值；經過Response對象的CacheControl屬性控制Cache-control的值，例如： Response.ExpiresAbsolute = #2000-1-1# ’ 指定絕對的過時時間，這個時間用的是服務器當地時間，會被自動轉換爲GMT時間 Response.Expires = 20  ’ 指定相對的過時時間，以分鐘爲單位，表示從當前時間起過多少分鐘過時。 Response.CacheControl = "no-cache" HTTP狀態碼（HTTP Status Code）是用以表示網頁服務器HTTP響應狀態的3位數字代碼。它由RFC 2616規範定義的，並獲得RFC 251八、RFC 281七、RFC 229五、RFC 277四、RFC 4918等規範擴展。 全部狀態碼的第一個數字表明瞭響應的五種狀態之一。 目錄  1 1xx消息 2 2xx成功 3 3xx重定向 4 4xx請求錯誤 5 5xx服務器錯誤 6 參考 7 引用文獻 8 外部連接 1xx 消息 這一類型的狀態碼，表明請求已被接受，須要繼續處理。這類響應是臨時響應，只包含狀態行和某些可選的響應頭信息，並以空行結束。因爲HTTP/1.0協議中沒有定義任何1xx狀態碼，因此除非在某些試驗條件下，服務器禁止向此類客戶端發送1xx響應。 這些狀態碼錶明的響應都是信息性的，標示客戶應該採起的其餘行動。 100 Continue 客戶端應當繼續發送請求。這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收，且仍未被拒絕。客戶端應當繼續發送請求的剩餘部分，或者若是請求已經完成，忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應。 101 Switching Protocols 服務器已經理解了客戶端的請求，並將經過Upgrade消息頭通知客戶端採用不一樣的協議來完成這個請求。在發送完這個響應最後的空行後，服務器將會切換到在Upgrade消息頭中定義的那些協議。: 只有在切換新的協議更有好處的時候才應該採起相似措施。例如，切換到新的HTTP版本比舊版本更有優點，或者切換到一個實時且同步的協議以傳送利用此類特性的資源。 102 Processing 由WebDAV（RFC 2518）擴展的狀態碼，表明處理將被繼續執行。 2xx 成功 這一類型的狀態碼，表明請求已成功被服務器接收、理解、並接受。 200 OK 請求已成功，請求所但願的響應頭或數據體將隨此響應返回。 201 Created 請求已經被實現，並且有一個新的資源已經依據請求的須要而建立，且其URI已經隨Location頭信息返回。假如須要的資源沒法及時建立的話，應當返回'202 Accepted'。 202 Accepted 服務器已接受請求，但還沒有處理。正如它可能被拒絕同樣，最終該請求可能會也可能不會被執行。在異步操做的場合下，沒有比發送這個狀態碼更方便的作法了。:返回202狀態碼的響應的目的是容許服務器接受其餘過程的請求（例如某個天天只執行一次的基於批處理的操做），而沒必要讓客戶端一直保持與服務器的鏈接直到批處理操做所有完成。在接受請求處理並返回202狀態碼的響應應當在返回的實體中包含一些指示處理當前狀態的信息，以及指向處理狀態監視器或狀態預測的指針，以便用戶可以估計操做是否已經完成。 海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo 203 Non-Authoritative Information 服務器已成功處理了請求，但返回的實體頭部元信息不是在原始服務器上有效的肯定集合，而是來自本地或者第三方的拷貝。當前的信息多是原始版本的子集或者超集。例如，包含資源的元數據可能致使原始服務器知道元信息的超級。使用此狀態碼不是必須的，並且只有在響應不使用此狀態碼便會返回200 OK的狀況下才是合適的。 204 No Content 服務器成功處理了請求，但不須要返回任何實體內容，而且但願返回更新了的元信息。響應可能經過實體頭部的形式，返回新的或更新後的元信息。若是存在這些頭部信息，則應當與所請求的變量相呼應。 若是客戶端是瀏覽器的話，那麼用戶瀏覽器應保留髮送了該請求的頁面，而不產生任何文檔視圖上的變化，即便按照規範新的或更新後的元信息應當被應用到用戶瀏覽器活動視圖中的文檔。 因爲204響應被禁止包含任何消息體，所以它始終以消息頭後的第一個空行結尾。 205 Reset Content 服務器成功處理了請求，且沒有返回任何內容。可是與204響應不一樣，返回此狀態碼的響應要求請求者重置文檔視圖。該響應主要是被用於接受用戶輸入後，當即重置表單，以便用戶可以輕鬆地開始另外一次輸入。 與204響應同樣，該響應也被禁止包含任何消息體，且以消息頭後的第一個空行結束。 206 Partial Content 服務器已經成功處理了部分GET請求。相似於FlashGet或者迅雷這類的HTTP 下載工具都是使用此類響應實現斷點續傳或者將一個大文檔分解爲多個下載段同時下載。 該請求必須包含Range頭信息來指示客戶端但願獲得的內容範圍，而且可能包含If-Range來做爲請求條件。 響應必須包含以下的頭部域： Content-Range用以指示本次響應中返回的內容的範圍；若是是Content-Type爲multipart/byteranges的多段下載，則每一multipart段中都應包含Content-Range域用以指示本段的內容範圍。假如響應中包含Content-Length，那麼它的數值必須匹配它返回的內容範圍的真實字節數。 Date ETag和／或Content-Location，假如一樣的請求本應該返回200響應。 Expires, Cache-Control，和／或Vary，假如其值可能與以前相同變量的其餘響應對應的值不一樣的話。 假如本響應請求使用了If-Range強緩存驗證，那麼本次響應不該該包含其餘實體頭；假如本響應的請求使用了If-Range弱緩存驗證，那麼本次響應禁止包含其餘實體頭；這避免了緩存的實體內容和更新了的實體頭信息之間的不一致。不然，本響應就應當包含全部本應該返回200響應中應當返回的全部實體頭部域。 假如ETag或Last-Modified頭部不能精確匹配的話，則客戶端緩存應禁止將206響應返回的內容與以前任何緩存過的內容組合在一塊兒。 任何不支持Range以及Content-Range頭的緩存都禁止緩存206響應返回的內容。 207 Multi-Status 由WebDAV(RFC 2518)擴展的狀態碼，表明以後的消息體將是一個XML消息，而且可能依照以前子請求數量的不一樣，包含一系列獨立的響應代碼。 3xx 重定向 這類狀態碼錶明須要客戶端採起進一步的操做才能完成請求。一般，這些狀態碼用來重定向，後續的請求地址（重定向目標）在本次響應的Location域中指明。 當且僅當後續的請求所使用的方法是GET或者HEAD時，用戶瀏覽器才能夠在沒有用戶介入的狀況下自動提交所須要的後續請求。客戶端應當自動監測無限循環重定向（例如：A->A，或者A->B->C->A），由於這會致使服務器和客戶端大量沒必要要的資源消耗。按照HTTP/1.0版規範的建議，瀏覽器不該自動訪問超過5次的重定向。 300 Multiple Choices 被請求的資源有一系列可供選擇的回饋信息，每一個都有本身特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器可以自行選擇一個首選的地址進行重定向。 除非這是一個HEAD請求，不然該響應應當包括一個資源特性及地址的列表的實體，以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由Content-Type定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力，自動做出最合適的選擇。固然，RFC 2616規範並無規定這樣的自動選擇該如何進行。 若是服務器自己已經有了首選的回饋選擇，那麼在Location中應當指明這個回饋的URI；瀏覽器可能會將這個Location值做爲自動重定向的地址。此外，除非額外指定，不然這個響應也是可緩存的。 301 Moved Permanently 被請求的資源已永久移動到新位置，而且未來任何對此資源的引用都應該使用本響應返回的若干個URI之一。若是可能，擁有連接編輯功能的客戶端應當自動把請求的地址修改成從服務器反饋回來的地址。除非額外指定，不然這個響應也是可緩存的。 新的永久性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。 若是這不是一個GET或者HEAD請求，所以瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。 注意：對於某些使用HTTP/1.0協議的瀏覽器，當它們發送的POST請求獲得了一個301響應的話，接下來的重定向請求將會變成GET方式。 302 Found 請求的資源如今臨時從不一樣的URI響應請求。因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。 新的臨時性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。 海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo 若是這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。 注意：雖然RFC 1945和RFC 2068規範不容許客戶端在重定向時改變請求的方法，可是不少現存的瀏覽器將302響應視做爲303響應，而且使用GET方式訪問在Location中規定的URI，而無視原先請求的方法。狀態碼303和307被添加了進來，用以明確服務器期待客戶端進行何種反應。 303 See Other 對應當前請求的響應能夠在另外一個URI上被找到，並且客戶端應當採用GET的方式訪問那個資源。這個方法的存在主要是爲了容許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的URI不是原始資源的替代引用。同時，303響應禁止被緩存。固然，第二個請求（重定向）可能被緩存。 新的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。 注意：許多HTTP/1.1版之前的瀏覽器不能正確理解303狀態。若是須要考慮與這些瀏覽器之間的互動，302狀態碼應該能夠勝任，由於大多數的瀏覽器處理302響應時的方式偏偏就是上述規範要求客戶端處理303響應時應當作的。 304 Not Modified 若是客戶端發送了一個帶條件的GET請求且該請求已被容許，而文檔的內容（自上次訪問以來或者根據請求的條件）並無改變，則服務器應當返回這個狀態碼。304響應禁止包含消息體，所以始終以消息頭後的第一個空行結尾。 該響應必須包含如下的頭信息： Date，除非這個服務器沒有時鐘。假如沒有時鐘的服務器也遵照這些規則，那麼代理服務器以及客戶端能夠自行將Date字段添加到接收到的響應頭中去（正如RFC 2068中規定的同樣），緩存機制將會正常工做。 ETag和／或Content-Location，假如一樣的請求本應返回200響應。 Expires, Cache-Control，和／或Vary，假如其值可能與以前相同變量的其餘響應對應的值不一樣的話。 假如本響應請求使用了強緩存驗證，那麼本次響應不該該包含其餘實體頭；不然（例如，某個帶條件的GET請求使用了弱緩存驗證），本次響應禁止包含其餘實體頭；這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。 假如某個304響應指明瞭當前某個實體沒有緩存，那麼緩存系統必須忽視這個響應，而且重複發送不包含限制條件的請求。 假如接收到一個要求更新某個緩存條目的304響應，那麼緩存系統必須更新整個條目以反映全部在響應中被更新的字段的值。 305 Use Proxy 被請求的資源必須經過指定的代理才能被訪問。Location域中將給出指定的代理所在的URI信息，接收者須要重複發送一個單獨的請求，經過這個代理才能訪問相應資源。只有原始服務器才能建立305響應。 注意：RFC 2068中沒有明確305響應是爲了重定向一個單獨的請求，並且只能被原始服務器建立。忽視這些限制可能致使嚴重的安全後果。 306 Switch Proxy 在最新版的規範中，306狀態碼已經再也不被使用。 307 Temporary Redirect 請求的資源如今臨時從不一樣的URI響應請求。因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。 新的臨時性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。由於部分瀏覽器不能識別307響應，所以須要添加上述必要信息以便用戶可以理解並向新的URI發出訪問請求。 若是這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。 4xx 請求錯誤 這類的狀態碼錶明瞭客戶端看起來可能發生了錯誤，妨礙了服務器的處理。除非響應的是一個HEAD請求，不然服務器就應該返回一個解釋當前錯誤情況的實體，以及這是臨時的仍是永久性的情況。這些狀態碼適用於任何請求方法。瀏覽器應當向用戶顯示任何包含在此類錯誤響應中的實體內容。 若是錯誤發生時客戶端正在傳送數據，那麼使用TCP的服務器實現應當仔細確保在關閉客戶端與服務器之間的鏈接以前，客戶端已經收到了包含錯誤信息的數據包。若是客戶端在收到錯誤信息後繼續向服務器發送數據，服務器的TCP棧將向客戶端發送一個重置數據包，以清除該客戶端全部還未識別的輸入緩衝，以避免這些數據被服務器上的應用程序讀取並干擾後者。 400 Bad Request 因爲包含語法錯誤，當前請求沒法被服務器理解。除非進行修改，不然客戶端不該該重複提交這個請求。 401 Unauthorized 當前請求須要用戶驗證。該響應必須包含一個適用於被請求資源的WWW-Authenticate信息頭用以詢問用戶信息。客戶端能夠重複提交一個包含恰當的Authorization頭信息的請求。若是當前請求已經包含了Authorization證書，那麼401響應表明着服務器驗證已經拒絕了那些證書。若是401響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向用戶展現響應中包含的實體信息，由於這個實體信息中可能包含了相關診斷信息。參見RFC 2617。 402 Payment Required 該狀態碼是爲了未來可能的需求而預留的。 403 Forbidden 服務器已經理解請求，可是拒絕執行它。與401響應不一樣的是，身份驗證並不能提供任何幫助，並且這個請求也不該該被重複提交。若是這不是一個HEAD請求，並且服務器但願可以講清楚爲什麼請求不能被執行，那麼就應該在實體內描述拒絕的緣由。固然服務器也能夠返回一個404響應，假如它不但願讓客戶端得到任何信息。 海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo 404 Not Found 請求失敗，請求所但願獲得的資源未被在服務器上發現。沒有信息可以告訴用戶這個情況究竟是暫時的仍是永久的。假如服務器知道狀況的話，應當使用410狀態碼來告知舊資源由於某些內部的配置機制問題，已經永久的不可用，並且沒有任何能夠跳轉的地址。404這個狀態碼被普遍應用於當服務器不想揭示到底爲什麼請求被拒絕或者沒有其餘適合的響應可用的狀況下。 405 Method Not Allowed 請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個Allow頭信息用以表示出當前資源可以接受的請求方法的列表。 鑑於PUT，DELETE方法會對服務器上的資源進行寫操做，於是絕大部分的網頁服務器都不支持或者在默認配置下不容許上述請求方法，對於此類請求均會返回405錯誤。 406 Not Acceptable 請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體。 除非這是一個HEAD請求，不然該響應就應當返回一個包含可讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址列表的實體。實體的格式由Content-Type頭中定義的媒體類型決定。瀏覽器能夠根據格式及自身能力自行做出最佳選擇。可是，規範中並無定義任何做出此類自動選擇的標準。 407 Proxy Authentication Required 與401響應相似，只不過客戶端必須在代理服務器上進行身份驗證。代理服務器必須返回一個Proxy-Authenticate用以進行身份詢問。客戶端能夠返回一個Proxy-Authorization信息頭用以驗證。參見RFC 2617。 408 Request Timeout 請求超時。客戶端沒有在服務器預備等待的時間內完成一個請求的發送。客戶端能夠隨時再次提交這一請求而無需進行任何更改。 409 Conflict 因爲和被請求的資源的當前狀態之間存在衝突，請求沒法完成。這個代碼只容許用在這樣的狀況下才能被使用：用戶被認爲可以解決衝突，而且會從新提交新的請求。該響應應當包含足夠的信息以便用戶發現衝突的源頭。 衝突一般發生於對PUT請求的處理中。例如，在採用版本檢查的環境下，某次PUT提交的對特定資源的修改請求所附帶的版本信息與以前的某個（第三方）請求向衝突，那麼此時服務器就應該返回一個409錯誤，告知用戶請求沒法完成。此時，響應實體中極可能會包含兩個衝突版本之間的差別比較，以便用戶從新提交歸併之後的新版本。 410 Gone 被請求的資源在服務器上已經再也不可用，並且沒有任何已知的轉發地址。這樣的情況應當被認爲是永久性的。若是可能，擁有連接編輯功能的客戶端應當在得到用戶許可後刪除全部指向這個地址的引用。若是服務器不知道或者沒法肯定這個情況是不是永久的，那麼就應該使用404狀態碼。除非額外說明，不然這個響應是可緩存的。 410響應的目的主要是幫助網站管理員維護網站，通知用戶該資源已經再也不可用，而且服務器擁有者但願全部指向這個資源的遠端鏈接也被刪除。這類事件在限時、增值服務中很廣泛。一樣，410響應也被用於通知客戶端在當前服務器站點上，本來屬於某個我的的資源已經再也不可用。固然，是否須要把全部永久不可用的資源標記爲'410 Gone'，以及是否須要保持此標記多長時間，徹底取決於服務器擁有者。 411 Length Required 服務器拒絕在沒有定義Content-Length頭的狀況下接受請求。在添加了代表請求消息體長度的有效Content-Length頭以後，客戶端能夠再次提交該請求。 412 Precondition Failed 服務器在驗證在請求的頭字段中給出先決條件時，沒能知足其中的一個或多個。這個狀態碼容許客戶端在獲取資源時在請求的元信息（請求頭字段數據）中設置先決條件，以此避免該請求方法被應用到其但願的內容之外的資源上。 413 Request Entity Too Large 服務器拒絕處理當前請求，由於該請求提交的實體數據大小超過了服務器願意或者可以處理的範圍。此種狀況下，服務器能夠關閉鏈接以避免客戶端繼續發送此請求。 若是這個情況是臨時的，服務器應當返回一個Retry-After的響應頭，以告知客戶端能夠在多少時間之後從新嘗試。 414 Request-URI Too Long 請求的URI長度超過了服務器可以解釋的長度，所以服務器拒絕對該請求提供服務。這比較少見，一般的狀況包括： 本應使用POST方法的表單提交變成了GET方法，致使查詢字符串（Query String）過長。 重定向URI「黑洞」，例如每次重定向把舊的URI做爲新的URI的一部分，致使在若干次重定向後URI超長。 客戶端正在嘗試利用某些服務器中存在的安全漏洞攻擊服務器。這類服務器使用固定長度的緩衝讀取或操做請求的URI，當GET後的參數超過某個數值後，可能會產生緩衝區溢出，致使任意代碼被執行[1]。沒有此類漏洞的服務器，應當返回414狀態碼。 415 Unsupported Media Type 對於當前請求的方法和所請求的資源，請求中提交的實體並非服務器中所支持的格式，所以請求被拒絕。 416 Requested Range Not Satisfiable 若是請求中包含了Range請求頭，而且Range中指定的任何數據範圍都與當前資源的可用範圍不重合，同時請求中又沒有定義If-Range請求頭，那麼服務器就應當返回416狀態碼。 假如Range使用的是字節範圍，那麼這種狀況就是指請求指定的全部數據範圍的首字節位置都超過了當前資源的長度。服務器也應當在返回416狀態碼的同時，包含一個Content-Range實體頭，用以指明當前資源的長度。這個響應也被禁止使用multipart/byteranges做爲其Content-Type。 417 Expectation Failed 在請求頭Expect中指定的預期內容沒法被服務器知足，或者這個服務器是一個代理服務器，它有明顯的證據證實在當前路由的下一個節點上，Expect的內容沒法被知足。 418 I'm a teapot 本操做碼是在1998年做爲IETF的傳統愚人節笑話, 在RFC 2324 超文本咖啡壺控制協議中定義的，並不須要在真實的HTTP服務器中定義。 海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo 421 There are too many connections from your internet address 從當前客戶端所在的IP地址到服務器的鏈接數超過了服務器許可的最大範圍。一般，這裏的IP地址指的是從服務器上看到的客戶端地址（好比用戶的網關或者代理服務器地址）。在這種狀況下，鏈接數的計算可能涉及到不止一個終端用戶。 422 Unprocessable Entity 請求格式正確，可是因爲含有語義錯誤，沒法響應。（RFC 4918 WebDAV） 423 Locked 當前資源被鎖定。（RFC 4918 WebDAV） 424 Failed Dependency 因爲以前的某個請求發生的錯誤，致使當前請求失敗，例如PROPPATCH。（RFC 4918 WebDAV） 425 Unordered Collection 在WebDav Advanced Collections草案中定義，可是未出如今《WebDAV順序集協議》（RFC 3658）中。 426 Upgrade Required 客戶端應當切換到TLS/1.0。（RFC 2817） 449 Retry With 由微軟擴展，表明請求應當在執行完適當的操做後進行重試。 5xx 服務器錯誤 這類狀態碼錶明瞭服務器在處理請求的過程當中有錯誤或者異常狀態發生，也有多是服務器意識到以當前的軟硬件資源沒法完成對請求的處理。除非這是一個HEAD請求，不然服務器應當包含一個解釋當前錯誤狀態以及這個情況是臨時的仍是永久的解釋信息實體。瀏覽器應當向用戶展現任何在當前響應中被包含的實體。 這些狀態碼適用於任何響應方法。 500 Internal Server Error 服務器遇到了一個不曾預料的情況，致使了它沒法完成對請求的處理。通常來講，這個問題都會在服務器的程序碼出錯時出現。 501 Not Implemented 服務器不支持當前請求所須要的某個功能。當服務器沒法識別請求的方法，而且沒法支持其對任何資源的請求。 502 Bad Gateway 做爲網關或者代理工做的服務器嘗試執行請求時，從上游服務器接收到無效的響應。 503 Service Unavailable 因爲臨時的服務器維護或者過載，服務器當前沒法處理請求。這個情況是臨時的，而且將在一段時間之後恢復。若是可以預計延遲時間，那麼響應中能夠包含一個Retry-After頭用以標明這個延遲時間。若是沒有給出這個Retry-After信息，那麼客戶端應當以處理500響應的方式處理它。 504 Gateway Timeout 做爲網關或者代理工做的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如HTTP、FTP、LDAP）或者輔助服務器（例如DNS）收到響應。 注意：某些代理服務器在DNS查詢超時時會返回400或者500錯誤 505 HTTP Version Not Supported 服務器不支持，或者拒絕支持在請求中使用的HTTP版本。這暗示着服務器不能或不肯使用與客戶端相同的版本。響應中應當包含一個描述了爲什麼版本不被支持以及服務器支持哪些協議的實體。 506 Variant Also Negotiates 由《透明內容協商協議》（RFC 2295）擴展，表明服務器存在內部配置錯誤：被請求的協商變元資源被配置爲在透明內容協商中使用本身，所以在一個協商處理中不是一個合適的重點。 507 Insufficient Storage 服務器沒法存儲完成請求所必須的內容。這個情況被認爲是臨時的。WebDAV（RFC 4918） 509 Bandwidth Limit Exceeded 服務器達到帶寬限制。這不是一個官方的狀態碼，可是仍被普遍使用。 510 Not Extended 獲取資源所須要的策略並無沒知足。（RFC 2774） 引言                                         HTTP是一個屬於應用層的面 向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，通過幾年的使用與發展，獲得不斷地完善和擴展。目前在WWW中 使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工做正在進行之中，並且HTTP-NG(Next Generation of HTTP)的建議已經提出。 HTTP協議的主要特色可歸納以下： 1.支持客戶/服務器模式。 2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。 3.靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。 4.無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。 5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。 1、HTTP協議詳解之URL篇     http（超文本傳輸協議）是一個基於請求與響應模式的、無狀態的、應用層的協議，常基於TCP的鏈接方式，HTTP1.1版本中給出一種持續鏈接的機制，絕大多數的Web開發，都是構建在HTTP協議之上的Web應用。 HTTP URL (URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息)的格式以下： http://host[":"port][abs_path] http 表示要經過HTTP協議來定位網絡資源；host表示合法的Internet主機域名或者IP地址；port指定一個端口號，爲空則使用缺省端口 80；abs_path指定請求資源的URI；若是URL中沒有給出abs_path，那麼當它做爲請求URI時，必須以「/」的形式給出，一般這個工做 瀏覽器自動幫咱們完成。 eg: 一、輸入：www.guet.edu.cn 瀏覽器自動轉換成：http://www.guet.edu.cn/ 二、http:192.168.0.116:8080/index.jsp  海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo 2、HTTP協議詳解之請求篇     http請求由三部分組成，分別是：請求行、消息報頭、請求正文 一、請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本，格式以下：Method Request-URI HTTP-Version CRLF   其中 Method表示請求方法；Request-URI是一個統一資源標識符；HTTP-Version表示請求的HTTP協議版本；CRLF表示回車和換行（除了做爲結尾的CRLF外，不容許出現單獨的CR或LF字符）。 請求方法（全部方法全爲大寫）有多種，各個方法的解釋以下： GET     請求獲取Request-URI所標識的資源 POST    在Request-URI所標識的資源後附加新的數據 HEAD    請求獲取由Request-URI所標識的資源的響應消息報頭 PUT     請求服務器存儲一個資源，並用Request-URI做爲其標識 DELETE  請求服務器刪除Request-URI所標識的資源 TRACE   請求服務器回送收到的請求信息，主要用於測試或診斷 CONNECT 保留未來使用 OPTIONS 請求查詢服務器的性能，或者查詢與資源相關的選項和需求 應用舉例： GET方法：在瀏覽器的地址欄中輸入網址的方式訪問網頁時，瀏覽器採用GET方法向服務器獲取資源，eg:GET /form.html HTTP/1.1 (CRLF) POST方法要求被請求服務器接受附在請求後面的數據，經常使用於提交表單。 eg：POST /reg.jsp HTTP/ (CRLF) Accept:image/gif,image/x-xbit,... (CRLF) ... HOST:www.guet.edu.cn (CRLF) Content-Length:22 (CRLF) Connection:Keep-Alive (CRLF) Cache-Control:no-cache (CRLF) (CRLF)         //該CRLF表示消息報頭已經結束，在此以前爲消息報頭 user=jeffrey&pwd=1234  //此行如下爲提交的數據 HEAD方法與GET方法幾乎是同樣的，對於HEAD請求的迴應部分來講，它的HTTP頭部中包含的 信息與經過GET請求所獲得的信息是相同的。利用這個方法，沒必要傳輸整個資源內容，就能夠獲得Request-URI所標識的資源的信息。該方法經常使用於測 試超連接的有效性，是否能夠訪問，以及最近是否更新。 二、請求報頭後述 三、請求正文(略)  3、HTTP協議詳解之響應篇     在接收和解釋請求消息後，服務器返回一個HTTP響應消息。 HTTP響應也是由三個部分組成，分別是：狀態行、消息報頭、響應正文 一、狀態行格式以下： HTTP-Version Status-Code Reason-Phrase CRLF 其中，HTTP-Version表示服務器HTTP協議的版本；Status-Code表示服務器發回的響應狀態代碼；Reason-Phrase表示狀態代碼的文本描述。 狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值： 1xx：指示信息--表示請求已接收，繼續處理 2xx：成功--表示請求已被成功接收、理解、接受 3xx：重定向--要完成請求必須進行更進一步的操做 4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現 5xx：服務器端錯誤--服務器未能實現合法的請求 常見狀態代碼、狀態描述、說明： 200 OK      //客戶端請求成功 400 Bad Request  //客戶端請求有語法錯誤，不能被服務器所理解 401 Unauthorized //請求未經受權，這個狀態代碼必須和WWW-Authenticate報                 //頭域一塊兒使用  403 Forbidden  //服務器收到請求，可是拒絕提供服務 404 Not Found  //請求資源不存在，eg：輸入了錯誤的URL 500 Internal Server Error //服務器發生不可預期的錯誤 503 Server Unavailable  //服務器當前不能處理客戶端的請求，一段時間後，                         //可能恢復正常 eg：HTTP/1.1 200 OK （CRLF） 二、響應報頭後述 三、響應正文就是服務器返回的資源的內容  4、HTTP協議詳解之消息報頭篇     HTTP消息由客戶端到服務器的請求和服務器到客戶端的響應組成。請求消息和響應消息都是由開始行（對於請求消息，開始行就是請求行，對於響應消息，開始行就是狀態行），消息報頭（可選），空行（只有CRLF的行），消息正文（可選）組成。 HTTP消息報頭包括普通報頭、請求報頭、響應報頭、實體報頭。 每個報頭域都是由名字+「：」+空格+值 組成，消息報頭域的名字是大小寫無關的。 一、普通報頭 在普通報頭中，有少數報頭域用於全部的請求和響應消息，但並不用於被傳輸的實體，只用於傳輸的消息。 eg： Cache-Control   用於指定緩存指令，緩存指令是單向的（響應中出現的緩存指令在請求中未必會出現），且是獨立的（一個消息的緩存指令不會影響另外一個消息處理的緩存機制），HTTP1.0使用的相似的報頭域爲Pragma。 請求時的緩存指令包括：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、s-maxage. eg：爲了指示IE瀏覽器（客戶端）不要緩存頁面，服務器端的JSP程序能夠編寫以下：response.sehHeader("Cache-Control","no-cache"); //response.setHeader("Pragma","no-cache");做用至關於上述代碼，一般二者//合用 這句代碼將在發送的響應消息中設置普通報頭域：Cache-Control:no-cache Date普通報頭域表示消息產生的日期和時間 Connection普通報頭域容許發送指定鏈接的選項。例如指定鏈接是連續，或者指定「close」選項，通知服務器，在響應完成後，關閉鏈接 二、請求報頭 請求報頭容許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息。 海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo 經常使用的請求報頭 Accept Accept請求報頭域用於指定客戶端接受哪些類型的信息。eg：Accept：image/gif，代表客戶端但願接受GIF圖象格式的資源；Accept：text/html，代表客戶端但願接受html文本。 Accept-Charset Accept-Charset請求報頭域用於指定客戶端接受的字符集。eg：Accept-Charset:iso-8859-1,gb2312.若是在請求消息中沒有設置這個域，缺省是任何字符集均可以接受。 Accept-Encoding Accept-Encoding請求報頭域相似於Accept，可是它是用於指定可接受的內容編碼。eg：Accept-Encoding:gzip.deflate.若是請求消息中沒有設置這個域服務器假定客戶端對各類內容編碼均可以接受。 Accept-Language Accept-Language請求報頭域相似於Accept，可是它是用於指定一種天然語言。eg：Accept-Language:zh-cn.若是請求消息中沒有設置這個報頭域，服務器假定客戶端對各類語言均可以接受。 Authorization Authorization請求報頭域主要用於證實客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，若是收到服務器的響應代碼爲401（未受權），能夠發送一個包含Authorization請求報頭域的請求，要求服務器對其進行驗證。 Host（發送請求時，該報頭域是必需的） Host請求報頭域主要用於指定被請求資源的Internet主機和端口號，它一般從HTTP URL中提取出來的，eg： 咱們在瀏覽器中輸入：http://www.guet.edu.cn/index.html 瀏覽器發送的請求消息中，就會包含Host請求報頭域，以下： Host：www.guet.edu.cn 此處使用缺省端口號80，若指定了端口號，則變成：Host：www.guet.edu.cn:指定端口號 User-Agent 我 們上網登錄論壇的時候，每每會看到一些歡迎信息，其中列出了你的操做系統的名稱和版本，你所使用的瀏覽器的名稱和版本，這每每讓不少人感到很神奇，實際 上，服務器應用程序就是從User-Agent這個請求報頭域中獲取到這些信息。User-Agent請求報頭域容許客戶端將它的操做系統、瀏覽器和其它 屬性告訴服務器。不過，這個報頭域不是必需的，若是咱們本身編寫一個瀏覽器，不使用User-Agent請求報頭域，那麼服務器端就沒法得知咱們的信息 了。 請求報頭舉例： GET /form.html HTTP/1.1 (CRLF) Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF) Accept-Language:zh-cn (CRLF) Accept-Encoding:gzip,deflate (CRLF) If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF) If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF) User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF) Host:www.guet.edu.cn (CRLF) Connection:Keep-Alive (CRLF) (CRLF) 三、響應報頭 響應報頭容許服務器傳遞不能放在狀態行中的附加響應信息，以及關於服務器的信息和對Request-URI所標識的資源進行下一步訪問的信息。 經常使用的響應報頭 Location Location響應報頭域用於重定向接受者到一個新的位置。Location響應報頭域經常使用在更換域名的時候。 Server Server響應報頭域包含了服務器用來處理請求的軟件信息。與User-Agent請求報頭域是相對應的。下面是 Server響應報頭域的一個例子： Server：Apache-Coyote/1.1 WWW-Authenticate WWW-Authenticate響應報頭域必須被包含在401（未受權的）響應消息中，客戶端收到401響應消息時候，併發送Authorization報頭域請求服務器對其進行驗證時，服務端響應報頭就包含該報頭域。 eg：WWW-Authenticate:Basic realm="Basic Auth Test!"  //能夠看出服務器對請求資源採用的是基本驗證機制。 四、實體報頭 請求和響應消息均可以傳送一個實體。一個實體由實體報頭域和實體正文組成，但並非說實體報頭域和實體正文要在一塊兒發送，能夠只發送實體報頭域。實體報頭定義了關於實體正文（eg：有無實體正文）和請求所標識的資源的元信息。 經常使用的實體報頭 Content-Encoding Content- Encoding實體報頭域被用做媒體類型的修飾符，它的值指示了已經被應用到實體正文的附加內容的編碼，於是要得到Content-Type報頭域中所 引用的媒體類型，必須採用相應的解碼機制。Content-Encoding這樣用於記錄文檔的壓縮方法，eg：Content- Encoding：gzip Content-Language Content-Language實體報頭域描述了資源所用的天然語言。沒有設置該域則認爲實體內容將提供給全部的語言閱讀 者。eg：Content-Language:da Content-Length Content-Length實體報頭域用於指明實體正文的長度，以字節方式存儲的十進制數字來表示。 Content-Type Content-Type實體報頭域用語指明發送給接收者的實體正文的媒體類型。eg： Content-Type:text/html;charset=ISO-8859-1 Content-Type:text/html;charset=GB2312 Last-Modified Last-Modified實體報頭域用於指示資源的最後修改日期和時間。 Expires Expires 實體報頭域給出響應過時的日期和時間。爲了讓代理服務器或瀏覽器在一段時間之後更新緩存中(再次訪問曾訪問過的頁面時，直接從緩存中加載，縮短響應時間和 下降服務器負載)的頁面，咱們能夠使用Expires實體報頭域指定頁面過時的時間。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT HTTP1.1的客戶端和緩存必須將其餘非法的日期格式（包括0）看做已通過期。eg：爲了讓瀏覽器不要緩存頁面，咱們也能夠利用Expires實體報頭域，設置爲0，jsp中程序以下：response.setDateHeader("Expires","0"); 5、利用telnet觀察http協議的通信過程     實驗目的及原理：     利用MS的telnet工具，經過手動輸入http請求信息的方式，向服務器發出請求，服務器接收、解釋和接受請求後，會返回一個響應，該響應會在telnet窗口上顯示出來，從而從感性上加深對http協議的通信過程的認識。 海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo     實驗步驟： 一、打開telnet 1.1 打開telnet 運行-->cmd-->telnet 1.2 打開telnet回顯功能 set localecho 二、鏈接服務器併發送請求 2.1 open www.guet.edu.cn 80  //注意端口號不能省略     HEAD /index.asp HTTP/1.0     Host:www.guet.edu.cn         /*咱們能夠變換請求方法,請求桂林電子主頁內容,輸入消息以下*/     open www.guet.edu.cn 80          GET /index.asp HTTP/1.0  //請求資源的內容     Host:www.guet.edu.cn   2.2 open www.sina.com.cn 80  //在命令提示符號下直接輸入telnet www.sina.com.cn 80     HEAD /index.asp HTTP/1.0     Host:www.sina.com.cn 3 實驗結果： 3.1 請求信息2.1獲得的響應是: HTTP/1.1 200 OK                                              //請求成功 Server: Microsoft-IIS/5.0                                    //web服務器 Date: Thu,08 Mar 200707:17:51 GMT Connection: Keep-Alive                                  Content-Length: 23330 Content-Type: text/html Expries: Thu,08 Mar 2007 07:16:51 GMT Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/ Cache-control: private //資源內容省略 3.2 請求信息2.2獲得的響應是: HTTP/1.0 404 Not Found       //請求失敗 Date: Thu, 08 Mar 2007 07:50:50 GMT Server: Apache/2.0.54 <Unix> Last-Modified: Thu, 30 Nov 2006 11:35:41 GMT ETag: "6277a-415-e7c76980" Accept-Ranges: bytes X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remix Vary: Accept-Encoding Content-Type: text/html X-Cache: MISS from zjm152-78.sina.com.cn Via: 1.0 zjm152-78.sina.com.cn:80<squid/2.6.STABLES-20061207> X-Cache: MISS from th-143.sina.com.cn Connection: close 失去了跟主機的鏈接 按任意鍵繼續... 4 .注意事項：一、出現輸入錯誤，則請求不會成功。           二、報頭域不分大小寫。           三、更深一步瞭解HTTP協議，能夠查看RFC2616，在http://www.letf.org/rfc上找到該文件。           四、開發後臺程序必須掌握http協議 6、HTTP協議相關技術補充     一、基礎：     高層協議有：文件傳輸協議FTP、電子郵件傳輸協議SMTP、域名系統服務DNS、網絡新聞傳輸協議NNTP和HTTP協議等 中 介由三種：代理(Proxy)、網關(Gateway)和通道(Tunnel)，一個代理根據URI的絕對格式來接受請求，重寫所有或部分消息，經過 URI的標識把已格式化過的請求發送到服務器。網關是一個接收代理，做爲一些其它服務器的上層，而且若是必須的話，能夠把請求翻譯給下層的服務器協議。一 個通道做爲不改變消息的兩個鏈接之間的中繼點。當通信須要經過一箇中介(例如：防火牆等)或者是中介不能識別消息的內容時，通道常常被使用。      代理(Proxy)：一箇中間程序，它能夠充當一個服務器，也能夠充當一個客戶機，爲其它客戶機創建請求。請求是經過可能的翻譯在內部或通過傳遞到其它的 服務器中。一個代理在發送請求信息以前，必須解釋而且若是可能重寫它。代理常常做爲經過防火牆的客戶機端的門戶，代理還能夠做爲一個幫助應用來經過協議處 理沒有被用戶代理完成的請求。 網關(Gateway)：一個做爲其它服務器中間媒介的服務器。與代理不一樣的是，網關接受請求就好象對被請求的資源來講它就是源服務器；發出請求的客戶機並無意識到它在同網關打交道。 網關常常做爲經過防火牆的服務器端的門戶，網關還能夠做爲一個協議翻譯器以便存取那些存儲在非HTTP系統中的資源。     通道(Tunnel)：是做爲兩個鏈接中繼的中介程序。一旦激活，通道便被認爲不屬於HTTP通信，儘管通道多是被一個HTTP請求初始化的。當被中繼 的鏈接兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通信時通道被常用。 二、協議分析的優點—HTTP分析器檢測網絡攻擊 以模塊化的方式對高層協議進行分析處理，將是將來入侵檢測的方向。 HTTP及其代理的經常使用端口80、3128和8080在network部分用port標籤進行了規定 三、HTTP協議Content Lenth限制漏洞致使拒絕服務攻擊 使 用POST方法時，能夠設置ContentLenth來定義須要傳送的數據長度，例如ContentLenth:999999999，在傳送完成前，內 存不會釋放，攻擊者能夠利用這個缺陷，連續向WEB服務器發送垃圾數據直至WEB服務器內存耗盡。這種攻擊方法基本不會留下痕跡。 http://www.cnpaf.net/Class/HTTP/0532918532667330.html 四、利用HTTP協議的特性進行拒絕服務攻擊的一些構思 服務器端忙於處理攻擊者僞造的TCP鏈接請求而無暇理睬客戶的正常請求（畢竟客戶端的正常請求比率很是之小），此時從正常客戶的角度看來，服務器失去響應，這種狀況咱們稱做：服務器端受到了SYNFlood攻擊（SYN洪水攻擊）。 而Smurf、TearDrop等是利用ICMP報文來Flood和IP碎片攻擊的。本文用「正常鏈接」的方法來產生拒絕服務攻擊。 19 端口在早期已經有人用來作Chargen攻擊了，即Chargen_Denial_of_Service，可是！他們用的方法是在兩臺Chargen 服務器之間產生UDP鏈接，讓服務器處理過多信息而DOWN掉，那麼，幹掉一臺WEB服務器的條件就必須有2個：1.有Chargen服務2.有HTTP 服務 海奼網（網址:http://www.seacha.com），標籤：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo 方法：攻擊者僞造源IP給N臺Chargen發送鏈接請求（Connect），Chargen接收到鏈接後就會返回每秒72字節的字符流（實際上根據網絡實際狀況，這個速度更快）給服務器。 五、Http指紋識別技術    Http指紋識別的原理大體上也是相同的：記錄不一樣服務器對Http協議執行中的微小差異進行識別.Http指紋識別比TCP/IP堆棧指紋識別複雜許 多,理由是定製Http服務器的配置文件、增長插件或組件使得更改Http的響應信息變的很容易,這樣使得識別變的困難；然而定製TCP/IP堆棧的行爲 須要對核心層進行修改,因此就容易識別.       要讓服務器返回不一樣的Banner信息的設置是很簡單的,象Apache這樣的開放源代碼的Http服務器,用戶能夠在源代碼裏修改Banner信息,然 後重起Http服務就生效了；對於沒有公開源代碼的Http服務器好比微軟的IIS或者是Netscape,能夠在存放Banner信息的Dll文件中修 改,相關的文章有討論的,這裏再也不贅述,固然這樣的修改的效果仍是不錯的.另一種模糊Banner信息的方法是使用插件。 經常使用測試請求： 1：HEAD/Http/1.0發送基本的Http請求 2：DELETE/Http/1.0發送那些不被容許的請求,好比Delete請求 3：GET/Http/3.0發送一個非法版本的Http協議請求 4：GET/JUNK/1.0發送一個不正確規格的Http協議請求 Http指紋識別工具Httprint,它經過運用統計學原理,組合模糊的邏輯學技術,能頗有效的肯定Http服務器的類型.它能夠被用來收集和分析不一樣Http服務器產生的簽名。 六、其餘：爲了提升用戶使用瀏覽器時的性能，現代瀏覽器還支持併發的訪問方式，瀏覽一個網頁時同時創建多個鏈接，以迅速得到一個網頁上的多個圖標，這樣能更快速完成整個網頁的傳輸。 HTTP1.1中提供了這種持續鏈接的方式，而下一代HTTP協議：HTTP-NG更增長了有關會話控制、豐富的內容協商等方式的支持，來提供 更高效率的鏈接。 RFC 6585 最近剛剛發佈，該文檔描述了 4 個新的 HTTP 狀態碼。 HTTP 協議還在變化？是的，HTTP 協議一直在演變，新的狀態碼對於開發 REST 服務或者說是基於 HTTP 的服務很是有用，下面咱們爲你詳細介紹這四個新的狀態碼以及是否應該使用。 428 Precondition Required (要求先決條件) 先決條件是客戶端發送 HTTP 請求時，若是想要請求能成功必須知足一些預設的條件。 一個好的例子就是 If-None-Match 頭，常常在 GET 請求中使用，若是指定了 If-None-Match ，那麼客戶端只在響應中的 ETag 改變後纔會從新接收回應。 先決條件的另一個例子就是 If-Match 頭，這個通常用在 PUT 請求上用於指示只更新沒被改變的資源，這在多個客戶端使用 HTTP 服務時用來防止彼此間不會覆蓋相同內容。 當服務器端使用 428 Precondition Required 狀態碼時，表示客戶端必須發送上述的請求頭才能執行請求，這個方法爲服務器提供一種有效的方法來阻止 'lost update' 問題。 429 Too Many Requests (太多請求) 當你須要限制客戶端請求某個服務數量時，該狀態碼就頗有用，也就是請求速度限制。 在此以前，有一些相似的狀態碼，例如 '509 Bandwidth Limit Exceeded'. Twitter 使用 420 （這不是HTTP定義的狀態碼） 若是你但願限制客戶端對服務的請求數，可以使用 429 狀態碼，同時包含一個 Retry-After 響應頭用於告訴客戶端多長時間後能夠再次請求服務。 431 Request Header Fields Too Large (請求頭字段太大) 某些狀況下，客戶端發送 HTTP 請求頭會變得很大，那麼服務器可發送 431 Request Header Fields Too Large 來指明該問題。 我不太清楚爲何沒有 430 狀態碼，而是直接從 429 跳到 431，我嘗試搜索但沒有結果。惟一的猜想是 430 Forbidden 跟 403 Forbidden 太像了，爲了不混淆才這麼作的，天知道！ 511 Network Authentication Required (要求網絡認證) 對我來講這個狀態碼頗有趣，若是你在開發一個 HTTP 服務器，你不必定須要處理該狀態碼，但若是你在編寫 HTTP 客戶端，那這個狀態碼就很是重要。 若是你頻繁使用筆記本和智能手機，你可能會注意到大量的公用 WIFI 服務要求你必須接受一些協議或者必須登陸後才能使用。 這是經過攔截HTTP流量，當用戶試圖訪問網絡返回一個重定向和登陸，這很討厭，可是實際狀況就是這樣的。 使用這些「攔截」客戶端，會有一些討厭的反作用。在 RFC 中有提到這兩個的例子： 若是你在登陸WIFI前訪問某個網站，網絡設備將會攔截首個請求，這些設備每每也有本身的網站圖標 ‘favicon.ico'。登陸後您會發現，有一段時間內你訪問的網站圖標一直是WIFI登陸網站的圖標。 若是客戶端使用HTTP請求來查找文檔（多是JSON），網絡將會響應一個登陸頁，這樣你的客戶端就會解析錯誤並致使客戶端運行異常，在現實中這種問題很是常見。 所以 511 狀態碼的提出就是爲了解決這個問題。 若是你正在編寫 HTTP 的客戶端，你最好仍是檢查 511 狀態碼以確認是否須要認證後才能訪問。 (責任編輯：admin)

•     您可能對如下的相關文章感興趣：
•     VC++ HTTP協議之POST方法
•     C語言實現 HTTP 中的chunked解碼函數
•     TCP協議狀態詳解
•     HTTP狀態碼完整介紹
•     HTTP協議詳解
•     http協議狀態碼解釋詳細說明
•     合做協議書範本(二)
•     Red Hat Linux 9.0架設FTP服務器