HTTP協定詳解

引言

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表示要通過HTTP協定來定位網絡資源；host表示合法的Internet主機域名或者IP位址；port指定一個端口号，為空則使用預設端口80；abs_path指定請求資源的URI；如果URL中沒有給出abs_path，那麼當它作為請求URI時，必須以“/”的形式給出，通常這個工作浏覽器自動幫我們完成。

eg:

2、http:192.168.0.116:8080/index.jsp

二、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、請求報頭

請求報頭允許用戶端向伺服器端傳遞請求的附加資訊以及用戶端自身的資訊。

常用的請求報頭

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：

浏覽器發送的請求消息中，就會包含Host請求報頭域，如下：

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)

(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協定的通訊過程的認識。

   實驗步驟：

1、打開telnet

1.1 打開telnet

運作-->cmd-->telnet

1.2 打開telnet回顯功能

set localecho

2、連接配接伺服器并發送請求

   HEAD /index.asp HTTP/1.0

   Host:www.guet.edu.cn

  /*我們可以變換請求方法,請求桂林電子首頁内容,輸入消息如下*/

   GET /index.asp HTTP/1.0  //請求資源的内容

   Host:www.guet.edu.cn  

   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

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、報頭域不分大小寫。

         4、開發背景程式必須掌握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 服務

方法：攻擊者僞造源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更增加了有關會話控制、豐富的内容協商等方式的支援，來提供

更高效率的連接配接。

附錄:HTTP協定狀态碼的含義  

　　狀态代碼 狀态資訊 含義    

100 Continue 初始的請求已經接受，客戶應當繼續發送請求的其餘部分。（HTTP 1.1新）  

101 Switching Protocols 伺服器将遵從客戶的請求轉換到另外一種協定（HTTP 1.1新  

200 OK 一切正常，對GET和POST請求的應答文檔跟在後面。  

201 Created 伺服器已經建立了文檔，Location頭給出了它的URL。  

202 Accepted 已經接受請求，但處理尚未完成。    

203 Non-Authoritative Information 文檔已經正常地傳回，但一些應答頭可能不正确，因為使用的是文檔的拷貝（HTTP 1.1新）。    

204 No Content 沒有新文檔，浏覽器應該繼續顯示原來的文檔。  

205 Reset Content 沒有新的内容，但浏覽器應該重置它所顯示的内容。用來強制浏覽器清除表單輸入内容（HTTP 1.1新）。    

206 Partial Content 客戶發送了一個帶有Range頭的GET請求，伺服器完成了它（HTTP 1.1新）。    

300 Multiple Choices 客戶請求的文檔可以在多個位置找到，這些位置已經在傳回的文檔内列出。如果伺服器要提出優先選擇，則應該在Location應答頭指明。    

301 Moved Permanently 客戶請求的文檔在其他地方，新的URL在Location頭中給出，浏覽器應該自動地通路新的URL。    

302 Found 類似于301，但新的URL應該被視為臨時性的替代，而不是永久性的。注意，在HTTP1.0中對應的狀态資訊是“Moved Temporatily”，出現該狀态代碼時，浏覽器能夠自動通路新的URL，是以它是一個很有用的狀态代碼。注意這個狀态代碼有時候可以和301替換使用。例如，如果浏覽器錯誤地請求http://host/~user（缺少了後面的斜杠），有的伺服器傳回301，有的則傳回302。嚴格地說，我們隻能假定隻有當原來的請求是GET時浏覽器才會自動重定向。請參見307。  

303 See Other 類似于301/302，不同之處在于，如果原來的請求是POST，Location頭指定的重定向目标文檔應該通過GET提取（HTTP 1.1新）。    

304 Not Modified 用戶端有緩沖的文檔并發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶隻想比指定日期更新的文檔）。伺服器告訴客戶，原來緩沖的文檔還可以繼續使用。  

305 Use Proxy 客戶請求的文檔應該通過Location頭所指明的代理伺服器提取（HTTP 1.1新）。  

307 Temporary Redirect 和302（Found）相同。許多浏覽器會錯誤地響應302應答進行重定向，即使原來的請求是POST，即使它實際上隻能在POST請求的應答是303時才能重定向。由于這個原因，HTTP 1.1新增了307，以便更加清除地區分幾個狀态代碼：當出現303應答時，浏覽器可以跟随重定向的GET和POST請求；如果是307應答，則浏覽器隻能跟随對GET請求的重定向。（HTTP 1.1新）    

400 Bad Request 請求出現文法錯誤。    

401 Unauthorized 客戶試圖未經授權通路受密碼保護的頁面。應答中會包含一個WWW-Authenticate頭，浏覽器據此顯示使用者名字/密碼對話框，然後在填寫合适的Authorization頭後再次送出請求。    

403 Forbidden 資源不可用。伺服器了解客戶的請求，但拒絕處理它。通常由于伺服器上檔案或目錄的權限設定導緻。    

404 Not Found 無法找到指定位置的資源。這也是一個常用的應答，    

405 Method Not Allowed 請求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）對指定的資源不适用。（HTTP 1.1新）    

406 Not Acceptable 指定的資源已經找到，但它的MIME類型和客戶在Accpet頭中所指定的不相容（HTTP 1.1新）。    

407 Proxy Authentication Required 類似于401，表示客戶必須先經過代理伺服器的授權。（HTTP 1.1新）  

408 Request Timeout 在伺服器許可的等待時間内，客戶一直沒有發出任何請求。客戶可以在以後重複同一請求。（HTTP 1.1新）    

409 Conflict 通常和PUT請求有關。由于請求和資源的目前狀态相沖突，是以請求不能成功。（HTTP 1.1新）  

410 Gone 所請求的文檔已經不再可用，而且伺服器不知道應該重定向到哪一個位址。它和404的不同在于，傳回407表示文檔永久地離開了指定的位置，而404表示由于未知的原因文檔不可用。（HTTP 1.1新）  

411 Length Required 伺服器不能處理請求，除非客戶發送一個Content-Length頭。（HTTP 1.1新）  

412 Precondition Failed 請求頭中指定的一些前提條件失敗（HTTP 1.1新）。    

413 Request Entity Too Large 目标文檔的大小超過伺服器目前願意處理的大小。如果伺服器認為自己能夠稍後再處理該請求，則應該提供一個Retry-After頭（HTTP 1.1新）。    

414 Request URI Too Long URI太長（HTTP 1.1新）。    

416 Requested Range Not Satisfiable 伺服器不能滿足客戶在請求中指定的Range頭。（HTTP 1.1新）    

500 Internal Server Error 伺服器遇到了意料不到的情況，不能完成客戶的請求。    

501 Not Implemented 伺服器不支援實作請求所需要的功能。例如，客戶發出了一個伺服器不支援的PUT請求。  

502 Bad Gateway 伺服器作為網關或者代理時，為了完成請求通路下一個伺服器，但該伺服器傳回了非法的應答。    

503 Service Unavailable 伺服器由于維護或者負載過重未能應答。  

504 Gateway Timeout 由作為代理或網關的伺服器使用，表示不能及時地從遠端伺服器獲得應答。（HTTP 1.1新）    

505 HTTP Version Not Supported 伺服器不支援請求中所指明的HTTP版本  

本文轉自 deng304749970 51CTO部落格，原文連結：http://blog.51cto.com/damondeng/1254682，如需轉載請自行聯系原作者