亚洲AV乱码久久精品蜜桃 ,一区国严二区亚洲三区,亚洲五月综合网色九月色

HTTP協(xié)議及其請求頭分析

HTTP協(xié)議及其請求頭分析

眾所周知，Internet的基本協(xié)議是TCP/IP協(xié)議，目前廣泛采用的FTP、Archie Gopher等是建立在TCP/IP協(xié)議之上的應(yīng)用層協(xié)議，不同的協(xié)議對應(yīng)著不同的應(yīng)用。

WWW服務(wù)器使用的主要協(xié)議是HTTP協(xié)議，即超文體傳輸協(xié)議。由于HTTP協(xié)議支持的服務(wù)不限于WWW，還可以是其它服務(wù)，因而HTTP協(xié)議允許用戶在統(tǒng)一的界面下，采用不同的協(xié)議訪問不同的服務(wù)，如FTP、Archie、SMTP、NNTP等。另外，HTTP協(xié)議還可用于名字服務(wù)器和分布式對象管理。

HTTP的早期版本為HTTP/0.9，它適用于各種數(shù)據(jù)信息的簡潔快速協(xié)議，但是其遠(yuǎn)不能滿足日益發(fā)展各種應(yīng)用的需要。但HTTP/0.9作為HTTP 協(xié)議具有典型的無狀態(tài)性：每個事務(wù)都是獨立進(jìn)行處理的，當(dāng)一個事務(wù)開始就在客戶與服務(wù)器之間建立一個連接，當(dāng)事務(wù)結(jié)束時就釋放這個連接。HTTP/0.9 包含Simple-Request&Simple-Responsed的報文結(jié)構(gòu)。但是客戶無法使用內(nèi)容協(xié)商，所以服務(wù)器也無法返回實體的媒體類型。

1982年，Tim Berners-Lee提出了HTTP/1.0，在此后的不斷豐富和發(fā)展中，HTTP/1.0成為最重要的面向事務(wù)的應(yīng)用層協(xié)議。該協(xié)議對每一次請求/響應(yīng)，建立并拆除一次連接。其特點是簡單、易于管理，所以它符合了大家的需要，得到了廣泛的應(yīng)用。其缺點是仍會發(fā)生下列問題：對用戶請求響應(yīng)慢、網(wǎng)絡(luò)擁塞嚴(yán) 重、安全性等。

1997年形成的HTTP/1.1，也就是現(xiàn)在普遍使用的協(xié)議，在持續(xù)連接操作機制中實現(xiàn)流水方式，即客戶端需要對同一服務(wù)器發(fā)出多個請求時，其實現(xiàn) 在多數(shù)的網(wǎng)頁都是有多部分組成（比如多張圖片），可用流水線方式加快速度，流水機制就是指連續(xù)發(fā)出多個請求并等到這些請求發(fā)送完畢，再等待響應(yīng)。這樣就大大節(jié)省了單獨請求對響應(yīng)的等待時間，使我們得到更快速的瀏覽。

另外，HTTP/1.1服務(wù)器端處理請求時按照收到的順序進(jìn)行,這就保證了傳輸?shù)恼_性。當(dāng)然，服務(wù)器端在發(fā)生連接中斷時，會自動的重傳請求，保證數(shù)據(jù)的完整性。

HTTP/1.1還提供了身份認(rèn)證、狀態(tài)管理和Cache緩存等機制。這里，我想特別提一下關(guān)于HTTP/1.1中的Cache緩存機制對HTTP /1.0的不足之處的改進(jìn)，它嚴(yán)格全面，既可以減少時間延遲、又節(jié)省了帶寬。HTTP/1.1采用了內(nèi)容協(xié)商機制，選擇最合適的用戶的內(nèi)容表現(xiàn)形式。

2.1　HTTP協(xié)議簡介

