HTTP模塊方案設(shè)計(jì)

1、超文本協(xié)議模塊方案介紹 HTTP協(xié)議WWW的基礎(chǔ)協(xié)議是HTTP(Hyper Text Transfer Protocol), 它是TCP/IP協(xié)議集中的一個(gè)應(yīng)用層協(xié)議,是基于端對(duì)端連接的TCP協(xié)議. 是一種面向分布,協(xié)作的超媒體信息系統(tǒng)的協(xié)議.它具有通用,無狀態(tài),面向?qū)ο蟮忍攸c(diǎn):l HTTP是一種通用協(xié)議.它所描述的是一種通用的語義和語法結(jié)構(gòu).因此除了用于WWW,還用于用戶代理(User Agent,通常指瀏覽器等)和通向其他Internet系統(tǒng)的服務(wù)代理(Proxy)/網(wǎng)關(guān)(Gateway)間的通訊.后者一般連接其他的Internet協(xié)議模塊,如那些基于SMTP,NNTP,FTP, 

2、;Gopher和WAIS的應(yīng)用系統(tǒng),從而實(shí)現(xiàn)各類Internet應(yīng)用資源超媒體訪問的集成.通過協(xié)議轉(zhuǎn)換,可以對(duì)來自不同應(yīng)用的資源進(jìn)行超媒體訪問,以簡化用戶代理的設(shè)計(jì)和實(shí)現(xiàn).l HTTP是一種無狀態(tài)的協(xié)議.通信雙方(客戶和服務(wù)器)都不必為互相通信而建立起的TCP連接存儲(chǔ)任何狀態(tài)信息,雙方都可以根據(jù)它們之間交換的消息來確定如何響應(yīng).而不必存儲(chǔ)狀態(tài),所以當(dāng)接收到對(duì)方的消息后只要做一個(gè)響應(yīng)便可以不再理它,知道它下一次發(fā)出消息為止,這樣對(duì)與服務(wù)器而言,可以很容易為多個(gè)客戶服務(wù).l 作為一個(gè)通用的面向?qū)ο蟮膮f(xié)議,在HTTP中,資源對(duì)資源操作的方法是一起發(fā)送的.通過其請(qǐng)求/應(yīng)答方法(命令),為許多系統(tǒng)如DN

3、S服務(wù)器,分布式對(duì)象管理系統(tǒng)所采用.以其簡便快速而成為超媒體信息系統(tǒng)的基本協(xié)議.l 靈活性與內(nèi)容-類型(content-type)標(biāo)識(shí) HTTP允許任意類型數(shù)據(jù)的傳送，因此可以利用HTTP傳送任何類型的對(duì)象，并讓客戶程序能夠恰當(dāng)?shù)靥幚硭鼈?，?nèi)容-類型標(biāo)識(shí)指示了所傳輸數(shù)據(jù)的類型。打個(gè)比方，如果數(shù)據(jù)是罐頭，內(nèi)容-類型標(biāo)識(shí)就是罐頭上的標(biāo)簽。 HTTP協(xié)議的發(fā)展歷史HTTP作為WWW的支撐協(xié)議始于1990年,最早的HTTP/0.9只是一個(gè)簡單的原始數(shù)據(jù)傳輸協(xié)議.經(jīng)過幾年的使用與發(fā)展,如今的WWW中廣泛采用的是HTTP/1.0,即RFC1945.它通過引入類MIME(Multipurpose Inter

4、net Mail Extensions)格式消息,數(shù)據(jù)的元信息表示以及請(qǐng)求/響應(yīng)語義修師符等改進(jìn)了HTTP/0.9,但它不能對(duì)超媒體信息傳輸所需要的層次代理,緩沖,持續(xù)連接和虛擬主機(jī)提供足夠的支持.為此Internet工程部IETF在1996年6月提交了新版的HTTP/1.1草案,它在HTTP/1.0的基礎(chǔ)上增加了對(duì)層次代理,緩沖,持續(xù)連接和虛擬逐級(jí)的充分支持.以下講解均以HTTP/1.1規(guī)范作為基礎(chǔ). RFC 2616 (HTTP1.1協(xié)議)的內(nèi)容目前在Web中采用的HTTP協(xié)議的1.1版,即 RFC2616,它對(duì)HTTP協(xié)議的內(nèi)容進(jìn)行了詳細(xì)規(guī)范的描述,其基本內(nèi)容包括:(1) 一般語法和標(biāo)識(shí)

