http 超文本傳輸協議

超文本傳輸協議（HTTP，HyperText Transfer Protocol)是 互聯網上應用最為廣泛的一種 網絡協議。所有的 WWW文件都必須遵守這個標准。設計HTTP最初的目的是為了提供一種發布和接收 HTML頁面的方法。1960年美國人 Ted Nelson構思了一種通過 計算機處理文本信息的方法，並稱之為超文本（hypertext）,這成為了HTTP超文本傳輸協議標准架構的發展根基。Ted Nelson組織協調萬維網協會（World Wide Web Consortium）和 互聯網工程工作小組（Internet Engineering Task Force ）共同合作研究，最終發布了一系列的 RFC，其中著名的RFC 2616定義了HTTP 1.1。

目錄

1. 1 技術架構
2. 2 協議功能
3. 3 協議基礎
4. ▪ 通用頭域

1. ▪ 請求消息
2. ▪ 響應消息
3. ▪ 實體信息
4. 4 運作方式
5. 5 報文格式

1. 6 工作原理
2. 7 狀態消息
3. 8 版本歷史

技術架構

HTTP是一個 客戶端和 服務器端請求和應答的標准（TCP）。客戶端是終端用戶，服務器端是網站。通過使用 Web瀏覽器、 網絡爬蟲或者其它的工具，客戶端發起一個到服務器上指定端口（默認 端口為80）的HTTP請求。（我們稱這個客戶端）叫用戶代理（user agent）。應答的服務器上存儲着（一些）資源，比如HTML文件和圖像。（我們稱）這個應答服務器為源服務器（origin server）。在用戶代理和源服務器中間可能存在

http和其他幾種網絡協議

多個中間層，比如代理，網關，或者隧道（tunnels）。盡管 TCP/IP協議是互聯網上最流行的應用，HTTP協議並沒有規定必須使用它和（基於）它支持的層。 事實上，HTTP可以在任何其他互聯網協議上，或者在其他網絡上實現。HTTP只假定（其下層協議提供）可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。

通常，由HTTP客戶端發起一個請求，建立一個到服務器指定端口（默認是 80端口）的TCP連接。HTTP服務器則在那個端口監聽客戶端發送過來的請求。一旦收到請求，服務器（向客戶端）發回一個狀態行，比如"HTTP/1.1 200 OK"，和（響應的）消息，消息的消息體可能是請求的文件、錯誤消息、或者其它一些信息。

HTTP協議的網頁

HTTP使用TCP而不是UDP的原因在於（打開）一個網頁必須傳送很多數據，而TCP協議提供傳輸控制，按順序組織數據，和錯誤糾正。

通過HTTP或者HTTPS協議請求的資源由統一資源標示符（Uniform Resource Identifiers）（或者，更准確一些，URLs）來標識。

協議功能

HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先於圖形)等。

HTTP是客戶端瀏覽器或其他程序與 Web服務器之間的應用層通信協議。在Internet上的Web服務器上存放的都是超文本信息，客戶機需要通過HTTP協議傳輸所要訪問的超文本信息。HTTP包含命令和傳輸信息，不僅可用於Web訪問，也可以用於其他因特網/內聯網應用系統之間的通信，從而實現各類應用資源超媒體訪問的集成。

我們在瀏覽器的地址欄里輸入的網站地址叫做URL (Uniform Resource Locator， 統一資源定位符)。就像每家每戶都有一個門牌地址一樣，每個網頁也都有一個Internet地址。當你在

http功用

瀏覽器的地址框中輸入一個URL或是單擊一個超級鏈接時，URL就確定了要瀏覽的地址。瀏覽器通過超文本傳輸協議(HTTP)，將Web服務器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁。

協議基礎

HTTP（HyperText Transport Protocol）是超文本傳輸協議的縮寫，它用於傳送WWW方式的數據，關於HTTP協議的詳細內容請參考RFC2616。HTTP協議采用了請求/響應模型。客戶端向服務器發送一個請求，請求頭包含請求的方法、URL、協議版本、以及包含請求修飾符、客戶信息和內容的類似於MIME的消息結構。服務器以一個狀態行作為響應，響應的內容包括消息協議的版本，成功或者錯誤編碼加上包含服務器信息、實體元信息以及可能的實體內容。