HTTP是一個屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，由于其簡捷、快速的方式，適用于分布式超媒體信息系統(tǒng)。它于1990年提出，經(jīng)過幾年的使用與發(fā)展，得到不斷地完善和擴(kuò)展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規(guī)范化工作正在進(jìn)行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經(jīng)提出。

HTTP協(xié)議的主要特點可概括如下：

1.支持客戶/服務(wù)器模式。
2.簡單快速：客戶向服務(wù)器請求服務(wù)時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。
由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。
3.靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。
4.無連接：無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。
5.無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快。

2.2　HTTP協(xié)議的幾個重要概念

1.連接(Connection)：一個傳輸層的實際環(huán)流，它是建立在兩個相互通訊的應(yīng)用程序之間。
2.消息(Message)：HTTP通訊的基本單位，包括一個結(jié)構(gòu)化的八元組序列并通過連接傳輸。
3.請求(Request)：一個從客戶端到服務(wù)器的請求信息包括應(yīng)用于資源的方法、資源的標(biāo)識符和協(xié)議的版本號
4.響應(yīng)(Response)：一個從服務(wù)器返回的信息包括HTTP協(xié)議的版本號、請求的狀態(tài)(例如"成功"或"沒找到")和文檔的MIME類型。
5.資源(Resource)：由URI標(biāo)識的網(wǎng)絡(luò)數(shù)據(jù)對象或服務(wù)。
6.實體(Entity)：數(shù)據(jù)資源或來自服務(wù)資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應(yīng)信息中。一個實體包括實體頭信息和實體的本身內(nèi)容。
7.客戶機(Client)：一個為發(fā)送請求目的而建立連接的應(yīng)用程序。
8.用戶代理(User agent)：初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它用戶工具。
9.服務(wù)器(Server)：一個接受連接并對請求返回信息的應(yīng)用程序。
10.源服務(wù)器(Origin server)：是一個給定資源可以在其上駐留或被創(chuàng)建的服務(wù)器。
11.代理(Proxy)：一個中間程序，它可以充當(dāng)一個服務(wù)器，也可以充當(dāng)一個客戶機，為其它客戶機建立請求。請求是通過可能的翻譯在內(nèi)部或經(jīng)過傳遞到其它的服務(wù)器中。一個代理在發(fā)送請求信息之前，必須解釋并且如果可能重寫它。
代理經(jīng)常作為通過防火墻的客戶機端的門戶，代理還可以作為一個幫助應(yīng)用來通過協(xié)議處理沒有被用戶代理完成的請求。
12.網(wǎng)關(guān)(Gateway)：一個作為其它服務(wù)器中間媒介的服務(wù)器。與代理不同的是，網(wǎng)關(guān)接受請求就好象對被請求的資源來說它就是源服務(wù)器；發(fā)出請求的客戶機并沒有意識到它在同網(wǎng)關(guān)打交道。
網(wǎng)關(guān)經(jīng)常作為通過防火墻的服務(wù)器端的門戶，網(wǎng)關(guān)還可以作為一個協(xié)議翻譯器以便存取那些存儲在非HTTP系統(tǒng)中的資源。
13.通道(Tunnel)：是作為兩個連接中繼的中介程序。一旦激活，通道便被認(rèn)為不屬于HTTP通訊，盡管通道可能是被一個HTTP請求初始化的。當(dāng)被中繼的連接兩端關(guān)閉時，通道便消失。當(dāng)一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經(jīng)常使用。
14.緩存(Cache)：反應(yīng)信息的局域存儲。

2.3　HTTP協(xié)議的運作方式

HTTP協(xié)議是基于請求／響應(yīng)范式的。一個客戶機與服務(wù)器建立連接后，發(fā)送一個請求給服務(wù)器，請求方式的格式為，統(tǒng)一資源標(biāo)識符、協(xié)議版本號，后邊是 MIME信息包括請求修飾符、客戶機信息和可能的內(nèi)容。服務(wù)器接到請求后，給予相應(yīng)的響應(yīng)信息，其格式為一個狀態(tài)行包括信息的協(xié)議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務(wù)器信息、實體信息和可能的內(nèi)容。

