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。

技術架構,協定功能,協定基礎,通用頭域,請求訊息,回響訊息,實體信息,運作方式,報文格式,工作原理,狀態訊息,版本歷史,

技術架構

HTTP是一個客戶端和伺服器端請求和應答的標準（TCP）。客戶端是終端用戶，伺服器端是網站。通過使用Web瀏覽器、網路爬蟲或者其它的工具，客戶端發起一個到伺服器上指定連線埠（默認連線埠為80）的HTTP請求。（我們稱這個客戶端）叫用戶代理（user agent）。應答的伺服器上存儲著（一些）資源，比如HTML檔案和圖像。（我們稱）這個應答伺服器為源伺服器（origin server）。在用戶代理和源伺服器中間可能存在多箇中間層，比如代理，網關，或者隧道（tunnels）。儘管TCP/IP協定是網際網路上最流行的套用，HTTP協定並沒有規定必須使用它和（基於）它支持的層。事實上，HTTP可以在任何其他網際網路協定上，或者在其他網路上實現。HTTP只假定（其下層協定提供）可靠的傳輸，任何能夠提供這種保證的協定都可以被其使用。

通常，由HTTP客戶端發起一個請求，建立一個到伺服器指定連線埠（默認是80連線埠）的TCP連線。HTTP伺服器則在那個連線埠監聽客戶端傳送過來的請求。一旦收到請求，伺服器（向客戶端）發回一個狀態行，比如"HTTP/1.1 200 OK"，和（回響的）訊息，訊息的訊息體可能是請求的檔案、錯誤訊息、或者其它一些信息。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地址。當你在瀏覽器的地址框中輸入一個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指示對於單個用戶的整個或部分回響訊息，不能被共享快取處理。這允許伺服器僅僅描述當用戶的部分回響訊息，此回響訊息對於其他用戶的請求無效。

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表示換行回車符。請求頭域允許客戶端向伺服器傳遞關於請求或者關於客戶機的附加信息。請求頭域可能包含下列欄位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實體頭指定伺服器上保存內容的最後修訂時間。

運作方式

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

HTTP協定是基於請求/回響範式的。一個客戶機與伺服器建立連線後，傳送一個請求給伺服器，請求方式的格式為，統一資源標識符、協定版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。伺服器接到請求後，給予相應的回響信息，其格式為一個狀態行包括信息的協定版本號、一個成功或錯誤的代碼，後邊是MIME信息包括伺服器信息、實體信息和可能的內容。其實簡單說就是任何伺服器除了包括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通訊是由一個用戶代理初始化的並且包括一個申請在源伺服器上資源的請求。最簡單的情況可能是在用戶代理和伺服器之間通過一個單獨的連線來完成。在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版本號的用法。客戶端在請求的開始告訴伺服器它採用的協定版本號，而後者則在回響中採用相同或者更早的協定版本。

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

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

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

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

1 快取處理

2 頻寬最佳化及網路連線的使用

3 錯誤通知的管理

4 訊息在網路中的傳送

5 網際網路地址的維護

6 安全性及完整性

http