5、符約定.其語法使用BNF(RFC822中的擴(kuò)展巴科斯范式(Augmented Backus-Naur Form,BNF)描述.(2) 協(xié)議參數(shù).包括協(xié)議的版本號(hào),URI,字符集,編碼方式以及媒體類型等.這些參數(shù)主要設(shè)在HTTP的請(qǐng)求/應(yīng)答格式的各種頭標(biāo)域中.(3) HTTP消息.包括HTTP請(qǐng)求和應(yīng)答,每種又分為簡單式和完整式.協(xié)議對(duì)請(qǐng)求/應(yīng)答的格式以及各域的相關(guān)內(nèi)容,進(jìn)行了詳細(xì)的說明.這部分是協(xié)議的主要內(nèi)容.(4) 訪問權(quán)限.目前一般僅支持Basic訪問方案,即用戶名/用戶口令方式.(5) 安全考慮.HTTP協(xié)議的工作模式HTTP協(xié)議的實(shí)現(xiàn)基于請(qǐng)求/應(yīng)答模式.它是一種請(qǐng)求/響應(yīng)協(xié)議.其基本運(yùn)

6、作方式見下圖. 建立TCP/IP連接客戶->服務(wù)器 發(fā)送請(qǐng)求消息客戶->服務(wù)器 發(fā)送響應(yīng)消息客戶<-服務(wù)器 關(guān)閉連接客戶<-服務(wù)器 圖1: HTTP的基本運(yùn)作過程一個(gè)客戶首先于服務(wù)器建立一個(gè)連接,并向服務(wù)器發(fā)送請(qǐng)求服務(wù)的消息,服務(wù)器收到請(qǐng)求消息后進(jìn)行相應(yīng)操作,然后發(fā)出一個(gè)響應(yīng)消息給客戶,最后關(guān)閉連接.其中客戶與服務(wù)器是一個(gè)相對(duì)的概念,只存在于某個(gè)特定的連接期間,即在某個(gè)連接中的客戶在另一個(gè)連接中可能作為服務(wù)器,這也就是說,對(duì)于HTTP中的程序它應(yīng)具有客戶與服務(wù)器的雙重功能.HTTP的服務(wù)器還可以使其他類型的網(wǎng)關(guān)或服務(wù)代理,通過它們HTTP允許超媒體訪問現(xiàn)存的Intern

7、et協(xié)議,如SMTP,NNTP,FTP,Gopher,WAIS等.在Internet上的通訊一般是建立在TCP/IP連接上的,HTTP的連接也不例外,其缺省端口是TCP 80端口,當(dāng)然其他端口也可以使用.正常的握手過程要求客戶在每一次發(fā)送請(qǐng)求之前建立連接,并由服務(wù)器在發(fā)送響應(yīng)消息后關(guān)閉,但客戶和服務(wù)器還必須具有處理任意一方因突發(fā)事件(如用戶強(qiáng)制,自動(dòng)超時(shí)或程序失敗等)而發(fā)生關(guān)閉連接的能力.在這些情況下,通常不論當(dāng)前狀態(tài)怎樣都中止當(dāng)前請(qǐng)求.圖1只是HTTP正常的運(yùn)作過程,對(duì)突發(fā)情況并沒有體現(xiàn).從圖1我們可以看出,當(dāng)客戶和服務(wù)器的一次請(qǐng)求/響應(yīng)完成后,將斷開它們之間的連接.在WWW服務(wù)中,經(jīng)常會(huì)碰

8、到這樣的情況:常常要求客戶程序在一段較短時(shí)間內(nèi)向同一服務(wù)器發(fā)送多個(gè)請(qǐng)求,如WWW頁面中有內(nèi)插圖表(Inline Image)時(shí).然而,在持續(xù)連接出現(xiàn)之前,每取回一個(gè)URL都需要重新建立一個(gè)獨(dú)立的TCP連接,很顯然,這樣增加了HTTP服務(wù)器一端的開銷,并且可能導(dǎo)致網(wǎng)絡(luò)阻塞.為了解決這個(gè)問題,HTTP/1.1提供了持續(xù)連接功能,持續(xù)連接的好處有:l 減少了TCP連接建立和關(guān)閉的次數(shù),從而節(jié)約了CPU時(shí)間和TCP協(xié)議控制塊消耗的內(nèi)存.l 減少了TCP連接建立時(shí)所發(fā)送的報(bào)文數(shù),并給TCP控制進(jìn)程足夠的時(shí)間已確定網(wǎng)絡(luò)的阻塞狀態(tài),從而減少了整個(gè)網(wǎng)絡(luò)阻塞的發(fā)生次數(shù).l 在一個(gè)TCP連接之上就可以實(shí)現(xiàn)HTTP

9、請(qǐng)求和相應(yīng)的流水作業(yè),這意味著程序可以不必等待響應(yīng)就可以連續(xù)發(fā)出多個(gè)請(qǐng)求,減少了系統(tǒng)延遲,提高了單個(gè)TCP連接的使用效率.l 沒有關(guān)閉TCP連接的負(fù)擔(dān)就可以報(bào)告差錯(cuò),從而促進(jìn)HTTP平穩(wěn)地發(fā)展.未來版本的HTTP客戶可能為了優(yōu)化而采用新的協(xié)議特性,如果這些客戶和舊版本的服務(wù)器通信并收到差錯(cuò)報(bào)告,由于有了持續(xù)性連接,就可以在不關(guān)閉連接的情況下,采用舊的語義和語法規(guī)范重試. 客戶與服務(wù)器建立連接后向服務(wù)器發(fā)出一個(gè)請(qǐng)求,其請(qǐng)求具有一定的格式.一個(gè)請(qǐng)求一般包括這些內(nèi)容:請(qǐng)求方法,請(qǐng)求資源的 URI和協(xié)議的版本號(hào)的請(qǐng)求行;有關(guān)請(qǐng)求的其他信息和客戶本身的信息;實(shí)體頭和可能的實(shí)體內(nèi)容.服務(wù)器應(yīng)答客戶端發(fā)來的

10、請(qǐng)求,其應(yīng)答也具有一定的格式.一個(gè)應(yīng)答一般包括這樣的一些內(nèi)容:HTTP協(xié)議版本號(hào),狀態(tài)代碼和狀態(tài)說明的狀態(tài)行;服務(wù)器信息和進(jìn)一步訪問資源的URI以及WWW權(quán)限識(shí)別;實(shí)體頭和可能的實(shí)體內(nèi)容.決大多數(shù)HTTP通訊是從客戶代理(通常為客戶瀏覽器)發(fā)出對(duì)某資源的請(qǐng)求開始的,在最簡單的情況下,這只需在客戶代理和源服務(wù)器(存放請(qǐng)求資源的服務(wù)器)間建立一條連接即可.當(dāng)請(qǐng)求/應(yīng)答鏈路中有中介系統(tǒng)時(shí),情況會(huì)復(fù)雜一些.一般由三種形式中介系統(tǒng),即代理Proxy,網(wǎng)關(guān)Gataway和通道Tunnel.Proxy是客戶端轉(zhuǎn)發(fā)代理(既是服務(wù)器又是客戶).它接受客戶端的請(qǐng)求,必要時(shí)重寫部分或全部請(qǐng)求信息,然后將重新格式化的

11、請(qǐng)求轉(zhuǎn)發(fā)給請(qǐng)求所指的服務(wù)器.Gataway是源服務(wù)器的接受代理(是服務(wù)器).作為其他源服務(wù)器的上一層,在必要時(shí),轉(zhuǎn)換客戶端的請(qǐng)求,以適應(yīng)下層源服務(wù)器所采用的協(xié)議(一般為非HTTP協(xié)議,如FTP,Gopher等).Tunnel作為連接鏈路中的中繼接點(diǎn),它不改變消息內(nèi)容.當(dāng)連接鏈路要通過一中介(如防火墻.該中介可以不理解傳送消息的內(nèi)容)時(shí),Tunnel才被使用.HTTP消息兩種分類HTTP消息包括客戶端請(qǐng)求消息和服務(wù)器應(yīng)答消息:HTTP-message=Request|Response這兩種類型的消息都由一個(gè)起始行,一個(gè)或多個(gè)頭標(biāo)域,一個(gè)空行(表示頭標(biāo)域結(jié)束)和一個(gè)可選的消息凈荷組成:消息頭標(biāo):H

12、TTP消息頭標(biāo)包括通用頭標(biāo),請(qǐng)求頭標(biāo),響應(yīng)頭標(biāo)和實(shí)體頭標(biāo)等類型.每個(gè)頭標(biāo)字段由一個(gè)字段,加上冒號(hào),而后跟一個(gè)值組成.一個(gè)消息的不同頭標(biāo)的接收順序并不重要,然而,一般情況下最好按下列順序發(fā)送:通用頭標(biāo),請(qǐng)求頭標(biāo),響應(yīng)頭標(biāo)和實(shí)體頭標(biāo).消息體:一個(gè)消息的消息體是用于運(yùn)載請(qǐng)求或響應(yīng)消息的實(shí)體內(nèi)容.實(shí)體是請(qǐng)求或響應(yīng)消息攜帶的數(shù)據(jù),它包括實(shí)體頭標(biāo)和實(shí)體內(nèi)容.消息體于實(shí)體內(nèi)容的區(qū)別在于,消息體不僅包括實(shí)體內(nèi)容,而且還包括經(jīng)過傳輸編碼處理的實(shí)體內(nèi)容.generic_message=start_line *message_header CRLF message_body start_line=Request_l

13、ine|Status_line這里的*message_header表示形式符,message_header可以出現(xiàn)若干次(可以為0次).方括號(hào)表示可選;CRLF表示回車,換行符.HTTP的請(qǐng)求消息的擴(kuò)展BNF表示如下:Request=Request_line *(general_header |request_header |entity_header CRLF message_body例如:_GET /test/mh-email.asp HTTP/1.0Referer: Connection: Keep-AliveUser-Agent: Mozilla/4.51 en (Win95; I)H

14、ost: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*Accept-Encoding: gzipAccept-Language: enAccept-Charset: iso-8859-1,*,utf-8Cookie: ASPSESSIONIDQGQGQQAD=AIHJBHPBNDLGGKPBPOGKDHOB _ 請(qǐng)求行有一個(gè)操作字段(token)開始,接著是Request-URI和協(xié)議版本號(hào),最后以CRLF結(jié)尾.個(gè)項(xiàng)內(nèi)容之間用空格分開,除了最后的CRLF外,Request-URI

15、中其他地方不能出現(xiàn)CR和LF: Request_line=Method Request_URI HTTP_VersionCRLF Method ="OPTIONS" ; Section 9.2 | "GET" ; Section 9.3 | "HEAD" ; Section 9.4 | "POST" ; Section 9.5 | "PUT" ; Section 9.6 | "DELETE" ; Section 9.7 | "TRACE" ; Sectio

16、n 9.8 | "CONNECT" ; Section 9.9 | extension-methodHTTP應(yīng)答消息的擴(kuò)展BNF表示如下:Response=Status_line *(general_header) |response_header |entity_header) CRLF message_body例如:_/1HTTP/1.1 200 OKServer: Microsoft-IIS/4.0Connection: keep-aliveDate: Wed, 12 May 1999 09:14:17 GMTContent-Type: image/gifAccept

17、-Ranges: bytesLast-Modified: Wed, 24 Jun 1998 02:58:00 GMTETag: "0ec86e51b9fbd1:10c0"Content-Length: 5357 (blank line)GIF89a?薜蘄蕙汁?鼢 /GIF圖片余下部分省略_ 應(yīng)答消息的頭一行是狀態(tài)行,其定義如下: Status_line=HTTP_Version Status_Code Reason_PhraseCRLF其中的狀態(tài)代碼Status_Code是一個(gè)3位數(shù)字的結(jié)果代碼:原因短語Reason_Phrase是對(duì)狀態(tài)代碼的簡短文字陳述.狀態(tài)碼供協(xié)議自動(dòng)

18、機(jī)使用,而原因短語是為用戶使用的.有時(shí)我們可以在瀏覽器的服務(wù)器返回狀態(tài)中看到狀態(tài)代碼.狀態(tài)代碼的第一個(gè)數(shù)字定一個(gè)應(yīng)答的類別,其余的兩位數(shù)字只起編號(hào)作用.一共有5種應(yīng)答類別:1xx:Informational 提示,收到并接受請(qǐng)求,繼續(xù)請(qǐng)求其他部分;2xx:Success - 請(qǐng)求成功,操作指令被成功的接收到,理解和接受; 3xx:Redirection - 請(qǐng)求未完成,為了完成請(qǐng)求,必須采取進(jìn)一步的操作;4xx:ClientError - 客戶錯(cuò),請(qǐng)求語法錯(cuò)或無法完成;5xx:ServerError - 服務(wù)器錯(cuò),服務(wù)器無法完成有效的請(qǐng)求. HTTP狀態(tài)碼列表 Status-Code = &q

19、uot;100" ; Section 10.1.1: Continue | "101" ; Section 10.1.2: Switching Protocols | "200" ; Section 10.2.1: OK | "201" ; Section 10.2.2: Created | "202" ; Section 10.2.3: Accepted | "203" ; Section 10.2.4: Non-Authoritative Information | "2

20、04" ; Section 10.2.5: No Content | "205" ; Section 10.2.6: Reset Content | "206" ; Section 10.2.7: Partial Content | "300" ; Section 10.3.1: Multiple Choices | "301" ; Section 10.3.2: Moved Permanently | "302" ; Section 10.3.3: Found | "303

21、" ; Section 10.3.4: See Other | "304" ; Section 10.3.5: Not Modified | "305" ; Section 10.3.6: Use Proxy | "307" ; Section 10.3.8: Temporary Redirect | "400" ; Section 10.4.1: Bad Request | "401" ; Section 10.4.2: Unauthorized | "402"

22、; Section 10.4.3: Payment Required | "403" ; Section 10.4.4: Forbidden | "404" ; Section 10.4.5: Not Found | "405" ; Section 10.4.6: Method Not Allowed | "406" ; Section 10.4.7: Not Acceptable | "407" ; Section 10.4.8: Proxy Authentication Required |

23、 "408" ; Section 10.4.9: Request Time-out | "409" ; Section 10.4.10: Conflict | "410" ; Section 10.4.11: Gone | "411" ; Section 10.4.12: Length Required | "412" ; Section 10.4.13: Precondition Failed | "413" ; Section 10.4.14: Request Entit

24、y Too Large | "414" ; Section 10.4.15: Request-URI Too Large | "415" ; Section 10.4.16: Unsupported Media Type | "416" ; Section 10.4.17: Requested range not satisfiable | "417" ; Section 10.4.18: Expectation Failed | "500" ; Section 10.5.1: Internal

25、 Server Error | "501" ; Section 10.5.2: Not Implemented | "502" ; Section 10.5.3: Bad Gateway | "503" ; Section 10.5.4: Service Unavailable | "504" ; Section 10.5.5: Gateway Time-out | "505" ; Section 10.5.6: HTTP Version not supported | extension-co

26、deHTTP的操作(全部共7種)1. OPTIONSOPTIONS操作說明了由Request-URI所標(biāo)識(shí)的HTTP請(qǐng)求/應(yīng)答鏈上有關(guān)通訊功能選項(xiàng).客戶使用該操作可以在對(duì)不同實(shí)體操作或傳送實(shí)體的情況下獲得某個(gè)實(shí)體的操作要求,功能選項(xiàng),服務(wù)器的能力.對(duì)OPTIONS的應(yīng)答是不能被緩存的.2. GETGET操作表示以實(shí)體的形式取回由Request-URI所標(biāo)識(shí)的任何信息.如果Request-URI指向一個(gè)數(shù)據(jù)處理進(jìn)程,那么該進(jìn)程運(yùn)行結(jié)果將作為應(yīng)答消息包中的實(shí)體而返回.如果請(qǐng)求消息帶有 If-Modified-Since,If-Unmodified-Since,If-Match,If-None-Ma

27、tch或If-Range頭標(biāo)域,則GET就變成”條件GET”;如果請(qǐng)求消息中含有Range頭標(biāo)域,這相當(dāng)于一個(gè)”部分GET”.部分 GET只要求傳送實(shí)體的一部分內(nèi)容,這樣就不必傳送客戶已擁有的數(shù)據(jù),從而減輕網(wǎng)絡(luò)負(fù)載.3. HEADHEAD操作和GET語義基本相同,但是HEAD規(guī)定應(yīng)答消息包中不能含有消息凈荷.使用該操作可以在不傳送實(shí)體凈荷的情況下獲取實(shí)體的元信息,因此它經(jīng)常被用來測(cè)試超文本鏈的有效性,可訪問性和最近修改狀態(tài).4. POSTPOST操作用于請(qǐng)求目的服務(wù)器接收請(qǐng)求消息包中的實(shí)體,作為Request-URI所標(biāo)識(shí)資源的一個(gè)新的從屬.有了POST,可以在實(shí)體應(yīng)用中完成如下的功能:.注解

28、已存在的資源.向BBS,新聞組或郵件列表張貼消息.向數(shù)據(jù)處理進(jìn)程提供一組數(shù)據(jù),如表格(form)提交結(jié)果.實(shí)現(xiàn)數(shù)據(jù)庫的添加操作.(POST:用于客戶向服務(wù)器傳送數(shù)據(jù),以便服務(wù)器作出相應(yīng)的處理。POST方法經(jīng)常用于向HTTP服務(wù)器提交HTML表格以便處理.例如,網(wǎng)上的聯(lián)機(jī)就業(yè)服務(wù)中就是靠提交簡歷表格來找工作.當(dāng)你填寫了一份WWW頁面表格后,瀏覽器通常就使用POST方法向服務(wù)器提交你輸入的數(shù)據(jù).)5. PUTPUT操作請(qǐng)求把攜帶的實(shí)體存放于Request-URI處,請(qǐng)注意它和POST的區(qū)別.如果Request-URI指向一個(gè)已經(jīng)存在的資源,請(qǐng)求消息包中攜帶的實(shí)體將作為起始服務(wù)其上原資源的一個(gè)更新版

29、本;如果Request-URI所指向的資源不存在,而且該URI能被請(qǐng)求用戶進(jìn)程定義為一個(gè)新資源,那么服務(wù)器將用該URI創(chuàng)建一個(gè)新資源.POST操作和PUT操作的最根本的差別反映在Request-URI的含義中POST的URI標(biāo)識(shí)了將對(duì)被攜帶實(shí)體進(jìn)行處理的某個(gè)資源,該資源可能是一個(gè)數(shù)據(jù)處理進(jìn)程,一個(gè)多協(xié)議網(wǎng)關(guān)或者一個(gè)接收注解信息的獨(dú)立實(shí)體.而PUT請(qǐng)求中的URI標(biāo)識(shí)了該請(qǐng)求所攜帶的實(shí)體本身,只有客戶知道URI的確切含義,服務(wù)器絕不對(duì)其他資源實(shí)施被請(qǐng)求的操作.6. DELETEDELETE操作請(qǐng)求服務(wù)器刪除由Request-URI標(biāo)識(shí)的資源.不過DELETE操作可能受到服務(wù)器一端認(rèn)為干預(yù)而不予執(zhí)行

30、,所以即使從服務(wù)器返回的狀態(tài)代碼表明刪除成功完成,客戶也不能據(jù)此確認(rèn)真正執(zhí)行了刪除.7. TRACETRACE操作用于引發(fā)請(qǐng)求消息包的遠(yuǎn)程應(yīng)用自環(huán)測(cè)試.如果成功,請(qǐng)求消息的最后一個(gè)接收者應(yīng)該把整個(gè)請(qǐng)求消息包作為相應(yīng)消息的實(shí)體內(nèi)容部分發(fā)送還給客戶端.TRACE是客戶可以了解到請(qǐng)求/響應(yīng)鏈另一端數(shù)據(jù)接收的情況,并把接收的數(shù)據(jù)作為測(cè)試或診斷信息送回.HTTP的協(xié)議參數(shù)1. URI(Uniform Resource Identifiers)統(tǒng)一資源標(biāo)識(shí)符URI是一種格式化字符串,可以用名字,地點(diǎn)或其他特征標(biāo)識(shí)某個(gè)資源,因此URI有許多別名,如WWW地址,Universal Document Ideni

31、fiers(全局文檔標(biāo)識(shí)符),Uniform Resourct Names(統(tǒng)一資源名),以及大家很熟悉的統(tǒng)一資源定位器Uniform Resource Locators.2. 實(shí)體標(biāo)記(Entity Tags)實(shí)體標(biāo)記用于區(qū)分同一個(gè)被請(qǐng)求資源的不同實(shí)體.頭標(biāo)域 Etag,If-Match,If-None-Match和If-Range中使用了實(shí)體標(biāo)記.3. 實(shí)體域單元(Entity-Range Unit)HTTP/1.1允許客戶端請(qǐng)求服務(wù)器發(fā)送的應(yīng)答消息中只包含原應(yīng)答實(shí)體的一部分(實(shí)體域).頭標(biāo)域Range和Content-Range中用到了該協(xié)議參數(shù).在當(dāng)前版本中,HhHHTTP/1.1定義

32、實(shí)體域單元為一個(gè)字節(jié).HTTP的頭標(biāo)域?qū)?shí)體頭標(biāo)域來說,術(shù)語發(fā)送方sender和接收recipient可能指客戶或者服務(wù)器任何一方,這取決于發(fā)送或接收實(shí)體的當(dāng)前實(shí)際行為.同樣實(shí)體頭標(biāo)域即可用于請(qǐng)求消息,也可用于應(yīng)答消息,但是不能用于被傳輸?shù)膶?shí)體.所以下面的通用頭標(biāo)域只能用于消息本身.消息中被表示的頭標(biāo)域可以認(rèn)為是實(shí)體頭標(biāo)域.HTTP/1.1頭標(biāo)域的語法如下:genner_header=cache_control |Connection |Date |Program |Transfer_Encoding |Upgrade |Via主要的頭標(biāo)域包括Content_Base,Content_Leng