許多HTTP通訊是由一個用戶代理初始化的并且包括一個申請在源服務(wù)器上資源的請求。最簡單的情況可能是在用戶代理(UA)和源服務(wù)器(O)之間通過一個單獨的連接來完成(見圖2-1)。

圖2-1

當(dāng)一個或多個中介出現(xiàn)在請求／響應(yīng)鏈中時，情況就變得復(fù)雜一些。中介由三種：代理(Proxy)、網(wǎng)關(guān)(Gateway)和通道(Tunnel)。一個代理根據(jù)URI(Uniform Resource Identifier)的絕對格式來接受請求，重寫全部或部分消息，通過URI的標(biāo)識把已格式化過的請求發(fā)送到服務(wù)器。網(wǎng)關(guān)是一個接收代理，作為一些其它服務(wù)器的上層，并且如果必須的話，可以把請求翻譯給下層的服務(wù)器協(xié)議。一個通道作為不改變消息的兩個連接之間的中繼點。當(dāng)通訊需要通過一個中介(例如：防火墻等)或者是中介不能識別消息的內(nèi)容時，通道經(jīng)常被使用。

圖2-2

上面的圖2-2表明了在用戶代理(UA)和源服務(wù)器(O)之間有三個中介(A,B和C)。一個通過整個鏈的請求或響應(yīng)消息必須經(jīng)過四個連接段。這個區(qū) 別是重要的，因為一些HTTP通訊選擇可能應(yīng)用于最近的連接、沒有通道的鄰居，應(yīng)用于鏈的終點或應(yīng)用于沿鏈的所有連接。盡管圖2-2是線性的，每個參與者都可能從事多重的、并發(fā)的通訊。例如，B可能從許多客戶機接收請求而不通過A，并且／或者不通過C把請求送到A，在同時它還可能處理A的請求。

任何針對不作為通道的匯聚可能為處理請求啟用一個內(nèi)部緩存。緩存的效果是請求／響應(yīng)鏈被縮短，條件是沿鏈的參與者之一具有一個緩存的響應(yīng)作用于那個請求。下圖說明結(jié)果鏈，其條件是針對一個未被UA或A加緩存的請求，B有一個經(jīng)過C來自O(shè)的一個前期響應(yīng)的緩存拷貝。

圖2-3

在Internet上，HTTP通訊通常發(fā)生在TCP/IP連接之上。缺省端口是TCP 80，但其它的端口也是可用的。但這并不預(yù)示著HTTP協(xié)議在Internet或其它網(wǎng)絡(luò)的其它協(xié)議之上才能完成。HTTP只預(yù)示著一個可靠的傳輸。

以上簡要介紹了HTTP協(xié)議的宏觀運作方式，下面介紹一下HTTP協(xié)議的內(nèi)部操作過程。

首先，簡單介紹基于HTTP協(xié)議的客戶/服務(wù)器模式的信息交換過程，如圖2-4所示，它分四個過程，建立連接、發(fā)送請求信息、發(fā)送響應(yīng)信息、關(guān)閉連接。

圖2-4

在WWW中，"客戶"與"服務(wù)器"是一個相對的概念，只存在于一個特定的連接期間，即在某個連接中的客戶在另一個連接中可能作為服務(wù)器。WWW服務(wù)器運行時，一直在TCP80端口(WWW的缺省端口)監(jiān)聽，等待連接的出現(xiàn)。

下面，討論HTTP協(xié)議下客戶/服務(wù)器模式中信息交換的實現(xiàn)。　　

1.建立連接
連接的建立是通過申請?zhí)捉幼?Socket)實現(xiàn)的。客戶打開一個套接字并把它約束在一個端口上，如果成功，就相當(dāng)于建立了一個虛擬文件。以后就可以在該虛擬文件上寫數(shù)據(jù)并通過網(wǎng)絡(luò)向外傳送。

