http協議包含哪幾個部分

時間 2020-01-10

原文原文鏈接

原文連接： caibaojian.com/http.html

HTTP協議包含：通用頭域、請求消息、響應消息和主體信息。·html

超文本傳輸協議（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技術架構

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

多箇中間層，好比代理，網關，或者隧道（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）來標識。

2協議功能

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

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

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

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

3協議基礎

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-MD五、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實體頭指定服務器上保存內容的最後修訂時間。

4運做方式

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

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

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

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

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

5報文格式

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

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

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

應答報文格式以下：

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

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

6工做原理

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

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

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

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

客戶端接收服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上，而後客戶機與服務器斷開鏈接。

若是在以上過程當中的某一步出現錯誤，那麼產生錯誤的信息將返回到客戶端，由顯示屏輸出。對於用戶來講，這些過程是由HTTP本身完成的，用戶只要用鼠標點擊，等待信息顯示就能夠了。

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

這個過程就好像咱們打電話定貨同樣，咱們能夠打電話給商家，告訴他咱們須要什麼規格的商品，而後商家再告訴咱們什麼商品有貨，什麼商品缺貨。這些，咱們是經過電話線用電話聯繫（HTTP是經過TCP/IP），固然咱們也能夠經過傳真，只要商家那邊也有傳真。

7狀態消息

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協議版本。