通常HTTP消息包括客戶機向服務器的請求消息和服務器向客戶機的響應消息。這兩種類型的消息由一個起始行，一個或者多個頭域，一個指示頭域結束的空行和可選的消息體組成。HTTP的頭域包括通用頭，請求頭，響應頭和實體頭四個部分。每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前可以添加任何數量的空格符，頭域可以被擴展為多行，在每行開始處，使用至少一個空格或制表符。

通用頭域

通用頭域包含請求和響應消息都支持的頭域，通用頭域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對通用頭域的擴展要求通訊雙方都支持此擴展，如果存在不支持的通用頭域，一般將會作為實體頭域處理。下面簡單介紹幾個在UPnP消息中使用的通用頭域：

1.Cache-Control頭域

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

Public指示響應可被任何緩存區緩存。

Private指示對於單個用戶的整個或部分響應消息，不能被共享緩存處理。這允許服務器僅僅描述當用戶

http結構

的部分響應消息，此響應消息對於其他用戶的請求無效。

no-cache指示請求或響應消息不能緩存

no-store用於防止重要的信息被無意的發布。在請求消息中發送將使得請求和響應消息都不使用緩存。

max-age指示客戶機可以接收生存期不大於指定時間（以秒為單位）的響應。

min-fresh指示客戶機可以接收響應時間小於當前時間加上指定時間的響應。

max-stale指示客戶機可以接收超出超時期間的響應消息。如果指定max-stale消息的值，那么客戶機可以接收超出超時期指定值之內的響應消息。

HTTP Keep-Alive

Keep-Alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的后繼請求時，Keep-Alive功能避免了建立或者重新建立連接。市場上的大部分Web服務器，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive。對於提供靜態內容的網站來說，這個功能通常很有用。但是，對於負擔較重的網站來說，這里存在另外一個問題：雖然為客戶保留打開的連接有一定的好處，但它同樣影響了性能，因為在處理暫停期間，本來可以釋放的資源仍舊被占用。當Web服務器和應用服務器在同一台機器上運行時，Keep- Alive功能對資源利用的影響尤其突出。

KeepAliveTime 值控制 TCP/IP 嘗試驗證空閑連接是否完好的頻率。如果這段時間內沒有活動，則會發送保持活動信號。如果網絡工作正常，而且接收方是活動的，它就會響應。如果需要對丟失接收方敏感，換句話說，需要更快地發現丟失了接收方，請考慮減小這個值。如果長期不活動的空閑連接出現次數較多，而丟失接收方的情況出現較少，您可能會要提高該值以減少開銷。缺省情況下，如果空閑連接 7200000 毫秒（2 小時）內沒有活動，Windows 就發送保持活動的消息。通常，1800000 毫秒是首選值，從而一半的已關閉連接會在 30 分鍾內被檢測到。 KeepAliveInterval 值定義了如果未從接收方收到保持活動消息的響應，TCP/IP 重復發送保持活動信號的頻率。當連續發送保持活動信號、但未收到響應的次數超出 TcpMaxDataRetransmissions 的值時，會放棄該連接。如果期望較長的響應時間，您可能需要提高該值以減少開銷。如果需要減少花在驗證接收方是否已丟失上的時間，請考慮減小該值或 TcpMaxDataRetransmissions 值。缺省情況下，在未收到響應而重新發送保持活動的消息之前，Windows 會等待 1000 毫秒（1 秒）。 KeepAliveTime 根據你的需要設置就行，比如10分鍾，注意要轉換成MS。 XXX代表這個間隔值得大小。

2.Date頭域

Date頭域表示消息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標准時，換算成本地時間，需要知道用戶所在的時區。

3.Pragma頭域

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

請求消息

請求消息的第一行為下面的格式：

MethodSPRequest-URISPHTTP-VersionCRLFMethod表示對於Request-URI完成的方法，這個字段是大小寫敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。方法GET和HEAD應該被所有的通用 WEB服務器支持，其他所有方法的實現是可選的。GET方法取回由Request-URI標識的信息。HEAD方法也是取回由Request-URI標識的信息，只是可以在響應時，不返回消息體。POST方法可以請求服務器接收包含在請求中的實體信息，可以用於提交 表單，向新聞組、BBS、郵件群組和數據庫發送消息。