2.發(fā)送請求
打開一個連接后，客戶機把請求消息送到服務(wù)器的停留端口上，完成提出請求動作。
HTTP/1.0　　請求消息的格式為：
請求消息=請求行(通用信息|請求頭|實體頭) CRLF[實體內(nèi)容]
請求行=方法　請求URL　HTTP版本號　CRLF
方法=GET|HEAD|POST|擴(kuò)展方法
URL=協(xié)議名稱+宿主名+目錄與文件名
請求行中的方法描述指定資源中應(yīng)該執(zhí)行的動作，常用的方法有GET、HEAD和POST。不同的請求對象對應(yīng)GET的結(jié)果是不同的，對應(yīng)關(guān)系如下：
對象　　　　　　GET的結(jié)果
文件　　　　　　文件的內(nèi)容
程序　　　　　　該程序的執(zhí)行結(jié)果
數(shù)據(jù)庫查詢　　　查詢結(jié)果
HEAD--要求服務(wù)器查找某對象的元信息，而不是對象本身。
POST--從客戶機向服務(wù)器傳送數(shù)據(jù)，在要求服務(wù)器和CGI做進(jìn)一步處理時會用到POST方法。POST主要用于發(fā)送HTML文本中FORM的內(nèi)容，讓CGI程序處理。
一個請求的例子為：
GET http://networking.zju.edu.cn/zju/index.htm HTTP/1.0
頭信息又稱為元信息，即信息的信息，利用元信息可以實現(xiàn)有條件的請求或應(yīng)答。
請求頭--告訴服務(wù)器怎樣解釋本次請求，主要包括用戶可以接受的數(shù)據(jù)類型、壓縮方法和語言等。
實體頭--實體信息類型、長度、壓縮方法、最后一次修改時間、數(shù)據(jù)有效期等。
實體--請求或應(yīng)答對象本身。

3.發(fā)送響應(yīng)
服務(wù)器在處理完客戶的請求之后，要向客戶機發(fā)送響應(yīng)消息。
HTTP/1.0的響應(yīng)消息格式如下：
響應(yīng)消息=狀態(tài)行(通用信息頭|響應(yīng)頭|實體頭)　CRLF　〔實體內(nèi)容〕
狀態(tài) 行=HTTP版本號　狀態(tài)碼　原因敘述
狀態(tài)碼表示響應(yīng)類型
1××　　保留
2××　　表示請求成功地接收
3××　　為完成請求客戶需進(jìn)一步細(xì)化請求
4××　　客戶錯誤
5××　　服務(wù)器錯誤
響應(yīng)頭的信息包括：服務(wù)程序名，通知客戶請求的URL需要認(rèn)證，請求的資源何時能使用。

4.關(guān)閉連接
客戶和服務(wù)器雙方都可以通過關(guān)閉套接字來結(jié)束TCP/IP對話

二．http協(xié)議請求頭格式分析

http協(xié)議的請求頭分為10個部分。

1.From:
以internet郵件的形式，這一字段給出了正在請求的用戶的名字。這一字段也許被用來登陸和一種存取保護(hù)的不安全形式。這一字段的解釋是代表被給定用戶的要求正在被執(zhí)行，這個用戶接受被執(zhí)行方法的回應(yīng)。
這一字段里的因特網(wǎng)郵件地址并非一定要對發(fā)出請求的主機回應(yīng).例如，當(dāng)一個請求正通過一個網(wǎng)關(guān)時，開始的發(fā)布者的地址應(yīng)該被使用。
假如能的話，郵件地址應(yīng)該時一個有效的郵件地址而不管它實際上是否是一個internet郵件地址。

