http 超文字傳輸通訊協定 (HTTP)

標籤：

超文字傳輸通訊協定 (HTTP)（HTTP，HyperText Transfer Protocol)是互連網上應用最為廣泛的一種網路通訊協定。所有的WWW檔案都必須遵守這個標準。設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法。1960年美國人Ted Nelson構思了一種通過電腦處理文本資訊的方法，並稱之為超文本（hypertext）,這成為了HTTP超文字傳輸通訊協定 (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，超文字傳輸通訊協定 (HTTP)）是用於從WWW伺服器傳輸超文本到本地瀏覽器的傳輸協議。它可以使瀏覽器更加高效，使網路傳輸減少。它不僅保證電腦正確快速地傳輸超文字文件，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先於圖形)等。HTTP是用戶端瀏覽器或其他程式與Web伺服器之間的應用程式層通訊協定。在Internet上的Web伺服器上存放的都是超文本資訊，客戶機需要通過HTTP協議傳輸所要訪問的超文本資訊。HTTP包含命令和傳輸資訊，不僅可用於Web訪問，也可以用於其他網際網路/內連網應用系統之間的通訊，從而實現各類應用資源超媒體訪問的整合。我們在瀏覽器的地址欄裡輸入的網站地址叫做URL (Uniform Resource Locator，統一資源定位器)。就像每家每戶都有一個門牌地址一樣，每個網頁也都有一個Internet地址。當你在http功用瀏覽器的地址框中輸入一個URL或是單擊一個超級連結時，URL就確定了要瀏覽的地址。瀏覽器通過超文字傳輸通訊協定 (HTTP)(HTTP)，將Web伺服器上網站的網頁代碼提取出來，並翻譯成漂亮的網頁。協議基礎HTTP（HyperText Transport Protocol）是超文字傳輸通訊協定 (HTTP)的縮寫，它用於傳送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-AliveKeep-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.*******.deAccept: */*Pragma: no-cacheCache-Control: no-cacheUser-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-PhraseCRLFHTTP-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.0200OKDate:Mon,31Dec200104:25:57GMTServer:Apache/1.3.14(Unix)Content-type:text/htmlLast-modified:Tue,17Apr200106:46:28GMTEtag:"a030f020ac7c01:1e9f"Content-length:39725426Content-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頭所指明的Proxy 伺服器提取。
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	使用者必須首先使用Proxy 伺服器進行驗證，這樣請求才會被處理。
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協議版本。

版本曆史超文字傳輸通訊協定 (HTTP)已經演化出了很多版本，它們中的大部分都是向下相容的。在RFC 2145中描述了HTTP配置http通行證版本號碼的用法。用戶端在請求的開始告訴伺服器它採用的協議版本號碼，而後者則在響應中採用相同或者更早的協議版本。0.9　已淘汰。只接受 GET 一種要求方法，沒有在通訊中指定版本號碼，且不支援要求頭。由於該版本不支援 POST 方法，所以用戶端無法向伺服器傳遞太多資訊。HTTP/1.0　這是第一個在通訊中指定版本號碼的HTTP 協議版本，至今仍被廣泛採用，特別是在Proxy 伺服器中。HTTP/1.1　目前的版本。持久串連被預設採用，並能很好地配合Proxy 伺服器工作。還支援以管道方式同時發送多個請求，以便降低線路負載，提高傳輸速度。HTTP/1.1相較於 HTTP/1.0 協議的區別主要體現在：1 緩衝處理2 頻寬最佳化及網路連接的使用3 錯誤通知的管理4 訊息在網路中的發送5 互連網地址的維護6 安全性及完整性詞條圖冊更多圖冊詞條圖片(9) 

參考資料

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

http 超文字傳輸通訊協定 (HTTP)