2019獨角獸企業重金招聘Python工程師標準>>>

?

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 2518、RFC 2817、RFC 2295、RFC 2774、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協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。 一、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: 1、輸入：www.guet.edu.cn 瀏覽器自動轉換成：http://www.guet.edu.cn/ 2、http:192.168.0.116:8080/index.jsp? 海姹網（網址:http://www.seacha.com），標簽：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo 二、HTTP協議詳解之請求篇 ? ? http請求由三部分組成，分別是：請求行、消息報頭、請求正文 1、請求行以一個方法符號開頭，以空格分開，后面跟著請求的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所標識的資源的信息。該方法常用于測 試超鏈接的有效性，是否可以訪問，以及最近是否更新。 2、請求報頭后述 3、請求正文(略)? 三、HTTP協議詳解之響應篇 ? ? 在接收和解釋請求消息后，服務器返回一個HTTP響應消息。 HTTP響應也是由三個部分組成，分別是：狀態行、消息報頭、響應正文 1、狀態行格式如下： 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） 2、響應報頭后述 3、響應正文就是服務器返回的資源的內容? 四、HTTP協議詳解之消息報頭篇 ? ? HTTP消息由客戶端到服務器的請求和服務器到客戶端的響應組成。請求消息和響應消息都是由開始行（對于請求消息，開始行就是請求行，對于響應消息，開始行就是狀態行），消息報頭（可選），空行（只有CRLF的行），消息正文（可選）組成。 HTTP消息報頭包括普通報頭、請求報頭、響應報頭、實體報頭。 每一個報頭域都是由名字+“：”+空格+值 組成，消息報頭域的名字是大小寫無關的。 1、普通報頭 在普通報頭中，有少數報頭域用于所有的請求和響應消息，但并不用于被傳輸的實體，只用于傳輸的消息。 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”選項，通知服務器，在響應完成后，關閉連接 2、請求報頭 請求報頭允許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息。 海姹網（網址: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) 3、響應報頭 響應報頭允許服務器傳遞不能放在狀態行中的附加響應信息，以及關于服務器的信息和對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!" ?//可以看出服務器對請求資源采用的是基本驗證機制。 4、實體報頭 請求和響應消息都可以傳送一個實體。一個實體由實體報頭域和實體正文組成，但并不是說實體報頭域和實體正文要在一起發送，可以只發送實體報頭域。實體報頭定義了關于實體正文（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"); 五、利用telnet觀察http協議的通訊過程 ? ? 實驗目的及原理： ? ? 利用MS的telnet工具，通過手動輸入http請求信息的方式，向服務器發出請求，服務器接收、解釋和接受請求后，會返回一個響應，該響應會在telnet窗口上顯示出來，從而從感性上加深對http協議的通訊過程的認識。 海姹網（網址:http://www.seacha.com），標簽：HTTP狀態碼完整介紹， HTTP,協議,狀態碼,seo ? ? 實驗步驟： 1、打開telnet 1.1 打開telnet 運行-->cmd-->telnet 1.2 打開telnet回顯功能 set localecho 2、連接服務器并發送請求 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 .注意事項：1、出現輸入錯誤，則請求不會成功。 ? ? ? ? ? 2、報頭域不分大小寫。 ? ? ? ? ? 3、更深一步了解HTTP協議，可以查看RFC2616，在http://www.letf.org/rfc上找到該文件。 ? ? ? ? ? 4、開發后臺程序必須掌握http協議 六、HTTP協議相關技術補充 ? ? 1、基礎： ? ? 高層協議有：文件傳輸協議FTP、電子郵件傳輸協議SMTP、域名系統服務DNS、網絡新聞傳輸協議NNTP和HTTP協議等 中 介由三種：代理(Proxy)、網關(Gateway)和通道(Tunnel)，一個代理根據URI的絕對格式來接受請求，重寫全部或部分消息，通過 URI的標識把已格式化過的請求發送到服務器。網關是一個接收代理，作為一些其它服務器的上層，并且如果必須的話，可以把請求翻譯給下層的服務器協議。一 個通道作為不改變消息的兩個連接之間的中繼點。當通訊需要通過一個中介(例如：防火墻等)或者是中介不能識別消息的內容時，通道經常被使用。 ? ? ?代理(Proxy)：一個中間程序，它可以充當一個服務器，也可以充當一個客戶機，為其它客戶機建立請求。請求是通過可能的翻譯在內部或經過傳遞到其它的 服務器中。一個代理在發送請求信息之前，必須解釋并且如果可能重寫它。代理經常作為通過防火墻的客戶機端的門戶，代理還可以作為一個幫助應用來通過協議處 理沒有被用戶代理完成的請求。 網關(Gateway)：一個作為其它服務器中間媒介的服務器。與代理不同的是，網關接受請求就好象對被請求的資源來說它就是源服務器；發出請求的客戶機并沒有意識到它在同網關打交道。 網關經常作為通過防火墻的服務器端的門戶，網關還可以作為一個協議翻譯器以便存取那些存儲在非HTTP系統中的資源。 ? ? 通道(Tunnel)：是作為兩個連接中繼的中介程序。一旦激活，通道便被認為不屬于HTTP通訊，盡管通道可能是被一個HTTP請求初始化的。當被中繼 的連接兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經常使用。 2、協議分析的優勢—HTTP分析器檢測網絡攻擊 以模塊化的方式對高層協議進行分析處理，將是未來入侵檢測的方向。 HTTP及其代理的常用端口80、3128和8080在network部分用port標簽進行了規定 3、HTTP協議Content Lenth限制漏洞導致拒絕服務攻擊 使 用POST方法時，可以設置ContentLenth來定義需要傳送的數據長度，例如ContentLenth:999999999，在傳送完成前，內 存不會釋放，攻擊者可以利用這個缺陷，連續向WEB服務器發送垃圾數據直至WEB服務器內存耗盡。這種攻擊方法基本不會留下痕跡。 http://www.cnpaf.net/Class/HTTP/0532918532667330.html 4、利用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字節的字符流（實際上根據網絡實際情況，這個速度更快）給服務器。 5、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服務器產生的簽名。 6、其他：為了提高用戶使用瀏覽器時的性能，現代瀏覽器還支持并發的訪問方式，瀏覽一個網頁時同時建立多個連接，以迅速獲得一個網頁上的多個圖標，這樣能更快速完成整個網頁的傳輸。 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服務器

轉載于:https://my.oschina.net/u/2001537/blog/348459

總結

以上是生活随笔為你收集整理的HTTP状态码完整介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。