2.Accept:
這一字段包含了一個分隔的請求方案列表，它將在這個請求的回應(yīng)中被接受。這一字段可能會根據(jù)RCFC822被包裝成幾行，并且這個字段不僅僅一次的發(fā)生也是被接受的，好像所有的入口已經(jīng)在一個域種了。列表中每個入口的模式如下：
<field> = Accept: <entry> *[ , <entry> ]
<entry> = <content type> *[ ; <param> ]
<param> = <attr> = <float>
<attr> = q / mxs / mxb
<float> = <ANSI-C floating point text represntation>
注意在上述語法中分號的優(yōu)先級高于逗號，這是為了符合多用途的忘記郵件擴(kuò)充協(xié)議。
記入沒有Accept字段出現(xiàn)，那么假定無格式正文和html正文被接受。
Example
Accept: text/plain, text/html
Accept: text/x-dvi; q=.8; mxb=100000; mxt=5.0, text/x-c
為了節(jié)省時間，并且也允許客戶接受他們可能不會意識到的content type一個星號也許被使用在下面的地方，either the second half of the content-type value, or both halves。這僅僅被應(yīng)用于Accept，而且不是對于content-type field of course的。
Example
Accept: *.*, q=0.1
Accept: audio/*, q=0.2
Accept: audio/basic q=1
上面的例子可以這樣解釋：假如你有基本音頻，那么傳送它，否則傳送給我一些其他的聲音，或者不能那樣作，那么僅僅給我你所得到的。
Type parameters
在（content type）中參數(shù)對于描述決議，顏色深度等等是特別重要的。他們將允許一個客戶來在Accept字段中指定它的設(shè)備的決議。這也許允許server在傳輸時通過減少一個圖片的resultion來大大的節(jié)約。并且使一個更適合的用戶時間的黑白圖象被選中而不是給客戶一個彩色圖片來轉(zhuǎn)換成單色的。
These parameters are to be specified when types are registered.. @@ TBS.Sugestions include the following. Please feed back any references to existing improved abbreviations for these:
下面這些參數(shù)是當(dāng)類型被注冊時而被具體詳細(xì)說明的。
Dpi
Dots per inch: pixels per inch [cm?!]
pxmax
Maximum width in pixels (image or video)
pymax
Maximum height in pixels
bits
Bits per sample (sound) or pixels (graphics)
mchrome
Grayscale or black and white (no value)
sps
Samples (sound) or frames (video) per second
Length
Total size of object in bytes [bits?]

3.Accept-Encoding:
和Accept一樣，但是僅列出了在響應(yīng)中是可接受的Content-Encoding types
<field> = Accept-Encoding: <entry> *[ , <entry> ]
<entry> = <content transfer encoding> *[ , <param> ]
Example：
Accept-Encoding: x-compress; x-zip

4。Accept-Language:
和Accept一樣但是列出了在響應(yīng)中更好的Language values。在一個未詳細(xì)說明的語言中一個響應(yīng)不是非法的。

5．User-Agent：
假如存在的話，這一行給出了被原始用戶使用的軟件程序。這是為了統(tǒng)計和protocol violations的追蹤而給出的。第一個白色空格劃定了單詞必須是軟件產(chǎn)品名有一個可選的斜線和版本說明。其他形成了用戶代理的部分產(chǎn)品也許被作為分開的單詞被安排。
<field> = User-Agent: <product>+
<product> = <word> [/<version>]
<version> = <word>
Example:
User-Agent: LII-Cello/1.0 libwww/2.5

6．Referer:
這個可選的header field允許客戶詳細(xì)說明，為了server的好處，文檔的地址或者文檔中的元素，URI通過文檔的地址或者文檔中的元素在請求中被獲得。
這允許一個服務(wù)器來產(chǎn)生向后對文檔的鏈接，它允許壞鏈接為了維護(hù)而被跟蹤。
假如一個部分的URI被給出那么它應(yīng)該被解析到相應(yīng)的請求對象的URI。
Example:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html

7．Authorization:
假如這一行存在的話它包含了授權(quán)信息。格式也是被指定的。這一字段的格式是在可擴(kuò)展的形式。第一個單詞是一個使用中的被授權(quán)的系統(tǒng)的規(guī)范。
Basic
Specification for current one implemented by AL Sep 1993.
PGP/PEM Encryption（pgp/增強的加密電子郵件密碼術(shù)）
People at NCSA are designing a PGP/PEM based protection system.
User/Password scheme
Authorization: user fred:mypassword
設(shè)計名是"user"。第二個單詞是一個用戶名，有一個被冒號分開的可選的密碼，就好像在ftp的URL語法一樣。沒有密碼的話這提供了一個非常低級的安全保證，有了密碼，它提供了一個低級安全保證作為未定義的FTP,Telnet等等。
Koreros
Authorization: kerberos kerberos authentications parameters
Kerberos的確認(rèn)參數(shù)格式被具體指定。

8．ChargeTo:
假如這一行存在地話，它包括了被請求的方法的程序的帳戶信息。格式是TBS
（To Be Specified）這個字段的格式必須是在擴(kuò)展模式的。第一個單詞以一個namespaces的說明開始。這和擴(kuò)展URLㄒ搴芟瘛５鼻懊揮衝amespaces被定義。Namespaces見被隨著注冊確認(rèn)而注冊。
這行的其余部分的格式是一個系統(tǒng)有關(guān)的函數(shù)但是它被推薦這包含了一個被用戶確認(rèn)得本次事務(wù)的最大花費和一個花費單元。
If-Modified-Since: date
這個請求頭被隨著get方法使用使之有條件。假如請求文檔直到被定義還沒改變得花那么文檔不會被發(fā)送，但是會有一個Not Modified 304 回應(yīng)。
這個字段的格式和日期的一樣。

9.Pragma:
語法和其它的http中的多值字段一樣，就像Accept字段，名以上是一個冒號分開的入口列表對他來說可選的參數(shù)是被漢歐摯摹?
Pragma 指示應(yīng)該被服務(wù)器理解，對它來說是相對的，例如，一個代理服務(wù)器當(dāng)前僅僅一個pragma被定義：no-cache
當(dāng)當(dāng)前的代理不應(yīng)該從緩存返回一個文檔時，即使它還沒有被到期，但是它總應(yīng)該從實際存在地服務(wù)器請求文檔。
Pragma應(yīng)該被通過代理實現(xiàn)，甚至他們也許對代理本身有意義。當(dāng)請求不得不通過許多代理時，這在事件中是必須的，而且pragma應(yīng)該隊所有的他們有效。

以下是用jetcar在亦多下載網(wǎng)絡(luò)吸血鬼的信息

Thu Mar 14 14:36:56 2002 正在連接 202.113.29.120 [IP=202.113.29.120:80]
//正在連接主機，解析ip地址
Thu Mar 14 14:36:57 2002 已連接.
Thu Mar 14 14:36:57 2002 GET /index.dhtml?op=download&ino=2941&type=file HTTP/1.1 //請求行，表示用get方式取得文件，并且是HTTP1.1版本
Thu Mar 14 14:36:57 2002 HOST: 202.113.29.120 //主機名
Thu Mar 14 14:36:57 2002 ACCEPT: */* //accept字段，接受的數(shù)據(jù)類型
Thu Mar 14 14:36:57 2002 Referer: http://202.113.29.120//從該網(wǎng)址轉(zhuǎn)發(fā)而來
Thu Mar 14 14:36:57 2002 User-Agent: Mozilla/4.0 (compatible; MSIE 5.00; Windows 98)//客戶端標(biāo)識
Thu Mar 14 14:36:57 2002 Pragma: no-cache //參數(shù)，表示與以前的服務(wù)器兼容
Thu Mar 14 14:36:57 2002 Cache-Control: no-cache //不使用緩存
Thu Mar 14 14:36:57 2002 Connection: close //表示非持續(xù)性連接。
以下為response字段
Thu Mar 14 14:36:58 2002 HTTP/1.1 302 Found
服務(wù)器使用HTTP/1.0協(xié)議，狀態(tài)值（Status Code）為200，狀態(tài)為OK，表示文件可以讀取
Thu Mar 14 14:36:58 2002 Date: Thu, 14 Mar 2002 06:52:16 GMT//現(xiàn)在的時間，用格林威治時間表示
Thu Mar 14 14:36:58 2002 Server: Apache/1.3.19 (Unix) PHP/4.0.4pl1
//服務(wù)器類型
Thu Mar 14 14:36:58 2002 X-Powered-By: PHP/4.0.4pl1
Thu Mar 14 14:36:58 2002 Set-Cookie: PHPSESSID=6cf938f3c6ce551971c787ac8b3c0f5b; path=/
Thu Mar 14 14:36:58 2002 Expires: Thu, 19 Nov 1981 08:52:00 GMT//請求文檔過期時間
Thu Mar 14 14:36:58 2002 Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Thu Mar 14 14:36:58 2002 Pragma: no-cache
Thu Mar 14 14:36:58 2002 Content-Disposition: inline; filename=netvampire33.zip
Thu Mar 14 14:36:58 2002 Location: ftp://202.113.29.120/pub/Dos_Windows/Internet/Client/Download/Net Vampire/3.3/netvampire33.zip
Thu Mar 14 14:36:58 2002 Connection: close
Thu Mar 14 14:36:58 2002 Transfer-Encoding: chunked
Thu Mar 14 14:36:58 2002 Content-Type: text/html