SP表示空格。Request-URI遵循URI格式，在此字段為星號（*）時，說明請求並不用於某個特定的資源地址，而是用於服務器本身。HTTP-Version表示支持的HTTP版本，例如為HTTP/1.1。CRLF表示換行回車符。請求頭域允許客戶端向服務器傳遞關於請求或者關於客戶機的附加信

http架構

息。請求頭域可能包含下列字段Accept、Accept-Charset、Accept-Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。對請求頭域的擴展要求通訊雙方都支持，如果存在不支持的請求頭域，一般將會作為實體頭域處理。

典型的請求消息：

Host: download.*******.de

Accept: */*

Pragma: no-cache

Cache-Control: no-cache

User-Agent: Mozilla/4.04[en](Win95;I;Nav)

Range: bytes=554554-

上例第一行表示HTTP客戶端（可能是瀏覽器、下載程序）通過GET方法獲得指定URL下的文件。棕色的部分表示請求頭域的信息，綠色的部分表示通用頭部分。

1.Host頭域

Host頭域指定請求資源的Intenet主機和 端口號，必須表示請求url的原始服務器或網關的位置。HTTP/1.1請求必須包含 主機頭域，否則系統會以400狀態碼返回。

2.Referer頭域

Referer頭域允許客戶端指定請求uri的源資源地址，這可以允許服務器生成回退鏈表，可用來登陸、優化cache等。他也允許廢除的或錯誤的連接由於維護的目的被追蹤。如果請求的uri沒有自己的uri地址，Referer不能被發送。如果指定的是部分uri地址，則此地址應該是一個 相對地址。

3.Range頭域

Range頭域可以請求實體的一個或者多個子范圍。例如，

表示頭500個字節：bytes=0-499

表示第二個500字節：bytes=500-999

表示最后500個字節：bytes=-500

表示500字節以后的范圍：bytes=500-

第一個和最后一個字節：bytes=0-0,-1

同時指定幾個范圍：bytes=500-600,601-999

但是服務器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應會以狀態碼206（PartialContent）返回而不是以200（OK）。

4.User-Agent頭域

User-Agent頭域的內容包含發出請求的用戶信息。

響應消息

響應消息的第一行為下面的格式：

HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF

HTTP-Version表示支持的HTTP版本，例如為HTTP/1.1。Status-Code是一個三個數字的結果代碼。Reason-Phrase給Status-Code提供一個簡單的文本描述。Status-Code主要用於機器自動識別，Reason-Phrase主要用於幫助用戶理解。Status-Code的第一個數字定義響應的類別，后兩個數字沒有分類的作用。第一個數字可能取5個不同的值：

1xx:信息響應類，表示接收到請求並且繼續處理

2xx:處理成功響應類，表示動作被成功接收、理解和接受

3xx: 重定向響應類，為了完成指定的動作，必須接受進一步處理

4xx:客戶端錯誤，客戶請求包含語法錯誤或者是不能正確執行

5xx:服務端錯誤，服務器不能正確執行一個正確的請求

響應頭域允許服務器傳遞不能放在狀態行的附加信息，這些域主要描述服務器的信息和Request-URI進一步的信息。響應頭域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。對響應頭域的擴展要求通訊雙方都支持，如果存在不支持的響應頭域，一般將會作為實體頭域處理。

典型的響應消息：

HTTP/1.0200OK

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:bytes55******/40279980

上例第一行表示HTTP服務端響應一個GET方法。棕色的部分表示響應頭域的信息，綠色的部分表示通用頭部分，紅色的部分表示實體頭域的信息。

1.Location響應頭

Location響應頭用於重定向接收者到一個新URI地址。

2.Server響應頭

Server響應頭包含處理請求的原始服務器的軟件信息。此域能包含多個產品標識和注釋，產品標識一般按照重要性排序。

實體信息

請求消息和響應消息都可以包含實體信息，實體信息一般由實體頭域和實體組成。實體頭域包含關於實體的原信息，實體頭包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。extension-header允許客戶端定義新的實體頭，但是這些域可能無法被接受方識別。實體可以是一個經過編碼的字節流，它的編碼方式由Content-Encoding或Content-Type定義，它的長度由Content-Length或Content-Range定義。

1.Content-Type實體頭