33、th,Content_Location,Content_Range,Content_Type,Date,Etag,Host,If_modified_Since,If_Range,Last_modified,Location,Pragma,Proxy_authenticate,Range等.頭標(biāo)域列表RFC#2616 14章 Header Field Definitions general-header = Cache-Control ; Section 14.9 | Connection ; Section 14.10 | Date ; Section 14.18 | Pragma ; Sec

34、tion 14.32 | Trailer ; Section 14.40 | Transfer-Encoding ; Section 14.41 | Upgrade ; Section 14.42 | Via ; Section 14.45 | Warning ; Section 14.46 request-header = Accept ; Section 14.1 | Accept-Charset ; Section 14.2 | Accept-Encoding ; Section 14.3 | Accept-Language ; Section 14.4 | Authorization

35、; Section 14.8 | Expect ; Section 14.20 | From ; Section 14.22 | Host ; Section 14.23 | If-Match ; Section 14.24 | If-Modified-Since ; Section 14.25 | If-None-Match ; Section 14.26 | If-Range ; Section 14.27 | If-Unmodified-Since ; Section 14.28 | Max-Forwards ; Section 14.31 | Proxy-Authorization ;

36、 Section 14.34 | Range ; Section 14.35 | Referer ; Section 14.36 | TE ; Section 14.39 | User-Agent ; Section 14.43 response-header = Accept-Ranges ; Section 14.5 | Age ; Section 14.6 | ETag ; Section 14.19 | Location ; Section 14.30 | Proxy-Authenticate ; Section 14.33 | Retry-After ; Section 14.37