備注：服務(wù)器返回的各類錯誤
當(dāng)服務(wù)器響應(yīng)時，其狀態(tài)行的信息為HTTP的版本號，狀態(tài)碼，及解釋狀態(tài)碼的簡單說明。現(xiàn)將5類狀態(tài)碼詳細(xì)列出：
① 客戶方錯誤
100　繼續(xù)
101　交換協(xié)議
② 成功
200 　OK
201 　已創(chuàng)建
202　接收
203　非認(rèn)證信息
204　無內(nèi)容
205 　重置內(nèi)容
206　部分內(nèi)容
③ 重定向
300 　多路選擇
301　永久轉(zhuǎn)移
302　暫時轉(zhuǎn)移
303　參見其它
304 　未修改（Not Modified）
305　使用代理
④ 客戶方錯誤
400　錯誤請求（Bad Request）
401 　未認(rèn)證
402 　需要付費
403　禁止（Forbidden）
404　未找到（Not Found）
405　方法不允許
406　不接受
407　需要代理認(rèn)證
408　請求超時
409　沖突
410 　失敗
411 　需要長度
412　條件失敗
413 　請求實體太大
414 　請求URI太長
415 　不支持媒體類型
⑤ 服務(wù)器錯誤
500　服務(wù)器內(nèi)部錯誤
501　未實現(xiàn)（Not Implemented）
502　網(wǎng)關(guān)失敗
504 　網(wǎng)關(guān)超時
505 　HTTP版本不支持

posted on 2008-06-23 22:47 lvq810 閱讀(4866) 評論(0) 編輯收藏所屬分類: Html/JavaScript/Ajax

常用鏈接

留言簿(8)

隨筆分類

隨筆檔案

文章分類

文章檔案

搜索

積分與排名

最新評論

閱讀排行榜

評論排行榜


只有注冊用戶登錄后才能發(fā)表評論。




網(wǎng)站導(dǎo)航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關(guān)文章: [轉(zhuǎn)載]有關(guān) JavaScript 的 10 件讓人費解的事情 [轉(zhuǎn)]HTML 5 預(yù)覽 [轉(zhuǎn)]來自Google的密碼強度Javascript驗證代碼圖片幻燈片切換特效手動幻燈圖片效果 JavaScript自動圖片切換 10款讓你震撼的圖片展示js代碼[轉(zhuǎn)] HTTP協(xié)議頭字段及分析 HTTP協(xié)議及其請求頭分析 JavaScript 網(wǎng)頁事件[轉(zhuǎn)]