Content-Type實體頭用於向接收方指示實體的介質類型，指定HEAD方法送到接收方的實體介質類型，或GET方法發送的請求介質類型

2.Content-Range實體頭

Content-Range實體頭用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的范圍和整個實體長度。一般格式：

Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth

例如，傳送頭500個字節次字段的形式：Content-Range:bytes0-499/1234如果一個http消息包含此節（例如，對范圍請求的響應或對一系列范圍的重疊請求），Content-Range表示傳送的范圍，Content-Length表示實際傳送的字節數。

3.Last-modified實體頭

Last-modified實體頭指定服務器上保存內容的最后修訂時間。

例如，傳送頭500個字節次字段的形式：Content-Range:bytes0-499/1234如果一個http消息包含此節（例如，對范圍請求的響應或對一系列范圍的重疊請求），Content-Range表示傳送的范圍，Content-Length表示實際傳送的字節數。

運作方式

在WWW中，“客戶”與“服務器”是一個相對的概念，只存在於一個特定的連接期間，即在某個連接中的客戶在另一個連接中可能作為服務器。基於HTTP協議的客戶/服務器模式的信息交換過程，它分四個過程：建立連接、發送請求信息、發送響應信息、關閉連接。

HTTP協議是基於請求/響應 范式的。一個客戶機與 服務器建立連接后，發送一個請求給服務器，請求方式的格式為，統一資源標識符、協議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。服務器接到請求后，給予相應的響應信息，其格式為一個狀態行包括信息的協議版本號、一個成功或錯誤的代碼，后邊是 MIME信息包括服務器信息、實體信息和可能的內容。

http運作方式的一種

其實簡單說就是任何服務器除了包括HTML文件以外，還有一個HTTP駐留程序，用於響應用戶請求。你的瀏覽器是HTTP客戶，向服務器發送請求，當瀏覽器中輸入了一個開始文件或點擊了一個超級鏈接時，瀏覽器就向服務器發送了HTTP請求，此請求被送往由 IP地址指定的URL。駐留程序接收到請求，在進行必要的操作后回送所要求的文件。在這一過程中，在網絡上發送和接收的數據已經被分成一個或多個數據包（packet），每個數據包包括：要傳送的數據；控制信息，即告訴網絡怎樣處理數據包。TCP/IP決定了每個數據包的格式。如果事先不告訴你，你可能不會知道信息被分成用於傳輸和再重新組合起來的許多小塊。

許多HTTP通訊是由一個用戶代理初始化的並且包括一個申請在源服務器上資源的請求。最簡單的情況可能是在用戶代理(UA)和源服務器(O)之間通過一個單獨的連接來完成。

當一個或多個中介出現在請求/響應鏈中時，情況就變得復雜一些。中介有三種：代理(Proxy)、 網關(Gateway)和通道(Tunnel)。一個代理根據URI的絕對格式來接受請求，重寫全部或部分消息，通過URI的標識把已格式化過的請求發送到服務器。網關是一個接收代理，作為一些其它服務器的上層，並且如果必須的話，可以把請求翻譯給下層的服務器協議。一個通道作為不改變消息的兩個連接之間的中繼點。當通訊需要通過一個中介(例如：防火牆等)或者是中介不能識別消息的內容時，通道經常被使用。

報文格式

HTTP報文由從客戶機到服務器的請求和從服務器到客戶機的響應構成。請求報文格式如下：

請求行 － 通用信息頭 － 請求頭 － 實體頭 － 報文主體

請求行以方法字段開始，后面分別是 URL 字段和 HTTP 協議版本字段，並以 CRLF 結尾。SP 是分隔符。除了在最后的 CRLF 序列中 CF 和 LF 是必需的之外，其他都可以不要。有關通用信息頭，請求頭和實體頭方面的具體內容可以參照相關文件。

應答報文格式如下：

狀態行 － 通用信息頭 － 響應頭 － 實體頭 － 報文主體

狀態碼元由3位數字組成，表示請求是否被理解或被滿足。原因分析是對原文的狀態碼作簡短的描述，狀態碼用來支持自動操作，而原因分析用來供用戶使用。客戶機無需用來檢查或顯示語法。有關通用信息頭，響應頭和實體頭方面的具體內容可以參照相關文件。

工作原理