37、| Server ; Section 14.38 | Vary ; Section 14.44 | WWW-Authenticate ; Section 14.47 entity-header = Allow ; Section 14.7 | Content-Encoding ; Section 14.11 | Content-Language ; Section 14.12 | Content-Length ; Section 14.13 | Content-Location ; Section 14.14 | Content-MD5 ; Section 14.15 | Content-Ra

38、nge ; Section 14.16 | Content-Type ; Section 14.17 | Expires ; Section 14.21 | Last-Modified ; Section 14.29 | extension-header extension-header = message-header快速理解HTTP協(xié)議HTTP協(xié)議使Web服務(wù)器和瀏覽器可以通過Web交換數(shù)據(jù).它是一種請(qǐng)求/響應(yīng)協(xié)議,即服務(wù)器等待并響應(yīng)客戶請(qǐng)求.HTTP不維護(hù)與客戶方的連接,它使用可靠的TCP連結(jié),通常采用TCP 80端口. Web服務(wù)器運(yùn)行著一個(gè)守護(hù)進(jìn)程(HTTPDaemon),它始終在端

39、口80監(jiān)聽著來自遠(yuǎn)端客戶的請(qǐng)求.當(dāng)一個(gè)請(qǐng)求發(fā)來時(shí),它就會(huì)產(chǎn)生一個(gè)子進(jìn)程來處理當(dāng)前請(qǐng)求,守護(hù)進(jìn)程繼續(xù)以后臺(tái)方式運(yùn)行,在端口80繼續(xù)監(jiān)聽來自遠(yuǎn)端的連接請(qǐng)求.客戶/服務(wù)器傳輸過程可以分為四個(gè)基本步驟:1)瀏覽器與服務(wù)器建立連接;2)瀏覽器向服務(wù)器請(qǐng)求文檔;3)服務(wù)器響應(yīng)瀏覽器請(qǐng)求;4)斷開連接.HTTP是一種無狀態(tài)協(xié)議,它不維護(hù)連接的狀態(tài)信息.(注:最新RFC中有關(guān)HTTP協(xié)議概述RFC2616可在/Protocols/中找到)每個(gè)資源都有其特定的URL標(biāo)識(shí),經(jīng)由各種不同的協(xié)議,對(duì)Internet上任何地方的信息都可以用URL定位或取回.URL可以指定FTP文件傳輸

40、,尋找新聞信息,定義用戶的Email地址,標(biāo)識(shí)HTTP文件和其他類型數(shù)據(jù).URL中的字符不區(qū)分大小寫.為了使客戶端和服務(wù)器通信成為可能,HTTP協(xié)議建立了一種由請(qǐng)求和響應(yīng)消息組成的Web語言.1) 客戶請(qǐng)求客戶請(qǐng)求包括如下信息:l 請(qǐng)求方法l 請(qǐng)求頭l 請(qǐng)求數(shù)據(jù)請(qǐng)求方法是用于特定URL或Web頁面的程序.表 快速理解-表1列出了可用的請(qǐng)求方法. 表1 HTTP請(qǐng)求方法=- 請(qǐng)求操作方法(共7種)描述=- (1) GET 請(qǐng)求指定文檔 (2) HEAD 僅請(qǐng)求文檔頭 (3) POST 請(qǐng)求服務(wù)器接收指定文當(dāng)作為可執(zhí)行的信息 (4) PUT 用從客戶端傳送的數(shù)據(jù)取代指定文檔中的內(nèi)容 (5) DELETE 請(qǐng)求服務(wù)器刪除指