發展簡史
理論提出
超文本傳輸協定的前身是世外桃源(Xanadu)項目，超文本的概念是泰德˙納爾森(Ted Nelson)在1960年代提出的。進入哈佛大學後，納爾森一直致力於超文本協定和該項目的研究，但他從未公開發表過資料。
程式開發
1989年，蒂姆˙伯納斯˙李(Tim Berners Lee)在CERN(歐洲原子核研究委員會 = European Organization for Nuclear Research)擔任軟體諮詢師的時候，開發了一套程式，奠定了全球資訊網的基礎。1990年12月，超文本在CERN首次上線。1991年夏天，繼Telnet等協定之後，超文本轉移協定成為網際網路諸多協定的一分子。
發展狀況
當時，Telnet協定解決了一台計算機和另外一台計算機之間一對一的控制型通信的要求。郵件協定解決了一個發件人向少量人員傳送信息的通信要求。檔案傳輸協定解決一台計算機從另外一台計算機批量獲取檔案的通信要求，但是它不具備一邊獲取檔案一邊顯示檔案或對檔案進行某種處理的功能。新聞傳輸協定解決了一對多新聞廣播的通信要求。而超文本要解決的通信要求是:在一台計算機上獲取並顯示存放在多台計算機里的文本、數據、圖片和其他類型的檔案;它包含兩大部分:超文本轉移協定和超文本標記語言(HTML)。HTTP、HTML以及瀏覽器的誕生給網際網路的普及帶來了飛躍。
技術架構
http和其他幾種網路協定 
HTTP協定的網頁 通常，由HTTP客戶端發起一個請求，建立一個到伺服器指定連線埠（默認是80連線埠）的TCP連線。HTTP伺服器則在那個連線埠監聽客戶端傳送過來的請求。一旦收到請求，伺服器（向客戶端）發回一個狀態行，比如"HTTP/1.1 200 OK"，和（回響的）訊息，訊息的訊息體可能是請求的檔案、錯誤訊息、或者其它一些信息。
HTTP使用TCP而不是UDP的原因在於（打開）一個網頁必須傳送很多數據，而TCP協定提供傳輸控制，按順序組織數據，和錯誤糾正。
通過HTTP或者HTTPS協定請求的資源由統一資源標示符（Uniform Resource Identifiers）（或者，更準確一些，URLs）來標識。
協定功能
http功用 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的頭域包括通用頭，請求頭，回響頭和實體頭四個部分。每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前可以添加任何數量的空格符，頭域可以被擴展為多行，在每行開始處，使用至少一個空格或制表符。
通用頭域
http 
http結構 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、郵件群組和資料庫傳送訊息。
http架構 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實體頭指定伺服器上保存內容的最後修訂時間。
例如，傳送頭500個位元組次欄位的形式：Content-Range:bytes0-499/1234如果一個http訊息包含此節（例如，對範圍請求的回響或對一系列範圍的重疊請求），Content-Range表示傳送的範圍，Content-Length表示實際傳送的位元組數。
運作方式
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），當然我們也可以通過傳真，只要商家那邊也有傳真。
狀態訊息
| 訊息 | 描述 |
|---|---|
| 100 Continue | 伺服器僅接收到部分請求，但是一旦伺服器並沒有拒絕該請求，客戶端應該繼續傳送其餘的請求。 |
| 101 Switching Protocols | 伺服器轉換協定：伺服器將遵從客戶的請求轉換到另外一種協定。 |
| 訊息 | 描述 |
|---|---|
| 200 OK | 請求成功（其後是對GET和POST請求的應答文檔。） |
| 201 Created | 請求被創建完成，同時新的資源被創建。 |
| 202 Accepted | 供處理的請求已被接受，但是處理未完成。 |
| 203 Non-authoritative Information | 文檔已經正常地返回，但一些應答頭可能不正確，因為使用的是文檔的拷貝。 |
| 204 No Content | 沒有新文檔。瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面，而Servlet可以確定用戶文檔足夠新，這個狀態代碼是很有用的。 |
| 205 Reset Content | 沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。 |
| 206 Partial Content | 客戶傳送了一個帶有Range頭的GET請求，伺服器完成了它。 |
| 訊息 | 描述 |
|---|---|
| 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。 |
| 訊息 | 描述 |
|---|---|
| 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 | 鎖定的錯誤。 |
| 訊息 | 描述 |
|---|---|
| 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通行證 0.9已過時。只接受GET一種請求方法，沒有在通訊中指定版本號，且不支持請求頭。由於該版本不支持POST方法，所以客戶端無法向伺服器傳遞太多信息。
HTTP/1.0這是第一個在通訊中指定版本號的HTTP 協定版本，至今仍被廣泛採用，特別是在代理伺服器中。
HTTP/1.1當前版本。持久連線被默認採用，並能很好地配合代理伺服器工作。還支持以管道方式同時傳送多個請求，以便降低線路負載，提高傳輸速度。
HTTP/1.1相較於HTTP/1.0協定的區別主要體現在：
1 快取處理
2 頻寬最佳化及網路連線的使用
3 錯誤通知的管理
4 訊息在網路中的傳送
5 網際網路地址的維護
6 安全性及完整性