一次HTTP操作稱為一個事務，其工作過程可分為四步：

首先客戶機與服務器需要建立連接。只要單擊某個超級鏈接，HTTP的工作就開始了。

建立連接后，客戶機發送一個請求給服務器，請求方式的格式為：統一資源標識符（URL）、協議 版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。

服務器接到請求后，給予相應的響應信息，其格式為一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務器信息、實體信息和可能的內容。

客戶端接收服務器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然后客

http工作流程圖

戶機與服務器斷開連接。

如果在以上過程中的某一步出現錯誤，那么產生錯誤的信息將返回到客戶端，由顯示屏輸出。對於用戶來說，這些過程是由HTTP自己完成的，用戶只要用鼠標點擊，等待信息顯示就可以了。

許多HTTP通訊是由一個用戶代理初始化的並且包括一個申請在源服務器上資源的請求。最簡單的情況可能是在用戶代理和服務器之間通過一個單獨的連接來完成。在Internet上，HTTP通訊通常發生在TCP/IP連接之上。缺省端口是TCP 80，但其它的端口也是可用的。但這並不預示着HTTP協議在Internet或其它網絡的其它協議之上才能完成。HTTP只預示着一個可靠的傳輸。

這個過程就好像我們打電話訂貨一樣，我們可以打電話給商家，告訴他我們需要什么規格的商品，然后商家再告訴我們什么商品有貨，什么商品缺貨。這些，我們是通過電話線用電話聯系（HTTP是通過TCP/IP），當然我們也可以通過傳真，只要商家那邊也有傳真。

狀態消息

1xx:信息

消息	描述
100 Continue	服務器僅接收到部分請求，但是一旦服務器並沒有拒絕該請求，客戶端應該繼續發送其余的請求。
101 Switching Protocols	服務器轉換協議：服務器將遵從客戶的請求轉換到另外一種協議。

2xx:成功

消息	描述
200 OK	請求成功（其后是對GET和POST請求的應答文檔。）
201 Created	請求被創建完成，同時新的資源被創建。
202 Accepted	供處理的請求已被接受，但是處理未完成。
203 Non-authoritative Information	文檔已經正常地返回，但一些應答頭可能不正確，因為使用的是文檔的拷貝。
204 No Content	沒有新文檔。瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面，而Servlet可以確定用戶文檔足夠新，這個狀態代碼是很有用的。
205 Reset Content	沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。
206 Partial Content	客戶發送了一個帶有Range頭的GET請求，服務器完成了它。

3xx:重定向

消息	描述
300 Multiple Choices	多重選擇。鏈接列表。用戶可以選擇某鏈接到達目的地。最多允許五個地址。
301 Moved Permanently	所請求的頁面已經轉移至新的url。
302 Found	所請求的頁面已經臨時轉移至新的url。
303 See Other	所請求的頁面可在別的url下被找到。
304 Not Modified	未按預期修改文檔。客戶端有緩沖的文檔並發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩沖的文檔還可以繼續使用。
305 Use Proxy	客戶請求的文檔應該通過Location頭所指明的代理服務器提取。
306  Unused	此代碼被用於前一版本。目前已不再使用，但是代碼依然被保留。
307 Temporary Redirect	被請求的頁面已經臨時移至新的url。

4xx:客戶端錯誤

