HTTP協(xié)議培訓(xùn)教程資料

協(xié)議基礎(chǔ)
　　HTTP（HyperText Transfer Protocol）是超文本傳輸協(xié)議的縮寫，它用于傳送WWW方式的數(shù)據(jù)，關(guān)于HTTP協(xié)議的詳細(xì)內(nèi)容請(qǐng)參考RFC2616。HTTP協(xié)議采用了請(qǐng)求/響應(yīng)模型。客戶端向服務(wù)器發(fā)送一個(gè)請(qǐng)求，請(qǐng)求頭包含請(qǐng)求的方法、URL、協(xié)議版本、以及包含請(qǐng)求修飾符、客戶信息和內(nèi)容的類似于MIME的消息結(jié)構(gòu)。服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)，相應(yīng)的內(nèi)容包括消息協(xié)議的版本，成功或者錯(cuò)誤編碼加上包含服務(wù)器信息、實(shí)體元信息以及可能的實(shí)體內(nèi)容。
　　通常HTTP消息包括客戶機(jī)向服務(wù)器的請(qǐng)求消息和服務(wù)器向客戶機(jī)的響應(yīng)消息。這兩種類型的消息由一個(gè)起始行，一個(gè)或者多個(gè)頭域，一個(gè)指示頭域結(jié)束的空行和可選的消息體組成。HTTP的頭域包括通用頭，請(qǐng)求頭，響應(yīng)頭和實(shí)體頭四個(gè)部分。每個(gè)頭域由一個(gè)域名，冒號(hào)（:）和域值三部分組成。域名是大小寫無(wú)關(guān)的，域值前可以添加任何數(shù)量的空格符，頭域可以被擴(kuò)展為多行，在每行開始處，使用至少一個(gè)空格或制表符。
　　通用頭域
　　通用頭域包含請(qǐng)求和響應(yīng)消息都支持的頭域，通用頭域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對(duì)通用頭域的擴(kuò)展要求通訊雙方都支持此擴(kuò)展，如果存在不支持的通用頭域，一般將會(huì)作為實(shí)體頭域處理。下面簡(jiǎn)單介紹幾個(gè)在UPnP消息中使用的通用頭域。
　　Cache-Control頭域
　　Cache-Control指定請(qǐng)求和響應(yīng)遵循的緩存機(jī)制。在請(qǐng)求消息或響應(yīng)消息中設(shè)置Cache-Control并不會(huì)修改另一個(gè)消息處理過程中的緩存處理過程。請(qǐng)求時(shí)的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，響應(yīng)消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各個(gè)消息中的指令含義如下：
　　Public指示響應(yīng)可被任何緩存區(qū)緩存。
　　Private指示對(duì)于單個(gè)用戶的整個(gè)或部分響應(yīng)消息，不能被共享緩存處理。這允許服務(wù)器僅僅描述當(dāng)用戶的部分響應(yīng)消息，此響應(yīng)消息對(duì)于其他用戶的請(qǐng)求無(wú)效。
　　no-cache指示請(qǐng)求或響應(yīng)消息不能緩存
　　no-store用于防止重要的信息被無(wú)意的發(fā)布。在請(qǐng)求消息中發(fā)送將使得請(qǐng)求和響應(yīng)消息都不使用緩存。
　　max-age指示客戶機(jī)可以接收生存期不大于指定時(shí)間（以秒為單位）的響應(yīng)。
　　min-fresh指示客戶機(jī)可以接收響應(yīng)時(shí)間小于當(dāng)前時(shí)間加上指定時(shí)間的響應(yīng)。
　　max-stale指示客戶機(jī)可以接收超出超時(shí)期間的響應(yīng)消息。如果指定max-stale消息的值，那么客戶機(jī)可以接收超出超時(shí)期指定值之內(nèi)的響應(yīng)消息。
　　Date頭域
　　Date頭域表示消息發(fā)送的時(shí)間，時(shí)間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時(shí)間表示世界標(biāo)準(zhǔn)時(shí)，換算成本地時(shí)間，需要知道用戶所在的時(shí)區(qū)。
　　Pragma頭域
　　Pragma頭域用來包含實(shí)現(xiàn)特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1協(xié)議中，它的含義和Cache-Control:no-cache相同。
　　請(qǐng)求消息
　　請(qǐng)求消息的第一行為下面的格式：
　　MethodSPRequest-URISPHTTP-VersionCRLFMethod表示對(duì)于Request-URI完成的方法，這個(gè)字段是大小寫敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。方法GET和HEAD應(yīng)該被所有的通用WEB服務(wù)器支持，其他所有方法的實(shí)現(xiàn)是可選的。GET方法取回由Request-URI標(biāo)識(shí)的信息。HEAD方法也是取回由Request-URI標(biāo)識(shí)的信息，只是可以在響應(yīng)時(shí)，不返回消息體。POST方法可以請(qǐng)求服務(wù)器接收包含在請(qǐng)求中的實(shí)體信息，可以用于提交表單，向新聞組、BBS、郵件群組和數(shù)據(jù)庫(kù)發(fā)送消息。
　　SP表示空格。Request-URI遵循URI格式，在此字段為星號(hào)（*）時(shí)，說明請(qǐng)求并不用于某個(gè)特定的資源地址，而是用于服務(wù)器本身。HTTP-Version表示支持的HTTP版本，例如為HTTP/1.1。CRLF表示換行回車符。請(qǐng)求頭域允許客戶端向服務(wù)器傳遞關(guān)于請(qǐng)求或者關(guān)于客戶機(jī)的附加信http架構(gòu)息。請(qǐng)求頭域可能包含下列字段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。對(duì)請(qǐng)求頭域的擴(kuò)展要求通訊雙方都支持，如果存在不支持的請(qǐng)求頭域，一般將會(huì)作為實(shí)體頭域處理。
　　典型的請(qǐng)求消息：
　　Host: download.microtool.de
　　Accept: */*
　　Pragma: no-cache
　　Cache-Control: no-cache
　　User-Agent: Mozilla/4.04[en](Win95;I;Nav)
　　Range: bytes=554554-
　　上例第一行表示HTTP客戶端（可能是瀏覽器、下載程序）通過GET方法獲得指定URL下的文件。棕色的部分表示請(qǐng)求頭域的信息，綠色的部分表示通用頭部分。
　　Host頭域
　　Host頭域指定請(qǐng)求資源的Intenet主機(jī)和端口號(hào)，必須表示請(qǐng)求url的原始服務(wù)器或網(wǎng)關(guān)的位置。HTTP/1.1請(qǐng)求必須包含主機(jī)頭域，否則系統(tǒng)會(huì)以400狀態(tài)碼返回。
　　Referer頭域
　　Referer頭域允許客戶端指定請(qǐng)求uri的源資源地址，這可以允許服務(wù)器生成回退鏈表，可用來登陸、優(yōu)化cache等。他也允許廢除的或錯(cuò)誤的連接由于維護(hù)的目的被追蹤。如果請(qǐng)求的uri沒有自己的uri地址，Referer不能被發(fā)送。如果指定的是部分uri地址，則此地址應(yīng)該是一個(gè)相對(duì)地址。
　　Range頭域
　　Range頭域可以請(qǐng)求實(shí)體的一個(gè)或者多個(gè)子范圍。例如，
　　表示頭500個(gè)字節(jié)：bytes=0-499
　　表示第二個(gè)500字節(jié)：bytes=500-999
　　表示最后500個(gè)字節(jié)：bytes=-500
　　表示500字節(jié)以后的范圍：bytes=500-
　　第一個(gè)和最后一個(gè)字節(jié)：bytes=0-0,-1
　　同時(shí)指定幾個(gè)范圍：bytes=500-600,601-999
　　但是服務(wù)器可以忽略此請(qǐng)求頭，如果無(wú)條件GET包含Range請(qǐng)求頭，響應(yīng)會(huì)以狀態(tài)碼206（PartialContent）返回而不是以200（OK）。
　　User-Agent頭域
　　User-Agent頭域的內(nèi)容包含發(fā)出請(qǐng)求的用戶信息。
　　響應(yīng)消息
　　響應(yīng)消息的第一行為下面的格式：
　　HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF
　　HTTP-Version表示支持的HTTP版本，例如為HTTP/1.1。Status-Code是一個(gè)三個(gè)數(shù)字的結(jié)果代碼。Reason-Phrase給Status-Code提供一個(gè)簡(jiǎn)單的文本描述。Status-Code主要用于機(jī)器自動(dòng)識(shí)別，Reason-Phrase主要用于幫助用戶理解。Status-Code的第一個(gè)數(shù)字定義響應(yīng)的類別，后兩個(gè)數(shù)字沒有分類的作用。第一個(gè)數(shù)字可能取5個(gè)不同的值：
　　1xx:信息響應(yīng)類，表示接收到請(qǐng)求并且繼續(xù)處理
　　2xx:處理成功響應(yīng)類，表示動(dòng)作被成功接收、理解和接受
　　3xx:重定向響應(yīng)類，為了完成指定的動(dòng)作，必須接受進(jìn)一步處理
　　4xx:客戶端錯(cuò)誤，客戶請(qǐng)求包含語(yǔ)法錯(cuò)誤或者是不能正確執(zhí)行
　　5xx:服務(wù)端錯(cuò)誤，服務(wù)器不能正確執(zhí)行一個(gè)正確的請(qǐng)求
　　響應(yīng)頭域允許服務(wù)器傳遞不能放在狀態(tài)行的附加信息，這些域主要描述服務(wù)器的信息和Request-URI進(jìn)一步的信息。響應(yīng)頭域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。對(duì)響應(yīng)頭域的擴(kuò)展要求通訊雙方都支持，如果存在不支持的響應(yīng)頭域，一般將會(huì)作為實(shí)體頭域處理。
　　典型的響應(yīng)消息：
　　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:bytes554554-40279979/40279980
　　上例第一行表示HTTP服務(wù)端響應(yīng)一個(gè)GET方法。棕色的部分表示響應(yīng)頭域的信息，綠色的部分表示通用頭部分，紅色的部分表示實(shí)體頭域的信息。
　　Location響應(yīng)頭
　　Location響應(yīng)頭用于重定向接收者到一個(gè)新URI地址。
　　Server響應(yīng)頭
　　Server響應(yīng)頭包含處理請(qǐng)求的原始服務(wù)器的軟件信息。此域能包含多個(gè)產(chǎn)品標(biāo)識(shí)和注釋，產(chǎn)品標(biāo)識(shí)一般按照重要性排序。
　　HTTP-運(yùn)作方式
　　HTTP協(xié)議是基于請(qǐng)求／響應(yīng)范式的。一個(gè)客戶機(jī)與服務(wù)器建立連接后，發(fā)送一個(gè)請(qǐng)求給服務(wù)器，請(qǐng)求方式的格式為，統(tǒng)一資源標(biāo)識(shí)符、協(xié)議版本號(hào)，后邊是MIME信息包括請(qǐng)求修飾符、客戶機(jī)信息和可能的內(nèi)容。服務(wù)器接到請(qǐng)求后，給予相應(yīng)的響應(yīng)信息，其格式為一個(gè)狀態(tài)行包括信息的協(xié)議版本號(hào)、一個(gè)成功或錯(cuò)誤的代碼，后邊是MIME信息包括服務(wù)器信息、實(shí)體信息和可能的內(nèi)容。
　　許多HTTP通訊是由一個(gè)用戶代理初始化的并且包括一個(gè)申請(qǐng)?jiān)谠捶?wù)器上資源的請(qǐng)求。最簡(jiǎn)單的情況可能是在用戶代理(UA)和源服務(wù)器(O)之間通過一個(gè)單獨(dú)的連接來完成。
　　當(dāng)一個(gè)或多個(gè)中介出現(xiàn)在請(qǐng)求／響應(yīng)鏈中時(shí)，情況就變得復(fù)雜一些。中介由三種：代理(Proxy)、網(wǎng)關(guān)(Gateway)和通道(Tunnel)。一個(gè)代理根據(jù)URI的絕對(duì)格式來接受請(qǐng)求，重寫全部或部分消息，通過URI的標(biāo)識(shí)把已格式化過的請(qǐng)求發(fā)送到服務(wù)器。網(wǎng)關(guān)是一個(gè)接收代理，作為一些其它服務(wù)器的上層，并且如果必須的話，可以把請(qǐng)求翻譯給下層的服務(wù)器協(xié)議。一個(gè)通道作為不改變消息的兩個(gè)連接之間的中繼點(diǎn)。當(dāng)通訊需要通過一個(gè)中介(例如：防火墻等)或者是中介不能識(shí)別消息的內(nèi)容時(shí)，通道經(jīng)常被使用.
　　實(shí)體
　　請(qǐng)求消息和響應(yīng)消息都可以包含實(shí)體信息，實(shí)體信息一般由實(shí)體頭域和實(shí)體組成。實(shí)體頭域包含關(guān)于實(shí)體的原信息，實(shí)體頭包括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允許客戶端定義新的實(shí)體頭，但是這些域可能無(wú)法未接受方識(shí)別。實(shí)體可以是一個(gè)經(jīng)過編碼的字節(jié)流，它的編碼方式由Content-Encoding或Content-Type定義，它的長(zhǎng)度由Content-Length或Content-Range定義。
　　Content-Type實(shí)體頭
　　Content-Type實(shí)體頭用于向接收方指示實(shí)體的介質(zhì)類型，指定HEAD方法送到接收方的實(shí)體介質(zhì)類型，或GET方法發(fā)送的請(qǐng)求介質(zhì)類型Content-Range實(shí)體頭
　　Content-Range實(shí)體頭用于指定整個(gè)實(shí)體中的一部分的插入位置，他也指示了整個(gè)實(shí)體的長(zhǎng)度。在服務(wù)器向客戶返回一個(gè)部分響應(yīng)，它必須描述響應(yīng)覆蓋的范圍和整個(gè)實(shí)體長(zhǎng)度。一般格式：
　　Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth
　　例如，傳送頭500個(gè)字節(jié)次字段的形式：Content-Range:bytes0-499/1234如果一個(gè)http消息包含此節(jié)（例如，對(duì)范圍請(qǐng)求的響應(yīng)或?qū)σ幌盗蟹秶闹丿B請(qǐng)求），Content-Range表示傳送的范圍，Content-Length表示實(shí)際傳送的字節(jié)數(shù)。
　　Last-modified實(shí)體頭
　　Last-modified實(shí)體頭指定服務(wù)器上保存內(nèi)容的最后修訂時(shí)間。
　　例如，傳送頭500個(gè)字節(jié)次字段的形式：Content-Range:bytes0-499/1234如果一個(gè)http消息包含此節(jié)（例如，對(duì)范圍請(qǐng)求的響應(yīng)或?qū)σ幌盗蟹秶闹丿B請(qǐng)求），Content-Range表示傳送的范圍，Content-Length表示實(shí)際傳送的字節(jié)數(shù)。
　　Last-modified實(shí)體頭
協(xié)議結(jié)構(gòu)
　　HTTP報(bào)文由從客戶機(jī)到服務(wù)器的請(qǐng)求和從服務(wù)器到客戶機(jī)的響應(yīng)構(gòu)成。請(qǐng)求報(bào)文格式如下：
　　請(qǐng)求行 － 通用信息頭 － 請(qǐng)求頭 － 實(shí)體頭 － 報(bào)文主體
　　請(qǐng)求行以方法字段開始，后面分別是 URL 字段和 HTTP 協(xié)議版本字段，并以 CRLF 結(jié)尾。SP 是分隔符。除了在最后的 CRLF 序列中 CF 和 LF 是必需的之外，其他都可以不要。有關(guān)通用信息頭，請(qǐng)求頭和實(shí)體頭方面的具體內(nèi)容可以參照相關(guān)文件。
　　應(yīng)報(bào)文格式如下：
　　狀態(tài)行 － 通用信息頭 － 響應(yīng)頭 － 實(shí)體頭 － 報(bào)文主體
　　狀態(tài)碼元由3位數(shù)字組成，表示請(qǐng)求是否被理解或被滿足。原因分析是對(duì)原文的狀態(tài)碼作簡(jiǎn)短的描述，狀態(tài)碼用來支持自動(dòng)操作，而原因分析用來供用戶使用?？蛻魴C(jī)無(wú)需用來檢查或顯示語(yǔ)法。有關(guān)通用信息頭，響應(yīng)頭和實(shí)體頭方面的具體內(nèi)容可以參照相關(guān)文件。
工作原理
　　既然我們明白了URL的構(gòu)成，那么HTTP是怎么工作呢？我們接下來就要討論這個(gè)問題。
　　一次HTTP操作稱為一個(gè)事務(wù)，其工作過程可分為四步：
　　首先客戶機(jī)與服務(wù)器需要建立連接。只要單擊某個(gè)超級(jí)鏈接，HTTP的工作就開始了。
　　建立連接后，客戶機(jī)發(fā)送一個(gè)請(qǐng)求給服務(wù)器，請(qǐng)求方式的格式為：統(tǒng)一資源標(biāo)識(shí)符（URL）、協(xié)議版本號(hào)，后邊是MIME信息包括請(qǐng)求修飾符、客戶機(jī)信息和可能的內(nèi)容。
　　服務(wù)器接到請(qǐng)求后，給予相應(yīng)的響應(yīng)信息，其格式為一個(gè)狀態(tài)行，包括信息的協(xié)議版本號(hào)、一個(gè)成功或錯(cuò)誤的代碼，后邊是MIME信息包括服務(wù)器信息、實(shí)體信息和可能的內(nèi)容。
　　客戶端接收服務(wù)器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然后客http工作流程圖戶機(jī)與服務(wù)器斷開連接。
　　如果在以上過程中的某一步出現(xiàn)錯(cuò)誤，那么產(chǎn)生錯(cuò)誤的信息將返回到客戶端，有顯示屏輸出。對(duì)于用戶來說，這些過程是由HTTP自己完成的，用戶只要用鼠標(biāo)點(diǎn)擊，等待信息顯示就可以了。
　　許多HTTP通訊是由一個(gè)用戶代理初始化的并且包括一個(gè)申請(qǐng)?jiān)谠捶?wù)器上資源的請(qǐng)求。最簡(jiǎn)單的情況可能是在用戶代理和服務(wù)器之間通過一個(gè)單獨(dú)的連接來完成。在Internet上，HTTP通訊通常發(fā)生在TCP/IP連接之上。缺省端口是TCP 80，但其它的端口也是可用的。但這并不預(yù)示著HTTP協(xié)議在Internet或其它網(wǎng)絡(luò)的其它協(xié)議之上才能完成。HTTP只預(yù)示著一個(gè)可靠的傳輸。
　　這個(gè)過程就好像我們打電話訂貨一樣，我們可以打電話給商家，告訴他我們需要什么規(guī)格的商品，然后商家再告訴我們什么商品有貨，什么商品缺貨。這些，我們是通過電話線用電話聯(lián)系（HTTP是通過TCP/IP），當(dāng)然我們也可以通過傳真，只要商家那邊也有傳真。
　　以上簡(jiǎn)要介紹了HTTP協(xié)議的宏觀運(yùn)作方式，下面介紹一下HTTP協(xié)議的內(nèi)部操作過程。
　　在WWW中，“客戶”與“服務(wù)器”是一個(gè)相對(duì)的概念，只存在于一個(gè)特定的連接期間，即在某個(gè)連接中的客戶在另一個(gè)連接中可能作為服務(wù)器?；贖TTP協(xié)議的客戶/服務(wù)器模式的信息交換過程，它分四個(gè)過程：建立連接、發(fā)送請(qǐng)求信息、發(fā)送響應(yīng)信息、關(guān)閉連接。這就好像上面的例子，我們電話訂貨的全過程。
　　其實(shí)簡(jiǎn)單說就是任何服務(wù)器除了包括HTML文件以外，還有一個(gè)HTTP駐留程序，用于響應(yīng)用戶請(qǐng)求。你的瀏覽器是HTTP客戶，向服務(wù)器發(fā)送請(qǐng)求，當(dāng)瀏覽器中輸入了一個(gè)開始文件或點(diǎn)擊了一個(gè)超級(jí)鏈接時(shí)，瀏覽器就向服務(wù)器發(fā)送了HTTP請(qǐng)求，此請(qǐng)求被送往由IP地址指定的URL。駐留程序接收到請(qǐng)求，在進(jìn)行必要的操作后回送所要求的文件。在這一過程中，在網(wǎng)絡(luò)上發(fā)送和接收的數(shù)據(jù)已經(jīng)被分成一個(gè)或多個(gè)數(shù)據(jù)包（packet），每個(gè)數(shù)據(jù)包包括：要傳送的數(shù)據(jù)；控制信息，即告訴網(wǎng)絡(luò)怎樣處理數(shù)據(jù)包。TCP/IP決定了每個(gè)數(shù)據(jù)包的格式。如果事先不告訴你，你可能不會(huì)知道信息被分成用于傳輸和再重新組合起來的許多小塊。
　　也就是說商家除了擁有商品之外，它也有一個(gè)職員在接聽你的電話，當(dāng)你打電話的時(shí)候，你的聲音轉(zhuǎn)換成各種復(fù)雜的數(shù)據(jù)，通過電話線傳輸?shù)綄?duì)方的電話機(jī)，對(duì)方的電話機(jī)又把各種復(fù)雜的數(shù)據(jù)轉(zhuǎn)換成聲音，使得對(duì)方商家的職員能夠明白你的請(qǐng)求。這個(gè)過程你不需要明白聲音是怎么轉(zhuǎn)換成復(fù)雜的數(shù)據(jù)的。
錯(cuò)誤代碼解釋
　　"100" : Continue
　　"101" : witching Protocols
　　"200" : OK
　　"201" : Created
　　"202" : Accepted
　　"203" : Non-Authoritative Information
　　"204" : No Content
　　"205" : Reset Content
　　"206" : Partial Content
　　"300" : Multiple Choices
　　"301" : Moved Permanently
　　"302" : Found
　　"303" : See Other
　　"304" : Not Modified
　　"305" : Use Proxy
　　"307" : Temporary Redirect
　　HTTP 400 - 請(qǐng)求無(wú)效
　　HTTP 401.1 - 未授權(quán)：登錄失敗
　　HTTP 401.2 - 未授權(quán)：服務(wù)器配置問題導(dǎo)致登錄失敗
　　HTTP 401.3 - ACL 禁止訪問資源
　　HTTP 401.4 - 未授權(quán)：授權(quán)被篩選器拒絕
　　HTTP 401.5 - 未授權(quán)：ISAPI 或 CGI 授權(quán)失敗
　　HTTP 403 - 禁止訪問
　　HTTP 403 - 對(duì) Internet 服務(wù)管理器 (HTML) 的訪問僅限于 Localhost
　　HTTP 403.1 禁止訪問：禁止可執(zhí)行訪問
　　HTTP 403.2 - 禁止訪問：禁止讀訪問
　　HTTP 403.3 - 禁止訪問：禁止寫訪問
　　HTTP 403.4 - 禁止訪問：要求 SSL
　　HTTP 403.5 - 禁止訪問：要求 SSL 128
　　HTTP 403.6 - 禁止訪問：IP 地址被拒絕
　　HTTP 403.7 - 禁止訪問：要求客戶證書
　　HTTP 403.8 - 禁止訪問：禁止站點(diǎn)訪問
　　HTTP 403.9 - 禁止訪問：連接的用戶過多
　　HTTP 403.10 - 禁止訪問：配置無(wú)效
　　HTTP 403.11 - 禁止訪問：密碼更改
　　HTTP 403.12 - 禁止訪問：映射器拒絕訪問
　　HTTP 403.13 - 禁止訪問：客戶證書已被吊銷
　　HTTP 403.15 - 禁止訪問：客戶訪問許可過多
　　HTTP 403.16 - 禁止訪問：客戶證書不可信或者無(wú)效
　　HTTP 403.17 - 禁止訪問：客戶證書已經(jīng)到期或者尚未生效
　　HTTP 404.1 - 無(wú)法找到 Web 站點(diǎn)
　　HTTP 404 - 無(wú)法找到文件
　　HTTP 405 - 資源被禁止
　　HTTP 406 - 無(wú)法接受
　　HTTP 407 - 要求代理身份驗(yàn)證
　　HTTP 410 - 永遠(yuǎn)不可用
　　HTTP 412 - 先決條件失敗
　　HTTP 414 - 請(qǐng)求 - URI 太長(zhǎng)
　　HTTP 500 - 內(nèi)部服務(wù)器錯(cuò)誤
　　HTTP 500.100 - 內(nèi)部服務(wù)器錯(cuò)誤 - ASP 錯(cuò)誤
　　HTTP 500-11 服務(wù)器關(guān)閉
　　HTTP 500-12 應(yīng)用程序重新啟動(dòng)
　　HTTP 500-13 - 服務(wù)器太忙
　　HTTP 500-14 - 應(yīng)用程序無(wú)效
　　HTTP 500-15 - 不允許請(qǐng)求 global.asa
　　Error 501 - 未實(shí)現(xiàn)
　　HTTP 502 - 網(wǎng)關(guān)錯(cuò)誤
版本歷史
　　
協(xié)議版本

　　　超文本傳輸協(xié)議已經(jīng)演化出了很多版本，它們中的大部分都是向下兼容的。在RFC 2145中描述了HTTP版本號(hào)的用法?？蛻舳嗽谡?qǐng)求的開始告訴服務(wù)器它采用的協(xié)議版本號(hào)，而后者則在響應(yīng)中采用相同或者更早的協(xié)議版本。
　　
0.9

　　已過時(shí)。只接受 GET 一種請(qǐng)求方法，沒有在通訊中指定版本號(hào)，且不支持請(qǐng)求頭。由于該版本不支持 POST 方法，所以客戶端無(wú)法向服務(wù)器傳遞太多信息。
　　
HTTP/1.0

　　這是第一個(gè)在通訊中指定版本號(hào)的 HTTP 協(xié)議版本，至今仍被廣泛采用，特別是在代理服務(wù)器中。
　　
HTTP/1.1

　　當(dāng)前版本。持久連接被默認(rèn)采用，并能很好地配合代理服務(wù)器工作。還支持以管道方式在同時(shí)發(fā)送多個(gè)請(qǐng)求，以便降低線路負(fù)載，提高傳輸速度。
　　HTTP/1.1相較于 HTTP/1.0 協(xié)議的區(qū)別主要體現(xiàn)在：
　　1 緩存處理
　　2 帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用
　　3 錯(cuò)誤通知的管理
　　4 消息在網(wǎng)絡(luò)中的發(fā)送
　　5 互聯(lián)網(wǎng)地址的維護(hù)
　　6 安全性及完整性