消息	描述
400 Bad Request	服務器未能理解請求。
401 Unauthorized	被請求的頁面需要用戶名和密碼。
401.1	登錄失敗。
401.2	服務器配置導致登錄失敗。
401.3	由於 ACL 對資源的限制而未獲得授權。
401.4	篩選器授權失敗。
401.5	ISAPI/CGI 應用程序授權失敗。
401.7	訪問被 Web 服務器上的 URL 授權策略拒絕。這個錯誤代碼為 IIS 6.0 所專用。
402 Payment Required	此代碼尚無法使用。
403 Forbidden	對被請求頁面的訪問被禁止。
403.1	執行訪問被禁止。
403.2	讀訪問被禁止。
403.3	寫訪問被禁止。
403.4	要求 SSL。
403.5	要求 SSL 128。
403.6	IP 地址被拒絕。
403.7	要求客戶端證書。
403.8	站點訪問被拒絕。
403.9	用戶數過多。
403.10	配置無效。
403.11	密碼更改。
403.12	拒絕訪問映射表。
403.13	客戶端證書被吊銷。
403.14	拒絕目錄列表。
403.15	超出客戶端訪問許可。
403.16	客戶端證書不受信任或無效。
403.17	客戶端證書已過期或尚未生效。
403.18	在當前的應用程序池中不能執行所請求的 URL。這個錯誤代碼為 IIS 6.0 所專用。
403.19	不能為這個應用程序池中的客戶端執行 CGI。這個錯誤代碼為 IIS 6.0 所專用。
403.20	Passport 登錄失敗。這個錯誤代碼為 IIS 6.0 所專用。
404 Not Found	服務器無法找到被請求的頁面。
404.0	（無）–沒有找到文件或目錄。
404.1	無法在所請求的端口上訪問 Web 站點。
404.2	Web 服務擴展鎖定策略阻止本請求。
404.3	MIME 映射策略阻止本請求。
405 Method Not Allowed	請求中指定的方法不被允許。
406 Not Acceptable	服務器生成的響應無法被客戶端所接受。
407 Proxy Authentication Required	用戶必須首先使用代理服務器進行驗證，這樣請求才會被處理。
408 Request Timeout	請求超出了服務器的等待時間。
409 Conflict	由於沖突，請求無法被完成。
410 Gone	被請求的頁面不可用。
411 Length Required	"Content-Length" 未被定義。如果無此內容，服務器不會接受請求。
412 Precondition Failed	請求中的前提條件被服務器評估為失敗。
413 Request Entity Too Large	由於所請求的實體的太大，服務器不會接受請求。
414 Request-url Too Long	由於url太長，服務器不會接受請求。當post請求被轉換為帶有很長的查詢信息的get請求時，就會發生這種情況。
415 Unsupported Media Type	由於媒介類型不被支持，服務器不會接受請求。
416 Requested Range Not Satisfiable	服務器不能滿足客戶在請求中指定的Range頭。
417 Expectation Failed	執行失敗。
423	鎖定的錯誤。

5xx:服務器錯誤

消息	描述
500 Internal Server Error	請求未完成。服務器遇到不可預知的情況。
500.12	應用程序正忙於在 Web 服務器上重新啟動。
500.13	Web 服務器太忙。
500.15	不允許直接請求 Global.asa。
500.16	UNC 授權憑據不正確。這個錯誤代碼為 IIS 6.0 所專用。
500.18	URL 授權存儲不能打開。這個錯誤代碼為 IIS 6.0 所專用。
500.100	內部 ASP 錯誤。
501 Not Implemented	請求未完成。服務器不支持所請求的功能。
502 Bad Gateway	請求未完成。服務器從上游服務器收到一個無效的響應。
502.1	CGI 應用程序超時。　·
502.2	CGI 應用程序出錯。
503 Service Unavailable	請求未完成。服務器臨時過載或當機。
504 Gateway Timeout	網關超時。
505 HTTP Version Not Supported	服務器不支持請求中指明的HTTP協議版本。

版本歷史

超文本傳輸協議已經演化出了很多版本，它們中的大部分都是向下兼容的。在RFC 2145中描述了HTTP

配置http通行證

版本號的用法。客戶端在請求的開始告訴服務器它采用的協議版本號，而后者則在響應中采用相同或者更早的協議版本。

0.9　已過時。只接受 GET 一種請求方法，沒有在通訊中指定版本號，且不支持請求頭。由於該版本不支持 POST 方法，所以客戶端無法向服務器傳遞太多信息。

HTTP/1.0　這是第一個在通訊中指定版本號的HTTP 協議版本，至今仍被廣泛采用，特別是在 代理服務器中。

HTTP/1.1　當前版本。持久連接被默認采用，並能很好地配合代理服務器工作。還支持以管道方式同時發送多個請求，以便降低線路負載，提高傳輸速度。

HTTP/1.1相較於 HTTP/1.0 協議的區別主要體現在：

1 緩存處理

2 帶寬優化及網絡連接的使用

3 錯誤通知的管理

4 消息在網絡中的發送

5 互聯網地址的維護

6 安全性及完整性

詞條圖冊更多圖冊

詞條圖片 (9)

 

參考資料

• 1.  各類Http請求狀態(status)及其含義 速查列表 xmlhttp status