［主標題］DATE\@"yyyy"2016 引言編寫目的為了以后更方便的回顧http協(xié)議的知識，加深記憶背景http協(xié)議1.1時間2016.9.5-2016.9.6方法定義連接（Connection）消息(Message)請求(Request)應(yīng)答(Response)資源(Resource)實體(Entity)表示方法(Representation)內(nèi)容協(xié)商(ContentNegotiation)變量（Variant)客戶機（Client）用戶代理(Useragent)服務(wù)器(Server)原服務(wù)器（Originserver)代理服務(wù)器（Proxy）網(wǎng)關(guān)（gateway）高速緩存（Cache）可緩存（Cacheable）直接（first-hand）明確終止時間（explicitexpirationtime）

探索終止時間（heuristicexpirationtime）

年齡（Age）保鮮壽命（Freshnesslifetime）保鮮（Fresh）

陳舊（Stale語義透明（semanticallytransparent）有效性判別器（Validator）上游/下游（upstream/downstream）向內(nèi)/向外（inbound/outbound）參考資料/cxd4321/p/3504632.html主題摘要超文本傳輸協(xié)議（HTTP）是一種為分布式，合作式，多媒體信息系統(tǒng)服務(wù)，面向應(yīng)用層的協(xié)議。它是一種通用的，不分狀態(tài)（stateless)的協(xié)議，除了諸如名稱服務(wù)和分布對象管理系統(tǒng)之類的超文本用途外，還可以通過擴展它的請求方式，錯誤代碼和報頭來完成許多任務(wù)。HTTP的一個特點是數(shù)據(jù)表示方式的典型性和可協(xié)商性允許獨立于傳輸數(shù)據(jù)而建立系統(tǒng)。在1990年WWW全球信息剛剛起步的時候HTTP就得到了應(yīng)用。HTTP的第一個版本叫做HTTP/0.9,是一種為互聯(lián)網(wǎng)原始數(shù)據(jù)傳輸服務(wù)的簡單協(xié)議。由RFC1945定義的HTTP/1.0進一步完善了這個協(xié)議。它允許消息以類似MIME的格式傳送，包括有關(guān)數(shù)據(jù)傳輸?shù)木S護信息和關(guān)于請求/應(yīng)答的句法修正。但是，HTTP/1.0沒有充分考慮到分層代理，高速緩存的作用以及對穩(wěn)定連接和虛擬主機的需求。并且隨著不完善的進程應(yīng)用的激增，HTTP/1.0迫切需要一個新的版本,以便使兩個通信應(yīng)用程序能夠確定彼此的真實性能。這里規(guī)定的協(xié)議叫做“HTTP/1.1".這個協(xié)議與HTTP/1.0相比，要求更為嚴格，以確保各項功能得到可靠實現(xiàn)。實際的信息系統(tǒng)除了簡單的檢索外，要求更多的功能性（functionality)，包括查找(search)，前端更新(front-endupdate)和注解(annotation)。HTTP允許可擴充的方法集和報頭集以指示請求的目的[47]。它是建立在統(tǒng)一資源標識符（URI）[3]提供的地址（URL）[4]和名字（URN）上[20]，以指出方法應(yīng)用于哪個資源的。消息以類似于一種叫做多用途網(wǎng)絡(luò)郵件擴展（MIME）[7]的互聯(lián)網(wǎng)郵件的格式傳送。HTTP也是用于用戶代理之間及代理/網(wǎng)關(guān)到其他網(wǎng)絡(luò)系統(tǒng)的通用通信協(xié)議，這樣的網(wǎng)絡(luò)系統(tǒng)可能由SMTP,NNTP,FTP,Gopher和WAIS協(xié)議支持。這樣，HTTP允許不同的應(yīng)用程序?qū)Y源進行基本的超媒體訪問?？傮w操作HTTP協(xié)議是一種請求/應(yīng)答協(xié)議。與主機建立連接后，客戶以請求方法，URI和協(xié)議版本的形式向服務(wù)器發(fā)送請求，繼以類MIME信息，其中包括請求修改，客戶信息和可能的正文內(nèi)容。大部分的HTTP通信由用戶代理引發(fā)，由應(yīng)用到一些原服務(wù)器上資源的請求構(gòu)成。最簡單的情形，可以經(jīng)用戶代理（UA）和原服務(wù)器（O）之間的單一連接（v）完成。請求鏈>用戶代理(UA)單一連接（v)原服務(wù)器（O）<應(yīng)答鏈當一個或一個以上的中介在請求/應(yīng)答鏈中出現(xiàn)的時候，會出現(xiàn)更復(fù)雜的情形。常見的中介形式有三種：代理，網(wǎng)關(guān)和隧道。代理是一種轉(zhuǎn)送工具，它接收絕對形式的URI請求，重寫全部或部分消息，然后把重新格式化后的請求發(fā)送到URI確定的服務(wù)器上。網(wǎng)關(guān)是一種接收工具，它充當其他服務(wù)器的上層，必要時將請求翻譯為下層服務(wù)器的協(xié)議。隧道不改變消息而充當兩個連接之間的中繼點；它用于通信需要穿過中介（如防火墻），甚至中介不能理解信息內(nèi)容的時候。請求鏈>UAvAvBvCvO<應(yīng)答鏈上圖顯示了用戶代理和原服務(wù)器之間的三個中介（A，B和C)。游歷整條鏈的請求或應(yīng)答消息需通過四個獨立的連接。這個特性很重要，因為某些HTTP通信選項只能應(yīng)用于到最近的非隧道鄰居，鏈的終點的連接，或者沿著鏈的所有連接。圖表盡管是線性的，每部分可能都在忙于多路同時通信。例如，B可以接收來自不同于A的許多客戶的請求，并且／或者轉(zhuǎn)送到不同于C的服務(wù)器，與此同時，它還在處理A的請求。任何非隧道的通信成員都可以使用內(nèi)部的高速緩存來處理請求。高速緩存的作用是如果沿著鏈的一個成員對請求采用了高速緩沖的應(yīng)答，請求/應(yīng)答鏈就會大大縮短。以下圖解作為結(jié)果產(chǎn)生的鏈，假定B擁有來自O(shè)（通過C）的一個從前應(yīng)答的備份，請求尚未被UA或A緩存。

請求鏈>UAvAvBCO<應(yīng)答鏈并不是所有的應(yīng)答都能有效地緩存，一些請求可能含有修改量，對緩存動作有特殊的要求HTTP通信在通常發(fā)生在TCP/ＩＰ連接上。默認端口是TCP80,不過其它端口也可以使用日期/時間格式完整日期歷史上的HTTP應(yīng)用一直允許三種不同的表示日期/時間印記的格式:

Sun,06Nov199408:49:37GMT

;RFC822,updatedbyRFC1123

Sunday,06-Nov-9408:49:37GMT;RFC850,obsoletedbyRFC1036

SunNov

608:49:371994

;ANSIC'sasctime()format第一種格式是作為Internet標準提出來的,它表示一個由RFC1123[8](RFC822[9]的升級版本)定義的固定長度的子集.第二種格式使用比較普遍,但是基于廢棄的RFC850[12],需要(應(yīng)該)用四位數(shù)表示年份.對日期值進行語法分析的HTTP/1.1客戶和服務(wù)器必須接受所有三種格式(為了同HTTP/1.0兼容),雖然它們必須只產(chǎn)生RFC1123格式以在頭域里表示HTTP日期值所有的HTTP日期/時間印記都必須毫無例外的以格林威治平均時間(GMT)表示Delta秒一些HTTP頭域收到消息后,允許以十進制整數(shù)秒表示的時間值.

delta-seconds

=1*DIGIT字符集本文檔中的術(shù)語"字符集"指一種用一個或更多表格將一個八字節(jié)序列轉(zhuǎn)換成一個字符序列的方法.HTTP字符集用不區(qū)分大小寫的標記表示.失蹤字符集.HTTP/1.1接收者必須重視發(fā)送者提供的字符集標注;當最初顯示文檔時，那些提供"猜"字符集服務(wù)的用戶代理必須使用內(nèi)容類型域中的字符集，如果它們支持那個字符集，而不是接收者的首選項內(nèi)容編碼內(nèi)容編碼值表示一種已經(jīng)或可以應(yīng)用于實體的編碼變換。內(nèi)容編碼主要用來允許文檔壓縮，換句話說，有效的變換而不損失它的基本媒體類型的特性，也不丟失信息。所有內(nèi)容編碼值都是不區(qū)分大小寫的.

新的內(nèi)容譯碼值的標記應(yīng)該注冊;為了允許客戶和服務(wù)器間的互用性,內(nèi)容譯碼運算的規(guī)范需要實現(xiàn)一個可被公開利用并能獨立實現(xiàn)的新值,并且與這節(jié)中內(nèi)容譯碼定義的目的相一致.傳輸編碼傳輸編碼值被用來表示一個已經(jīng),能夠,或可能需要應(yīng)用于一個實體的編碼轉(zhuǎn)化,為的是能夠確保通過網(wǎng)絡(luò)安全傳輸.這不同于內(nèi)容譯碼,傳輸譯碼是消息的特性而不是原始實體的特性.

transfer-coding="chunked"|transfer-extension

transfer-extension

=token*(";"parameter)

參數(shù)采用屬性/值對的形式.

參數(shù)

=屬性

"="值

屬性

=標記

值

=標記

|

引用-串（quoted-string

所有傳輸譯碼值是不直觀的無論何時一個傳輸譯碼都被應(yīng)用于一個消息體,傳輸譯碼的設(shè)置必須包括"大塊",除非消息被結(jié)束連接停止.當"大塊"傳輸譯碼被應(yīng)用時,它必須是應(yīng)用于消息體的最后傳輸譯碼.這些規(guī)則允許接受從而確定消息的傳輸長度傳輸譯碼被定義能夠?qū)崿F(xiàn)傳送服務(wù)器超過7位的二進制數(shù)據(jù)的安全傳輸.新的傳輸譯碼值標記應(yīng)和新的內(nèi)容譯碼值標記以相同的方式注冊服務(wù)器接收到一個不能理解的傳輸譯碼實體時應(yīng)返回501(不實現(xiàn)),并且切斷聯(lián)系.服務(wù)器不能向HTTP/1.0客戶發(fā)送傳輸譯碼成塊傳輸代碼（ChunkedTransferCoding）成塊編碼更改消息主體,為的是將它以一系列大塊的形式傳送,每一個連同它自己尺寸的指示器,被一個包含實體頭域的可隨意選擇的trailer跟隨.這允許有力量的地生產(chǎn)同接受所必需的消息一起轉(zhuǎn)化的內(nèi)容,從而檢驗它已經(jīng)獲得全部消息.

Chunked-Body

=*chunk(大塊)

大塊-正文

last-chunk(最后-大塊)

trailer(追蹤者)

CRLF

chunk

=chunk-size[chunk-extension]CRLF

大塊

=

大塊-尺寸[大塊-擴展]CRLF

chunk-dataCRLF

大塊-數(shù)據(jù)CRLF

chunk-size

=1*HEX

大塊數(shù)據(jù)

last-chunk

=1*("0")[chunk-extension]CRLF

最后-大塊

=1*("0")[大塊-擴展]CRLF

chunk-extension=*(";"chunk-ext-name["="chunk-ext-val])

大塊-擴展

大塊-外部-名稱

大塊-外部-值

chunk-ext-name=token

大塊-外部-名稱=標記

chunk-ext-val

=token|quoted-string

大塊-外部-值=標記

|

引用-串

chunk-data

=chunk-size(OCTET)

大塊-數(shù)據(jù)

=大塊-尺寸(八位子節(jié))

trailer

=*(entity-headerCRLF)

追蹤者

=*(實體-領(lǐng)先CRLF)媒體類型為了提供公開的,可擴展的數(shù)據(jù)輸入和規(guī)范流通,HTTP在目錄類型和認可頭域中運用網(wǎng)絡(luò)媒體類型

媒體類型

=類型"/"亞類型*(";"參數(shù)

)

類型

=標記

亞類型

=標記參數(shù)可能在屬性/值的形式上遵循類型/亞類型.類型,亞類型,和參數(shù)屬性名稱是不直觀的.參數(shù)值直觀與否,取決于參數(shù)名稱的意義.規(guī)范化和原文缺省網(wǎng)絡(luò)媒體類型以語言的語音典型形式注冊.一個通過HTTP通訊傳輸?shù)膶嶓w必須被以先于傳送的適當?shù)囊?guī)范的形式描繪,除'text'類形以外多部分類型（Multiparttype)多重部分"類型在單個消息體內(nèi)一個或多個實體的包裝.所有的多重部分類型共享一個公共的序列,

產(chǎn)品標記產(chǎn)品標記被用來承認通過軟件名和譯本識別它們自己的通訊應(yīng)用軟件.很多域還把產(chǎn)品標記用于認可次級產(chǎn)品,專業(yè)產(chǎn)品構(gòu)成應(yīng)用軟件中有重要意義的部分被一一列出,用白色間隔分開.按照慣例,按產(chǎn)品對于識別應(yīng)用軟件的重要性的順序列出它們.

產(chǎn)品

=標示

["/"產(chǎn)品-版本]

產(chǎn)品-版本

=標示

例:

用戶-代理:

CERN-LineMode/2.15libwww/2.17b3

服務(wù)器:Apache/0.8.4

質(zhì)量值(QualityValues)HTTP內(nèi)容流通運用簡短的"浮點"數(shù)字來表明不同可流通參數(shù)之間的重要聯(lián)系("重要性").一個重要性從0到1規(guī)格化了一個真實的數(shù)字,0是最小值,是最大值.如果一個參數(shù)為0的質(zhì)量值,那么這個參數(shù)的內(nèi)容不被客戶接受.HTTP/1.1應(yīng)用軟件不能產(chǎn)生多于小數(shù)點后三位數(shù)字.這些值的用戶配置也應(yīng)受限于這種方式.

qvalue

=("0"["."0*3DIGIT])

|("1"["."0*3("0")])標記語言一個語言標記和自然的語言一樣說,寫,或被人類用于與其他人傳遞信息.計算機語言明顯不包括在內(nèi).HTTP在認可語言和目錄語言域內(nèi)運用語言標記.總之,一個語言標記是由一部分或多部分構(gòu)成:一個主要語言標記和可能為空的一系列下標簽.

語言標記

=主要標記

*("_"

下標簽)

主要標記

=1*8ALPHA

下標簽

=1*8ALPHA標簽中不允許出現(xiàn)空格，標簽對個例不敏感（case-insensitive）實體標簽實體標簽用來從相同請求資源中比較兩個或更多實體.一個"堅固的(strong)實體標簽"在兩個實體八位子節(jié)相等時可能會被一個資源里的兩個實體共享.一個"虛弱(weak)的實體標簽",由"W/"前綴表示,在實體相等且可以互相替代而在語義上不發(fā)生重大的變動時,可能會被一個資源力的兩個實體共享.一個虛弱的實體標簽只能在虛弱對比時使用.一個實體標簽必須在所有與一個特殊資源相連系實體的譯本中是獨一無二的.一個給定的實體標簽值可以被不同的URI請求用來獲得實體.相同實體標簽值在不同URI請求獲得實體的聯(lián)合中的運用不意味著那些實體的等同.范圍單位(RangeUnits)HTTP/1.1允許一個客戶要求單獨部分的應(yīng)答實體被包括在應(yīng)答內(nèi)HTTP/1.1中定義的唯一的范圍單位是"字節(jié)".HTTP/1.1實現(xiàn)時可能忽略其他單位指定的范圍。

HTTP/1.1的設(shè)計允許應(yīng)用軟件不依靠有關(guān)范圍的知識而實現(xiàn)HTTP消息消息類型HTTP消息由從客戶到服務(wù)器的請求和從服務(wù)器到客戶的回答組成.消息頭HTTP頭域包括常規(guī)頭，請求頭，應(yīng)答頭，和實體頭域,它們遵循同一個常規(guī)的格式.每一個頭域由一個緊跟":"的名字和域值構(gòu)成.域名是大小寫不敏感的.用不同域名收到的頭域的順序不是重要的.但是,一個好的習慣是先送常規(guī)頭,接著是請求頭或應(yīng)答頭,最后是實體頭域.消息體HTTP消息的消息體備用用來傳輸由要求和應(yīng)答組成的實體.這些消息體僅僅當傳輸譯碼被應(yīng)用的時候才和實體不同,這用傳輸編碼的頭域標明消息的長度一條消息的傳輸長度是消息體出現(xiàn)在消息中的長度,也就是說,當傳輸代碼被處理以后.當一條消息包含消息體,實體的輸長度有以下幾條決定(以先后順序):1。任何回應(yīng)信息不應(yīng)包含在信息體中，如1xx，204,304回應(yīng)和任何對頭請求的回應(yīng)。這種情況都是在頭域結(jié)束后第一行為空白行,不管實體域是否出現(xiàn)。2。傳輸代碼頭域(屬于general-header域)出現(xiàn)的話而且有值而不是身份，那么傳輸長度就可以使用chunked大塊來確定，除非信息由于連接關(guān)閉而中斷了.3。如果Content-Length頭域(屬于實體頭)出現(xiàn)，那么它的值是信息體傳輸長度。如果傳輸頭域和Content-Length頭域都出現(xiàn)了，而長度不一致，那么Content-Length頭域中的值就不該傳。4。如果被1.0代理傳送的范圍頭域不能理解多部份/位范圍；服務(wù)器必須采用1，2，3的方式界定信息體長度。5。當服務(wù)器正在關(guān)閉連接.(正在關(guān)閉連接不能用來說明應(yīng)答體的結(jié)束,因為它將導(dǎo)致服務(wù)器沒有可能送回一個應(yīng)答信號.)常規(guī)頭域這兒有一些頭域能適應(yīng)一般的請求和應(yīng)答消息,但是它沒有應(yīng)用漁船樹種的實體.這些頭域只應(yīng)用于那些被發(fā)射的消息.常規(guī)頭域的名字的真正擴展必須和協(xié)議版本的變化相結(jié)合。然而，新的或?qū)嶒炐再|(zhì)的頭域可能被賦予常規(guī)頭域的意義，如果信息傳輸中的所有部分都承認它們?yōu)槌Ｒ?guī)頭域的話，未被承認的頭于一般當實體頭域看待。請求從客戶機到服務(wù)器的請求,其首行包括利用資源的方式,區(qū)分資源的標識,以及協(xié)議的版本號請求

=請求行

*((常規(guī)報頭

|請求報頭

實體報頭)CRLF)

CRLF

[消息正文]

請求行請求-行的開頭是方法標識,接下來是請求URL和協(xié)議版本號,以回車換行結(jié)束.各部分之間用空格符(SP)分隔,除了最后的回車換行外,不允許有回車(CR)和換行(LF).請求-行

==方式(空格)請求URI(空格)

HTTP版本號(回車換行)方法方法標記指的是在請求URI所指定的資源上所實現(xiàn)的方式,這種方式是條件敏感的請求URL請求URL是一種全球統(tǒng)一的應(yīng)用于資源請求的資源標識符請求定義的資源一個INTERNET請求所定義的精確資源由請求URL和主機報頭域所決定.請求報頭域請求的報頭域允許客戶傳遞關(guān)于請求，客戶自己的附加信息給服務(wù)器．這些域作為請求修飾成分，和程序語言中方法調(diào)用的參數(shù)有差不多的含義．應(yīng)答接收和翻譯一個請求信息后，服務(wù)器發(fā)出一個HTTP應(yīng)答信息．狀態(tài)行應(yīng)答信息的第一行是狀態(tài)行,由協(xié)議版本以及數(shù)字狀態(tài)碼和相關(guān)的文本說明組成,各部分間用空格符隔開，除了最后的回車或換行外，中間不允許有回車換行狀態(tài)碼與注解狀態(tài)碼是試圖理解和滿足請求的三位數(shù)字的整數(shù)碼，狀態(tài)碼用于自動控制而注解短語是面向用戶的．客戶機不需要檢查和顯示注解短語．狀態(tài)碼的第一位數(shù)字定義應(yīng)答類型．后兩位數(shù)字沒有任何類型任務(wù)．第一位數(shù)字有五種值：-1xx:報告的

-接收到請求,繼續(xù)進程.

-2xx

成功

-操作成功的收到.

-3xx

重發(fā)

-為了完成請求,必須采取進一步措施.

-4xx

客戶端出錯

-請求包括錯的順序或不能完成.

-5xx

服務(wù)器出錯

-服務(wù)器無法完成顯然有效的請求狀態(tài)碼＝

"100"

;

繼續(xù)

|"101"

;

轉(zhuǎn)換協(xié)議

|"200"

;

OK

|"201"

;

創(chuàng)建

|"202"

;

接受

|"203"

;

非權(quán)威信息

|"204"

;

無內(nèi)容

|"205"

;

重置內(nèi)容

|"206"

;

局部內(nèi)容

|"300"

;

多樣選擇

|"301"

;

永久移動

|"302"

;

創(chuàng)建

|"303"

;

觀察別的部分

|"304"

;

只讀

|"305"

;

用戶代理

|"307"

;

臨時重發(fā)

|"400"

;

壞請求

|"401"

;

未授權(quán)的

|"402"

;

必要的支付

|"403"

;

禁用

|"404"

;

沒找到

|"405"

;

不允許的方式

|"406"

;

不接受

|"407"

;

需要代理驗證

|"408"

;

請求超時

|"409"

;

沖突

|"410"

;

停止

|"411"

;

需要的長度

|"412"

；

預(yù)處理失敗

|"413"

;

請求實體太大

|"414"

;

請求-URI太大

|"415"

;

不支持的媒體類型

|"416"

；

請求的范圍不滿足

|"417"

;

期望失敗

|"500"

;

服務(wù)器內(nèi)部錯誤

|"501"

;

不能實現(xiàn)

|"502"

;

壞網(wǎng)關(guān)

|"503"

;

服務(wù)不能實現(xiàn)

|"504"

;

網(wǎng)關(guān)超時

|"505"

;

HTTP版本不支持

|擴展碼

應(yīng)答報頭域應(yīng)答頭允許服務(wù)器傳送應(yīng)答的附加信息,這些信息不能放在狀態(tài)行里.這些報頭域給出有關(guān)服務(wù)器的信息以及請求URI指定的資源的下一步的通路．隨著協(xié)議版本的變化,應(yīng)答報頭可以可靠的擴展．而且，如果通信的所有組成部分都把它當作應(yīng)答報頭域,新的或試驗性的應(yīng)答報頭域可以被給定應(yīng)答報頭域的含義，未被承認的報頭域被當作實體報頭域．實體在未經(jīng)特別規(guī)定的情況下，請求與應(yīng)答的報文也可以傳送實體。實體包括實體報頭域與實體正文，而有些應(yīng)答只包括實體報頭

實體報文域?qū)嶓w報文域定義了關(guān)于實體正文的維護信息（參數(shù)），或在無正文情況下定義了請求的資源。其中一些參數(shù)是可選的，一些則是由技術(shù)指標規(guī)定必須的。實體正文。經(jīng)由HTTP請求或應(yīng)答發(fā)送的實體正文部分（如果存在的話）的格式與編碼方式應(yīng)由實體報文域決定。類型對于報文中的實體正文而言，其數(shù)據(jù)類型由報頭中的"內(nèi)容類型"與"內(nèi)容編碼"域決定。實體狀態(tài)報文的實體長度指的是在對報文進行傳輸編碼前報文正文的長度。連接持續(xù)連接。目的在持續(xù)連接之前，為獲取每一URL都建立了獨立的TCP連接，這就加重了HTTP服務(wù)器的負擔，易引起INTERNET阻塞。嵌入式圖片與其它相關(guān)數(shù)據(jù)通常使用戶在短時間內(nèi)對同一服務(wù)器提交多個請求?？傮w操作HTTP/1.1與早期HTTP版本的一個顯著區(qū)別在于持續(xù)連接是任何HTTP連接的缺省方式。也就是說，除非另有指定，客戶機總應(yīng)當假定服務(wù)器會保持持續(xù)連接，即便在接到服務(wù)器的出錯應(yīng)答時也應(yīng)如此。持續(xù)連接提供了一種可以由客戶機或服務(wù)器發(fā)信號終止TCP連接的機制。談判除非請求的連接報頭域中包括了"終止連接"的符號，HTTP/1.1服務(wù)器總可以假定HTTP/1.1客戶機想要維持持續(xù)連接。如果服務(wù)器想在發(fā)出應(yīng)答后立即終止連接，它應(yīng)當發(fā)送一個含有終止要求的連接報頭域。無論是客戶機或服務(wù)器發(fā)起終止連接，這都是本次連接的最后一個請求。流水線支持持續(xù)連接的客戶機可以以流水線方式發(fā)送請求（即無須等待應(yīng)答而發(fā)送多個請求）。服務(wù)器則必須將其應(yīng)答按接到請求的順序發(fā)出。代理服務(wù)器使代理服務(wù)器正確地實現(xiàn)所規(guī)定的連接報頭域的屬性是非常關(guān)鍵的。代理服務(wù)器必須獨立于它所連接的客戶機，原服務(wù)器（或其它代理服務(wù)器）而發(fā)出持續(xù)連接的信號。實際的考慮服務(wù)器通常有一個時限值，超過一定時間即不再維系處于非活躍態(tài)的連接。代理服務(wù)器會選一個較高的值，因為客戶機很可能會與同一服務(wù)器建立多個連接。持續(xù)連接方式的采用對于客戶機與服務(wù)器的時限均未提出任何要求。當客戶機或服務(wù)器希望超時終止時，它應(yīng)按規(guī)范終止傳輸連接?？蛻舳伺c服務(wù)器端應(yīng)始終注意對方是否終止了連接，并適當?shù)挠枰詰?yīng)答。若客戶機或服務(wù)器未能及時檢測到對方已終止了連接，將會造成不必要的網(wǎng)絡(luò)資源浪費。報文傳輸要求持續(xù)連接與流量控制HTTP/1.1服務(wù)器應(yīng)當保持持續(xù)連接并使用TCP的流量控制機制來解決臨時過載，而不是在終止連接后指望客戶端的重試。后一方法會惡化網(wǎng)絡(luò)阻塞。監(jiān)視連接中出錯狀態(tài)的報文發(fā)送報文正文的HTTP/1。1（或更新）客戶機應(yīng)在傳輸請求的同時監(jiān)視連接是否處于出錯狀態(tài)。若客戶機發(fā)現(xiàn)了錯誤，它應(yīng)當立即停止正文的傳送。若正文是以塊編碼方式發(fā)送的，可以用一長度為零的塊和空報尾來提前標記報文結(jié)束。若正文前有"內(nèi)容長度"報頭，則客戶機必須關(guān)閉連接。100號狀態(tài)的用途100號狀態(tài)的目的在于幫助那些發(fā)送含有請求正文的請求報文的客戶機在發(fā)送請求正文之前推測服務(wù)器看到請求報頭后是否愿意接收請求。有些時候，如果服務(wù)器不看正文就棄置報文的話，客戶機對正文的發(fā)送就多此一舉了。

服務(wù)器過早關(guān)閉連接時客戶機的行為如果HTTP/1。1客戶機發(fā)出一條含有請求正文但不含填有"100-繼續(xù)"的"期望"報頭域的請求，并且客戶機直接與HTTP/1。1原服務(wù)器相連，在從服務(wù)器處接到任何狀態(tài)信息之前就發(fā)現(xiàn)連接被關(guān)閉，那么客戶機應(yīng)當重試請求。在重試時，客戶機何以采用如下所述的"二進制指數(shù)后退算法"以確保獲得可靠應(yīng)答：

1．向服務(wù)器發(fā)起一新連接。

2．發(fā)送請求的報頭。

3．初始化變量R為通往服務(wù)器的往返時間的估計值（比如基于建立連接的時間），或在無法估計往返時間時設(shè)為一常數(shù)值5秒。

4．計算T=R*（2**N），N為此前重試請求的次數(shù)。

5．等待服務(wù)器發(fā)來的出錯應(yīng)答或是T秒（兩者中時間較短的）。

6．若沒等到出錯應(yīng)答，T秒后發(fā)送請求正文。

7．若客戶機發(fā)現(xiàn)連接被提前終止，轉(zhuǎn)到第1步，直到請求被接受，接到出錯應(yīng)答，或是用戶因不耐煩而終止了重試進程。在任意環(huán)節(jié)上，客戶機如果接到出錯狀態(tài)，

不應(yīng)再繼續(xù)，并且

如完成請求報文的發(fā)送則應(yīng)終止連接方法定義HTTP/1.1常規(guī)方法的定義如下.雖然這個定義可以展開,但附加的方法不能被假定分享和個別擴展的客戶機和服務(wù)器同樣的語義.主機請求應(yīng)答報頭必須符合所有的HTTP/1.1請求.安全和等冪(Idempotent)方法安全方法實現(xiàn)程序應(yīng)當知道軟件通過在Internet上的交互來扮演用戶,且應(yīng)該仔細的允許用戶知道任何它們可能采取的行動,這些行動可能給他們自己或他人帶來無法預(yù)料的結(jié)果.特別的.這樣的慣例已經(jīng)形成,就是GET和HEAD方法除了補救外不應(yīng)該有別的采取措施的含義.等冪方法方法也可以等冪的性質(zhì),這種情況下(除了出錯或終止問題)N>0個同樣請求的副作用和單個請求一樣.方法GET,HEAD,PUT,DELETE都有這種性質(zhì).而且,方法OPTIONS和TRACE不應(yīng)該有副作用,等冪就是這樣的含義.然而,有可能幾個請求的序列是不等冪的,即使在那樣的序列中所有方法單獨實現(xiàn)都是等冪的(如果整個序列整體的實現(xiàn)結(jié)果總是相同的,即不因序列整體,部分的重新實現(xiàn)而變化,則序列是等冪的).例如,如果一個序列實現(xiàn)的結(jié)果依賴一個序列中后來可以修改的值,則該序列不是等冪的.沒有副作用的序列是等冪的(倘若在同樣的資源配置下不同時操作)OPTIONS(選項）OPTIONS方法描述了在請求URI確定的請求/應(yīng)答過程中通信條件是否可行的信息.該方法允許客戶機確定條件或設(shè)備,其與資源或服務(wù)器的沒有暗示資源操作或初始化資源重建的情況下的性能有關(guān),這種方法的應(yīng)答是不能緩存的.GET（獲?。〨ET方法重建信息的內(nèi)容(正文的形式)由請求URI來確定.如果請求URI指數(shù)據(jù)產(chǎn)生的過程,它是在應(yīng)答中產(chǎn)生,被當作正文返回的數(shù)據(jù),而不是過程的源文本,除非文本碰巧是過程的輸出.HEAD（報頭）除了應(yīng)答中禁止返回消息正文外,HEAD方法與GET方法一樣.包含在HTTP報頭以后應(yīng)答報頭頭請求的信息與POST去應(yīng)答GET請求的信息是相同的.這種方法能用于獲得關(guān)于實體更多的信息,沒有傳輸實體正文本身的請求暗示了這種信息.這個方法常用來檢查超文本鏈接的有效性,可到達性和最近的修正.POST（張貼）在POST方法適用的請求中,原服務(wù)器接收附加在請求后的實體,該實體后作為請求行里請求URI指定的資源的次要部分,.POST被設(shè)計為具有如下的功的統(tǒng)一的方法:

-已有資源的注解.

-在電子布告版,新聞組,郵箱或類似的主題組貼一些信息.

-提供數(shù)據(jù)塊,像確認表單數(shù)據(jù)處理的結(jié)果.

-通過附加的操作擴充數(shù)據(jù)庫.PUT（放置）PUT方法要求所附實體存儲在提供的請求URI下.假如請求URI指的是已經(jīng)存在的資源,所附的實體應(yīng)當被當作原服務(wù)器中已修改的版本.假如請求URI指的不是已經(jīng)存在的資源,而URI可以被客戶代理定義成新的資源,原服務(wù)器可以建立該URI資源.假設(shè)建立了新資源,原服務(wù)器必須通過201(建立)應(yīng)答通知用戶代理.如果修改了已有資源,將發(fā)送200(OK)或204(無內(nèi)容)應(yīng)答表示請求的成功完成.如果對于該URI資源不能創(chuàng)建或修正,將給出合理的出錯應(yīng)答來反映問題所在.實體容器不能忽視任何不被理解或?qū)崿F(xiàn)的內(nèi)容-*(例如內(nèi)容范圍)報頭,這時必須返回501(未實現(xiàn))應(yīng)答.DELETE（刪除）DELELE方法要求原服務(wù)器釋放請求URI指向的資源.這種方法可以通過原服務(wù)器上人的強行干涉而制止(括其他手段).客戶機不能擔保操作已經(jīng)實現(xiàn)了,即使從原服務(wù)器返回的狀態(tài)碼說明操作已經(jīng)成功的完成.但如果當時應(yīng)答未給出的話,服務(wù)器不應(yīng)該表示成功,它打算釋放資源或移到不能訪問的位置.TRACE（跟蹤）TRACE方法用于調(diào)用遠程的,應(yīng)用層循環(huán)請求消息.請求最終的接收者應(yīng)當反射從客戶機作為200應(yīng)答的實體正文收到的信息.最終的接收者也是原服務(wù)器或在請求中收到最大轉(zhuǎn)發(fā)數(shù)量值第一個代理服務(wù)器或網(wǎng)關(guān).TRACE請求不包括實體.CONNECT（連接）本說明中保留CONNECT方法用于能動態(tài)建立起隧道的代理服務(wù)器狀態(tài)代碼定義每一段狀態(tài)代碼在下面被描述,包括他所能遵循的方法的描述和在應(yīng)答中所必需的維護信息.信息1xx狀態(tài)代碼的類簡單描述了一個臨時的回答,只是由狀態(tài)行和可選擇的報頭所組成,并且由空行所決定,狀態(tài)代碼類沒有所需的報頭.自從HTTP/1.0沒有定義任何1xx狀態(tài)代碼,在實驗的條件下服務(wù)器嚴禁發(fā)送一個1xx應(yīng)答給HTTP/1.0客戶.

客戶必須準備在接受通常應(yīng)答之前接受一個或者多個1xx應(yīng)答，甚至客戶并不期待一個100狀態(tài)的報文。不被期待出現(xiàn)的1xx狀態(tài)應(yīng)答也許會被用戶端的代理所忽略。100繼續(xù)客戶應(yīng)該和他自己的請求繼續(xù)。中間的應(yīng)答被用于告知客戶請求的初始部分已經(jīng)收到并且還沒有被服務(wù)器所拒絕?？蛻魬?yīng)該繼續(xù)發(fā)送剩下的請求，或者如果請求早已完成，那就忽略請求。服務(wù)器必須發(fā)送一個初始回答應(yīng)答當請求完成時。101轉(zhuǎn)換協(xié)議

服務(wù)器了解并且愿意順從客戶的請求，經(jīng)過升級的報文報頭區(qū)域，為的就是一個應(yīng)用協(xié)議的變化使之能夠在連接中使用。服務(wù)器會轉(zhuǎn)換協(xié)議使之成為那些通過應(yīng)答升級報頭的區(qū)域定義的立即在決定101應(yīng)答的空行之后的協(xié)議。

協(xié)議應(yīng)該僅僅在這樣做有利的時候?qū)嵭修D(zhuǎn)換。成功2xx這種狀態(tài)代碼類簡要的說明了客戶的請求被成功的接收，理解，和接受200OK請求已經(jīng)成功。連同應(yīng)答一起返回的信息是依賴于在請求中使用方法的。例如：GET

與被請求的資源相應(yīng)的實體在應(yīng)答中一起發(fā)送。

HEAD

與被請求資源相對應(yīng)的沒有報文正文的報頭區(qū)域在應(yīng)答中發(fā)送。

POST

描述或者包含行動結(jié)果的實體。

TRACE

底端服務(wù)器已經(jīng)接收的包含請求報文的實體

201創(chuàng)建請求已經(jīng)完成同時導(dǎo)致新的資源被創(chuàng)造.新創(chuàng)造的資源和地址報頭區(qū)域給出資源的最專業(yè)的URI可以被隨應(yīng)答實體返回的URI參考.應(yīng)答應(yīng)該包含用戶或者用戶代理可以從中選擇出的一系列最最合適資源的特征和地址.實體的格式通過在內(nèi)容形式報頭區(qū)域給出的媒體形式來詳細說明.最初的服務(wù)器必須在返回201狀態(tài)代碼以前創(chuàng)造資源.如果行動不能馬上執(zhí)行,服務(wù)器應(yīng)該以202接受應(yīng)答來應(yīng)答它.202接受.為了處理,請求被接受,但是處理并沒有完成.請求最終有可能或者不可能遵照行事,因為在處理過程實際發(fā)生時,它有可能被不允許.沒有什么設(shè)備可以從如此的異步操作中重新發(fā)送狀態(tài)代碼202應(yīng)答是故意無委托的.它的目的就在于為了其他一些過程,在沒有要求用戶代理直到過程執(zhí)行結(jié)束還堅持連接到服務(wù)器的情況下,允許服務(wù)器接受請求(也許是一批有所指向的一天只處理一次).實體和應(yīng)答返回應(yīng)該包括當前的請求狀態(tài),和或者一個指向狀態(tài)監(jiān)聽器的指針或者關(guān)于什么時間用戶期待請求完成的估計..203

非權(quán)威信息在實體報頭中返回的維護信息并不是原服務(wù)器可用的最終的設(shè)置,但是他們是從一個本地的或是第三方的拷貝.提出的設(shè)置也許是原始版本的子集或是父集.舉例來說,包括有關(guān)于也許導(dǎo)致被原服務(wù)器識別的維護信息的父集的本地注解信息.這種應(yīng)答代碼的用法并不必需,而且只有當應(yīng)答為200時才適用.204沒有內(nèi)容服務(wù)器完成請求并不需要返回實體的正文,并且也許想返回升級過的維護信息.應(yīng)答也許包含新的或者是升級過的的實體報頭形式的維護信息,如果這些當前的可以與請求的變量相關(guān)聯(lián).205重置內(nèi)容服務(wù)器已經(jīng)完成了請求,用戶代理應(yīng)該重新設(shè)置導(dǎo)致請求被發(fā)送的文件觀點.這種應(yīng)答主要是故意允許輸入行動通過用戶輸入發(fā)生,伴隨而來的是對給出形式的清理為了讓用戶可以輕松開始另一個輸入行動.應(yīng)答嚴禁包含任何實體.

206局部內(nèi)容服務(wù)器對于資源已經(jīng)完成了部分GET請求.請求必須包含一個范圍報頭區(qū)域重新定向3xx.這種狀態(tài)代碼類指出了為了完成請求用戶代理而所需要做的更進一步的行動.必需的行動

可以被沒有與用戶發(fā)生交互作用的用戶代理執(zhí)行并且在當且僅當在第二個請求中所需的方法是GET或者是HEAD.客戶應(yīng)該偵察最終的重新定向環(huán)路,因為對于每一個重新定向來說這樣的環(huán)路產(chǎn)生網(wǎng)絡(luò)交通.300多樣選擇.被請求的資源符合任何一套表示法之一,每種資源和她自己的特定地址,并且為了使用戶可以選擇一個首選的表示法和依照那個地址重新定向,代理驅(qū)動的協(xié)商信息可以被提供出來.301永久移動被請求的資源已經(jīng)分配了一個新的永久的URI,任何對資源的未來參考應(yīng)該使用返回的URI中的一個.有編輯連接能力的客戶應(yīng)該對于被請求的URI從可能的服務(wù)器中返回的一個或者多個參考中實現(xiàn)自動連接參考.這種應(yīng)答是可以緩存的除非它指出其他的.新的永久的URI應(yīng)該在應(yīng)答中的地址區(qū)域給出.除非請求方法是HEAD,應(yīng)答的實體應(yīng)該包括一個段指向新的URI的超文本文本注解302創(chuàng)立被請求的資源已經(jīng)分配了一個新的永久的URI,任何對資源的未來參考應(yīng)該使用返回的URI中的一個.有編輯連接能力的客戶應(yīng)該對于被請求的URI從可能的服務(wù)器中返回的一個或者多個參考中實現(xiàn)自動連接參考.這種應(yīng)答是可以緩存的除非它指出其他的.對臨時的URI應(yīng)該給予地址區(qū)域.除非請求的方法是HEAD,相應(yīng)的實體應(yīng)該包含一個短的指向一個新的URI的超級連接的超文本提示303觀察別的部分對請求的應(yīng)答可以在不同的URI中找到,并且應(yīng)答應(yīng)該在對資源的GET方法中重新得到.這種方法存在主要是為了允許郵政活性的輸出腳本重新定向用戶代理于一個選擇的資源.新的URI不是一個最初請求資源的替代參考.303應(yīng)答嚴禁緩存,但是對于第二個請求(重新定向)可以緩存304只讀如果客戶提出一個條件的GET請求并且訪問也已經(jīng)允許,但是文檔并沒有修改,服務(wù)器應(yīng)該應(yīng)答這些狀態(tài)編碼.304應(yīng)答嚴禁包含報文正文,并且總是由報頭區(qū)域之后的第一個空行決定的.305使用代理服務(wù)器地址區(qū)域的被請求的資源必須通過代理服務(wù)器.地址區(qū)域給除了代理服務(wù)器的URI.期望容納者通過代理服務(wù)器重復(fù)這一單一請求.305應(yīng)答必須由原服務(wù)器產(chǎn)生.307臨時重發(fā).請求的資源臨時存在在另一個不同的URI下.由于重新定位有時可能變化,客戶應(yīng)該繼續(xù)使用請求URI以備將來用途.這個應(yīng)答只有當被緩存控制或是終止報頭區(qū)域指出時才是可以存儲的.客戶錯誤4xx狀態(tài)代碼4xx類是專門使用在客戶看上去錯誤的情形下的.除非當應(yīng)答一個HEAD請求時,服務(wù)器因該有一個包括錯誤情形的解釋的實體,以及它是否一個臨時或者終了的條件.這些狀態(tài)編碼可以應(yīng)用于任何請求方法.用戶代理應(yīng)該向用戶顯示任何包括的實體.如果客戶在發(fā)送數(shù)據(jù),使用TCP的服務(wù)器的實現(xiàn)應(yīng)該小心以保證在服務(wù)器關(guān)掉了所有的輸入連接時客戶承認收到包含應(yīng)答的包.在關(guān)掉之后如果客戶繼續(xù)發(fā)送數(shù)據(jù)給服務(wù)器,服務(wù)器TCP堆會發(fā)送一個重制包,也許這樣子會在服務(wù)器開始被訪問以及HTTP應(yīng)用程序被解釋的情況下,會擦掉客戶不知道的輸入緩沖.400壞請求請求由于畸形的語法而不被服務(wù)器所理解.客戶不應(yīng)該重復(fù)自己的請求在沒有改變的情況下.401未授權(quán)的請求需要用戶的鑒定.應(yīng)答必需有用于對被請求資源的挑戰(zhàn)的包含WWW鑒定報頭區(qū)域.如有合適的認證報頭區(qū)域,客戶可以重復(fù)請求.如果請求已經(jīng)包含了認證的信任書,那么401應(yīng)答就指出了認證由于這些信任書而被拒絕.如果401應(yīng)答包括和上一個應(yīng)答同樣的挑戰(zhàn)并且用戶代理已經(jīng)嘗試認證了至少一次,那么應(yīng)該給用戶在應(yīng)答中給出的實體,因為實體中可能包含相應(yīng)的診斷信息.402必需的支付這種代碼被保存下來以便將來使用.403禁用服務(wù)器理解了請求,但是拒絕實現(xiàn)它.認證不會幫助,請求也不應(yīng)該重復(fù).如果請求的方法不是HEAD并且服務(wù)器愿意將請求為什么沒有實現(xiàn)告訴大家,它應(yīng)該在實體中描述拒絕的理由.如果服務(wù)器并不想將這條信息告訴客戶,狀態(tài)代碼404(沒找到)可以替代使用之.404沒有找到服務(wù)器并沒有找到任何可以匹配請求URI.條件是永久的還是暫時的也沒有任何的跡象.410狀態(tài)編碼應(yīng)該在服務(wù)器知道老的資源是永遠不可以得到的并且沒有以前的地址的情況下,通過一些內(nèi)在的可配置的機構(gòu),才應(yīng)該使用.這種狀態(tài)編碼當服務(wù)器不想精確展示為什么請求被拒絕或者何時沒有其他的應(yīng)答可以利用的時候被廣泛的應(yīng)用.405不被允許的方法在請求行中特殊指定的方法不允許訪問由請求URI指定的資源.應(yīng)答必需有一個包括一些對于被請求的資源有效的方法的允許報頭.406不接受請求指定的資源只可能產(chǎn)生依照在發(fā)送請求中的接受報頭有不接受的內(nèi)容特性的應(yīng)答實體.407代理服務(wù)器認證所必需這種代碼很相近于401,但是它指出了客戶必須和代理服務(wù)器之間認證自己.代理服務(wù)器必需返回一個代理服務(wù)器認證報頭區(qū)域,該區(qū)域包括是為了被請求的資源而用于代理服務(wù)器的挑戰(zhàn).客戶可能隨著一個合適的代理服務(wù)器認證報頭區(qū)域一起重復(fù)它的請求.

408請求超時在服務(wù)器準備等待的時間段內(nèi),客戶并沒有產(chǎn)生請求.客戶也許會在以后的任意一時間內(nèi)重復(fù)請求.409沖突由于與資源的現(xiàn)在狀態(tài)的沖突請求游客能不能完成.代碼只有在用戶被期待有可能解決沖突和提交請求的地方的情況下允許使用.應(yīng)答體應(yīng)該包括對于用戶認識沖突來源的足夠多的信息.理想的,應(yīng)答體應(yīng)該有對于用戶和用戶代理可以解決問題的足夠多的信息量.然而,這也許是不可能的或者是不必需的.沖突通常會發(fā)生在應(yīng)答PUT請求的時候.410停止服務(wù)器上的被請求的資源不再可用,而且不知道以前的地址.我們期望此條件被認為是永遠的.有連接編輯能力的客戶在用戶同意的情況下,應(yīng)該刪掉對請求URI的參考.如果服務(wù)器并不知道,或者沒有設(shè)備去決定是否條件是永久的,狀態(tài)代碼404(未找到)此時應(yīng)該使用.這種應(yīng)答是不可被緩存的除非另外指出.

411必需的長度服務(wù)器拒絕接受沒有定義的內(nèi)容長度的請求.如果加上了一個有效的"包含有請求報文正文中的長度"的內(nèi)容長度報頭區(qū)域,那么客戶可能重復(fù)請求.412預(yù)處理失敗在一個或者多個請求中給出的預(yù)處理在被服務(wù)器驗證的時候會被評價為錯誤的.這種應(yīng)答代碼允許客戶將預(yù)處理放在當前資源維護信息(報頭區(qū)域數(shù)據(jù)),并且這樣作以防止有其他的適應(yīng)資源請求的法的而非所要的那一個.413請求實體太大服務(wù)器拒絕處理一個請求因為請求比服務(wù)器所能和所愿處理的還要大.服務(wù)器可能關(guān)掉連接以防止客戶繼續(xù)請求.如果條件是暫時的,服務(wù)器應(yīng)該有一個重新試-在之后報頭區(qū)域以便于指出這是暫時的在什么時間以后客戶可以再試一次.414請求的URI過長服務(wù)器拒絕請求的服務(wù)因為請求的URI比服務(wù)器所愿意解釋的要長.這種比較珍稀的條件之可能發(fā)生在黨課互補恰當?shù)膶OST請求變?yōu)橛虚L查詢信息的GET請求的情況下,或是客戶落到了一個重新定向的URI黑洞中時,再或者是在一些使用固定長度緩沖區(qū)用以讀或者處理請求的URI的服務(wù)器遭到鉆安全漏洞的黑客的攻擊的時候.415不被支持的媒體類型服務(wù)器拒絕提供服務(wù)給請求因為請求的實體所請求的方法是在一種不被請求資源支持的格式下.416請求范圍不滿足如果請求包括范圍請求報頭區(qū)域,或者是在區(qū)域內(nèi)沒有范圍說明符的值溢出當前選擇資源的延伸,再或者是請求沒有包含如果--范圍請求--報頭區(qū)域,服務(wù)器應(yīng)該返回連同狀態(tài)代碼的一個應(yīng)答.417期望失敗在請求報頭區(qū)域給出的預(yù)料不可能被服務(wù)器實現(xiàn),或者,如果服務(wù)器是代理服務(wù)器,服務(wù)器有請求不可能被下一個服務(wù)器實現(xiàn)的模糊的證據(jù)服務(wù)器錯誤5xx應(yīng)答狀態(tài)代碼用阿拉伯數(shù)字"5"表示服務(wù)器知道它自己有錯誤或者自己不能實現(xiàn)請求等這些情況.除了當應(yīng)答一個HEAD請求,服務(wù)器應(yīng)該有一個包括錯誤形式的解釋的實體和它是否暫時或者永久的條件的解釋的實體.用戶代理應(yīng)該顯示任何包括的實體給用戶.這些應(yīng)答代碼對于任何請求的方法都是適用的.500服務(wù)器內(nèi)部錯誤服務(wù)器遇到預(yù)料到的防止它完成請求的情況.501不能實現(xiàn)服務(wù)器不支持完成請求所必需的功能性.當服務(wù)器并不認識請求的方法并且沒有能力對于任何資源支持時,這是合適的應(yīng)答

502壞網(wǎng)關(guān)服務(wù)器,當被用作一個網(wǎng)關(guān)或者是代理服務(wù)器時,就會從上流的服務(wù)器收到無效的應(yīng)答以試圖完成請求的訪問.

503難以獲得的服務(wù).由于暫時的過載或者服務(wù)器維護,服務(wù)器此時不能處置請求.這說明了這是一個暫時的條件過一些耽擱會減輕.如果知道,耽擱的長度應(yīng)會在重新試-在之后報頭中指出.如果沒有重新試-在之后給出,客戶應(yīng)該處理處置應(yīng)答就像處理一個500應(yīng)答一樣。504網(wǎng)關(guān)超時服務(wù)器,當被用作是網(wǎng)關(guān)或者是代理服務(wù)器時,由于URI指定的上游服務(wù)器或者其他一些輔助服務(wù)器以有資格嘗試完成請求,并沒有收到及時的應(yīng)答.505HTTP版本不支持服務(wù)器并不支持,或者拒絕支持,在請求信息中用到了HTTP協(xié)議版本.服務(wù)器指出它不能或是不愿完成使用與客戶端一樣的版本的請求,就像在章節(jié)3.1中描述的那樣,???????.應(yīng)答應(yīng)該包含描述為什么那個版本不為支持而為什么其他協(xié)議被服務(wù)器支持的實體..入口驗證HTTP提供了一些可以選擇的用于服務(wù)器挑戰(zhàn)用戶請求和用戶提供驗證信息的的挑戰(zhàn)-應(yīng)答驗證機制.入口驗證的大體框架,和基礎(chǔ)及分類驗證的規(guī)范在"HTTP規(guī)范:"基礎(chǔ)及分類入口驗證"中詳細說明.這份說明從規(guī)范中采用了"挑戰(zhàn)"和"外交國書"的定義內(nèi)容談判大多數(shù)HTTP應(yīng)答都有一個包括人類用戶解釋信息的實體.自然地,相對于請求它需要提供給用戶"最佳利用"的實體.很不幸的是,對于服務(wù)器和存儲器來說,不是所有的用戶都有同樣的關(guān)于"什么是最好的"的判斷準則,并且并不是所有的用戶代理有相同的解釋實體形式的能力.為此,HTTP為了"內(nèi)容談判"提供了一些機制當有很多種可能的表示時如何選擇對于一個請求的最佳的表示

服務(wù)器驅(qū)動談判如果對于一個請求的最佳表示的選擇由服務(wù)器提供的運算法則來完成,我們就叫它是服務(wù)器驅(qū)動談判.選擇是基于應(yīng)答中可行的解釋和在請求報文的特定報頭區(qū)域的內(nèi)容或是其他一些適合請求的信息(如客戶的網(wǎng)絡(luò)地址).代理驅(qū)動談判在代理驅(qū)動談判中,對于一個應(yīng)答的最佳表示法的選擇是在代理從原服務(wù)器端收到最初的應(yīng)答后實現(xiàn)的.選擇是基于一系列可用的應(yīng)答的通過自己URI鑒定的表示法,其中包括初應(yīng)答的報頭區(qū)域和實體正文.從表示法中的選擇可以自動實現(xiàn)(如果用戶有能力這么做)或者人工的用戶從產(chǎn)生的菜單(可能是超文本)中選擇.透明的判斷透明的判斷是服務(wù)器驅(qū)動和代理驅(qū)動談判的結(jié)合體.當緩存被供給了一系列可茲利用的應(yīng)答的表示法并且變量的尺寸被緩存充分理解時,緩存可以執(zhí)行代表為了資源的后來請求的原服務(wù)器服務(wù)器驅(qū)動的判斷.HTTP中的緩存HTTP典型應(yīng)用于能通過采用緩存技術(shù)而提高性能的分布式信息系統(tǒng)。緩存正確性在如下列情況下,一個正確的緩存必須從他所存儲的內(nèi)容中選出最新者來響應(yīng)請求.1.經(jīng)過檢驗,源服務(wù)器對收到響應(yīng)重新確認生效返回的結(jié)果與原來相同.2．."足夠保鮮".在缺省值情況下,它表示對代理,源服務(wù)器和緩存的最低的保鮮性要求;如果源服務(wù)器詳細說明,那么保鮮性要求僅是對源服務(wù)器本身而言有效.如果某一存儲的響應(yīng)對代理和源服務(wù)器的最低保鮮要求仍不滿足,慎重考慮,緩存應(yīng)返回響應(yīng)并加入適當警告報頭,除非這種響應(yīng)是被禁止的.3.

304(未修改),305(代理人重寄),或錯誤(4xx,5xx)響應(yīng)信息.如果緩存無法與源服務(wù)器通信,則當響應(yīng)能正確的從緩存發(fā)出時,緩存應(yīng)

如上響應(yīng);如果不能,則緩存應(yīng)發(fā)出錯誤或警告信息以說明存在通信故障.如果緩存收到響應(yīng)(不論是一個完整響應(yīng)還是一個304響應(yīng)),它會將其轉(zhuǎn)寄給請求客戶,當收到的響應(yīng)被刷新時,緩存應(yīng)該轉(zhuǎn)寄給請求客戶而不須加入新的警告信息(且無需去掉已經(jīng)存在的警告報頭).緩存不能僅僅因為某一響應(yīng)在傳送過程中"過時"了而令響應(yīng)重新生效,這將引入一個死循環(huán).一個用戶代理收到?jīng)]有警告的過時響應(yīng)應(yīng)對用戶顯示警告.

警告信息當緩存器返回響應(yīng)既不是第一手的也不是最保鮮(fresh)的,此響應(yīng)必須附加警告，使用一般警告報頭,此警告允許客戶采取適當行動.警告信息可以被用作他途,不論是否與緩存有關(guān).警告的使用,而非錯誤狀態(tài)代碼區(qū)分了前述響應(yīng)和實際錯誤.警告信息由三類阿拉伯數(shù)字代碼表示.第一個數(shù)字表明當重發(fā)成功后警告信息是否必須或必須不被刪除.緩存控制機制在HTTP1.1協(xié)議中的基本緩存機制是隱含指示給緩存器.在某些情況下,一服務(wù)器或代理可能需要給緩存器以明確的指示,我們用緩存器控制報頭來達到這一目的.緩存器控制報頭允許代理或服務(wù)器傳送多種指示,既可以是請求,也可以是響應(yīng).這些指示代替缺省的緩存算法直接的用戶代理警告協(xié)議通常允許用戶代理來決定響應(yīng)是否已經(jīng)失效，當實際發(fā)生時，該指示需要單獨顯示。該指示不必是對話框，它可以是一個圖標。規(guī)則和警告的例外情況在某些情況下，緩存操作員會選擇設(shè)置緩存當用戶未提出請求時發(fā)出過時的響應(yīng)。協(xié)議還允許用戶代理采取措施來獲得第一手的或最新的響應(yīng)。由客戶控制的行為當源服務(wù)器是滿期信息的最初來源，在某些情況下，客戶將需要控制緩存器決定是否回復(fù)緩存的響應(yīng)而不使其生效?？蛻粜枰褂镁彺嫫骺刂茍箢^的幾項指示來作此工作。過期(Expiration)模型服務(wù)器指定模型當緩存器能完全避免向源服務(wù)器發(fā)送請求時，它工作于最佳狀態(tài)。避免請求的根本機制是源服務(wù)器給出一個明確的未來過期時間，這樣響應(yīng)信息或許可以滿足后來的請求。換句話說，緩存器不必首先聯(lián)系服務(wù)器就能回復(fù)一個最新響應(yīng)。啟發(fā)式過期由于源服務(wù)器并不總是提供明確的過期時間,HTTP緩存器典型設(shè)置為啟發(fā)式過期時間,采取使用其他報頭值的算法來估計一個近似的過期時間。HTTP1.1說明書中并未給出詳細算法，但卻利用最壞情況來限制其結(jié)果。由于啟發(fā)式過期次數(shù)可能影響語義透明度，故應(yīng)慎重使用，而且我們鼓勵源服務(wù)器提供盡可能大的過期次數(shù)。年齡(Age)計算為了解緩存實體是否為最新，緩存器需要知道其年齡是否已超過保鮮時限。過期計算：為了確定一條響應(yīng)是新是舊，我們需要將其保鮮期限和年齡進行比較，澄清過期值由于過期值不是嚴格制定的，所以可能兩個緩存器對相同資源制定的刷新值不同。

澄清多重響應(yīng)因為客戶可能收到經(jīng)多重路徑來的響應(yīng)，所以有些響應(yīng)流經(jīng)一簇緩存器，而另一些響應(yīng)流經(jīng)另一簇緩存器，客戶收到響應(yīng)的順序可能與源服務(wù)器發(fā)響應(yīng)的順序不同，我們希望客戶能選用最新的響應(yīng)。確認模式當緩存器想要用一個失時效的條目來相應(yīng)客戶的請求,他首先必須向源服務(wù)器(如果可能則向一中間緩存器)檢驗這一緩存條目是否仍然可用.我們稱之為"確認"緩存條目.最后修改日期(Last-ModifiedDates)最后修改報頭值經(jīng)常被用作確認器.簡言之,一緩存條目在最后修改期后未經(jīng)修改則被認為是有效的.標簽緩存確認器(EntityTagCacheValidators)標簽響應(yīng)報頭值,一個實體標簽,提供了一個"模糊"緩存確認器.這將允許在不便存儲修改信息的情況下進行可靠的確認,包括HTTP日期數(shù)據(jù)不充足和源服務(wù)器不想因使用修改日期而帶來麻煩的情況.強,弱確認器由于源服務(wù)器和緩存器會比較兩個確認器來確定他們是否代表相同的條目,所以通常希望實體發(fā)生任何變化,確認器也相應(yīng)變化,這樣的確認器為強確認器.關(guān)于何時使用實體標簽和最后修改時間的規(guī)則我們對源服務(wù)器，客戶和緩存器采用一套規(guī)則和建議來規(guī)定在何時，出于何種目的，應(yīng)采用何種確認器。不確認條件其他報頭的比較不被用于確認緩存實體.緩存能力響應(yīng)除非被明確限制,緩存系統(tǒng)可以將一成功的響應(yīng)作為緩存實體一直存儲,如果它是保鮮的可以不確認而返回它,如果成功確認,也可以返回它.從緩存器構(gòu)造響應(yīng)緩存器的目的是存儲響應(yīng)請求的信息來響應(yīng)后面的請求.再很多情況下,緩存器僅返回響應(yīng)的適當部分給請求者.如果緩存器保有一個基于前面請求的實體,它可能必須將其與新響應(yīng)合并.端到端和Hop-by-hop報頭為定義緩存器行為,我們將報頭分成兩類:

端到端報頭和hop_by_hop報頭（僅對簡單的傳輸層連接有意義，不被緩存,也不被代理服務(wù)器向前傳遞）不可更改報頭HTTP1.1的某些特征,如分類鑒定,基于某一端到端報頭值.一透明代理不能修改端到端報頭除非報頭要求或明確許可.傳輸代理不能修改下列各項，如果他們不存在，也不能添加。

聯(lián)合報頭（CombiningHeaders）但緩存向服務(wù)器發(fā)出確認請求,若服務(wù)器回復(fù)304或206響應(yīng),則緩存器構(gòu)造響應(yīng)回復(fù)給請求客戶.聯(lián)合字節(jié)范圍一條響應(yīng)可能僅傳送一條正文的一部分，經(jīng)過幾次這種傳送，一緩存器可能會收到同一條正文的好幾部分

如果緩存器已經(jīng)收到正文的一部分，且又收到了另一部分，緩存器可以將新收到的內(nèi)容與已有內(nèi)容合并，當所有收到的響應(yīng)及緩存實體含有強確認時。緩存談判響應(yīng)使用服務(wù)器驅(qū)動內(nèi)容轉(zhuǎn)讓,由響應(yīng)中的變化報頭區(qū)說明,改變了緩存器能用響應(yīng)回復(fù)后續(xù)請求的條件和過程共享和非共享緩存出于安全和保密考慮，有必要區(qū)分共享和非共享緩存。非共享緩存是僅供一個用戶使用的緩存器，此種情況下，可用性由適當?shù)陌踩珯C制控制。錯誤和不完全響應(yīng)緩存行為緩存器收到不完整響應(yīng)時也可以存儲它，但是必須把它看作部分響應(yīng)。GET和HEAD的副作用：除非服務(wù)器明確禁止緩存它們的響應(yīng)，對任何資源應(yīng)用GET和HEAD算法，如果響應(yīng)曲子緩存器，都不會引起能導(dǎo)致錯誤的副作用。他們確實有副作用，但緩存器在決定緩存時不必考慮。緩存器總是“看源服務(wù)器的臉色行事”。刷新或刪除后的無效性某些算法對源服務(wù)器資源的操作將使一個或多個已存在的緩存實體不可用，即為，雖然他們還是“新鮮”的，但卻不能準確反映源服務(wù)器想回復(fù)給請求的信息。HTTP協(xié)議無法保證所有此類實體均被標明無效。強制寫通過（Write-Through）所有可能對源服務(wù)器資源進行修改的算法都要寫給源服務(wù)器。這通常包括所有算法除了GET和HEAD。緩存在將此種請求轉(zhuǎn)給內(nèi)地服務(wù)器并獲得相應(yīng)答復(fù)前不能對請求客戶做出響應(yīng)。緩存替換如果收到一個新的響應(yīng)，它的同源響應(yīng)均已被緩存，緩存器就要用新響應(yīng)回復(fù)當前請求，且將其插入緩存器存儲區(qū)，并用其回復(fù)所有被退回的舊響應(yīng)。歷史紀錄用戶代理經(jīng)常使用歷史體制來重新獲得以前的實體。歷史機制和緩存是不同的，尤其歷史對資源的當前狀態(tài)是不透明的，更準確地說就是歷史紀錄明示用戶在獲得資源時看到了什么。默認情況，過期時間不用在歷史機制中。若實體仍然在存，即使它過期歷史機制仍可以顯示它，除非用戶明確提出要代理刷新過期紀錄。這并不能解釋為禁止歷史體制告訴用戶事情已經(jīng)過時。報頭域定義本節(jié)定義了所有HTTP/1.1種標準頭域的語法和語義。對于實體頭域，發(fā)送者和接收者指的是客戶端和服務(wù)器，它是由實體的發(fā)送和接收者來定義的。接受（Accept）接受請求報頭區(qū)域可以同作詳細說明特定對于響應(yīng)來說可以接受的媒體形式.接受報頭可以同作說明,請求對于一小組需要的形式來說是受限的,就像在為了內(nèi)嵌圖像的請求的情況下一樣.

接受-字符集（Accept-Charset）接受-字符集請求報頭區(qū)域可以用來指出什么特性裝置可以為響應(yīng)所接受.這個區(qū)域允許有能力理解更復(fù)雜或者是特定目的特性的裝置的客戶通知給在那些特性裝置中有能力描述文檔的服務(wù)器服務(wù)器是否具有上述所述的能力.接收編碼(Accept-Encoding)接收編碼(Accept-Encoding)請求報頭域和接收(Accept)相似,但限定響應(yīng)中可接收的內(nèi)容碼(content-codings)認可術(shù)語認可術(shù)語請求報頭區(qū)與認可是相近的，但規(guī)定了一套自然語言用來響應(yīng)請求.術(shù)語接收范圍(Accept-Range)接收范圍(Accept-Range)響應(yīng)報頭域允許服務(wù)器給出對資源請求的接收范圍:年齡（Age）Age響應(yīng)報頭域表示發(fā)送者對傳輸時間的估計,既然響應(yīng)是由源服務(wù)器產(chǎn)生的.假如緩存的響應(yīng)沒有超過它的壽命,則認為它是有活力的(fresh).13.2.3節(jié)說明了Age值的計算.允許（Allow）許(Allow)實體報頭域中列出了由請求指定資源支持的幾種方法--URI。這一報頭域的目的嚴格限于通知接收者與資源相聯(lián)系的方法有哪些。允許報頭域必須出現(xiàn)在405（方法不被允許）應(yīng)答中。授權(quán)（Authorization）用戶代理往往希望服務(wù)器自我驗證,但在收到401響應(yīng)后則沒有必要了.用戶代理通過包括Authorization請求報頭域的請求那樣做.Authorization請求報頭域的值由包含用戶代理驗證信息的信任狀所組成,這些用戶代理處于請求資源的領(lǐng)域.緩存-控制（Cache-control）緩存-控制通用-報頭域用于標明請求/應(yīng)答鏈上所有緩存機制必須遵守的指令。這些指令規(guī)定了一些意在預(yù)防緩存對請求或應(yīng)答造成不良影響的行為。它們通常覆蓋了缺省的緩存算法。緩存指令是單方向的，因為請求中指令的存在并不意味著應(yīng)答中也會有同樣的指令。何謂可緩存的缺省情況下，若請求方法，請求報頭域和應(yīng)答狀態(tài)指明了應(yīng)答為可緩存的，則它就是可以緩存的。哪些可被高速緩存機保存不保存"不保存"指令的目的在于防止無意中泄露或滯留了敏感信息（比如存在備用磁帶上了）。"不保存"指令適用于整個報文，可在請求或應(yīng)答中發(fā)送。

對基本過期失效機制的改進實體的過期時間可由原服務(wù)器的"過期"報頭指定。或者，它也可由應(yīng)答中的"最大-年齡"指令說明。當被緩存的應(yīng)答含有"最大-年齡"緩存-控制指令時，應(yīng)答若現(xiàn)有年齡大于出現(xiàn)對同一資源的新請求中所給年齡值（以秒為單位）則被視為陳舊。應(yīng)答中的"最大-年齡"指令意味著該應(yīng)答是可緩存的（如，"公共"），除非存在其他更嚴格的緩存指令。緩存重新確認有效和重載控制。有時用戶代理可能希望或出于需要堅持讓緩存機與原服務(wù)器之間重新確認緩存條目的有效性（而不只是通向原服務(wù)器的傳輸路徑中的下一高速緩存機），或是從原服務(wù)器處重載緩存條目。端到端的重新確認有效手續(xù)在緩存機或原服務(wù)器高估了緩存應(yīng)答的過期時間時可能需要。端到端重載在緩存條目由于某些原因被侵蝕時可能需要。不得轉(zhuǎn)換指令中轉(zhuǎn)緩存機（代理服務(wù)器）的實現(xiàn)者們發(fā)現(xiàn)轉(zhuǎn)換某些實體正文的媒體類型是很有用的。然而，當這些轉(zhuǎn)換應(yīng)用于某些應(yīng)用的實體正文時，會引發(fā)嚴重的操作方面的問題。所以，如果報文包括了"不得轉(zhuǎn)換"指令，中轉(zhuǎn)緩存機或代理服務(wù)器就不得改變受"不得轉(zhuǎn)換"指令影響的報頭。這意味著緩存機或代理服務(wù)器不得改變由這些報頭定義的實體正文的任何方面，包括實體正文值本身。緩存控制擴展緩存-控制報頭域可通過一個或多個緩存-擴展標志的使用來實現(xiàn)擴展。其中每一標志都賦予一可選的值。信息性的擴展（那些無須改變緩存機行為的）可以不經(jīng)改變其他指令的句法而添加。連接連接這一概括報頭域允許發(fā)送者指定某一特定連接中的選項設(shè)置，且不得由代理服務(wù)器在以后的連接中傳送。連接報頭遵循如下語法：連接="連接""："1#（連接-標志）

連接-標志=標志

內(nèi)容編碼"內(nèi)容編碼"實體報頭域是作為媒體類型的修正。此域存在時，其值表明對實體正文采用了何種附加的內(nèi)容編碼，從而須采用何種解碼機制以獲取"內(nèi)容類型"報頭域中指出的媒體類型。"內(nèi)容編碼"的主要目的是使文件可以在不喪失其基本媒體類型身份的同時被壓縮。

內(nèi)容語言內(nèi)容語言實體報頭域描述了實體面向的受眾的使用語言。請注意，這不一定等同于實體正文中用到的所有語言。內(nèi)容長度內(nèi)容長度實體報頭域按十進制或八位字節(jié)數(shù)指明了發(fā)給接收者的實體正文的大小，或是在使用HEAD方法的情況下，指明若請求為GET時將發(fā)送實體正文的大小。內(nèi)容位置內(nèi)容位置可用來在從一獨立于請求資源的URI的位置訪問實體時提供報文中實體的資源位置。服務(wù)器應(yīng)根據(jù)應(yīng)答實體為此變量提供一內(nèi)容位置；尤其是在資源和多個實體相聯(lián)系，而這些實體各享獨立位置，可被分別訪問時，服務(wù)器應(yīng)為特定的返回變量提供內(nèi)容位置。內(nèi)容-MD5內(nèi)容-MD5實體報頭域是實體正文的MD5摘要，以期提供端到端的實體正文的報文完整性檢驗（MIC）。內(nèi)容-范圍內(nèi)容-范圍實體報頭與部分實體正文一起發(fā)送，用于指明在全部實體正文中，那一部分正文應(yīng)該應(yīng)用于何處。內(nèi)容-類型容-類型實體報頭域指明發(fā)給接收者的實體正文的媒體類型，或在HEAD方法中指明若請求為GET時將發(fā)送的媒體類型。

日期日期頭域描述消息產(chǎn)生的日期和時間，它和RFC822中的ORIG-DATE語義一樣。它必須用RFC1123[8]數(shù)據(jù)格式發(fā)送。

沒有時鐘的原服務(wù)器的運作一些原服務(wù)器的執(zhí)行可能沒有可用的時鐘。一個沒有時鐘的原服務(wù)器不能指定一個應(yīng)答斷開或維持修改的值除非這些值是和系統(tǒng)或用戶可靠的時鐘資源相關(guān)聯(lián)的。它可以指定一個知道的終止值，在服務(wù)配置的時間或以前，這是過去的（這允許應(yīng)答的預(yù)終止而不保存每個資源分離的分割值）。ETagEtag應(yīng)答報頭域提供了請求變量的當前實體標簽。實體標簽可用于比較來自同一資源的不同實體。期望期望請求報頭域用于指明客戶機需要特定的服務(wù)器行為。過期（Expire）"過期"實體報頭域給出了在何日何時之后應(yīng)答即被視為陳舊。除非首先經(jīng)原服務(wù)器（或含有此實體較新拷貝的中介代理服務(wù)器緩存）確認為有效，緩存一般不會返回陳舊的緩存目錄值FromFrom請求報頭域，如果給定的話，應(yīng)該（SHOULD）包括控制請求用戶代理的人的互聯(lián)網(wǎng)E-MAIL地址。這個地址應(yīng)該（SHOULD）是適用于機器的主機（Host）主機（Host）請求報頭域說明了正在請求的資源的互聯(lián)網(wǎng)主機和端口號，就包括在用戶或者提交的資源指定的源URI中（一般是一個HTTPURL,就像在3.2.2部分描述的）。Host域的值必須（MUST）代表源URL給定的源網(wǎng)關(guān)或者服務(wù)器的授權(quán)命名。這允許源服務(wù)器或網(wǎng)關(guān)區(qū)分內(nèi)部不明確的URL，例如單個IP地址上有多個主機域名的服務(wù)器的根“/”URL.If-Match

If-Match報頭域是用一種方法使得它是有條件的。由以前從源獲得的一個或更多實體的客戶機能夠校驗?zāi)切嶓w中的一個現(xiàn)在包括在If-Match報頭域的一系列聯(lián)合的實體標簽。這種特征的目的是允許用對報頭進行最少量處理的方法對高速緩存信息進行有效的修正。它也用來在更新請求時防止源的錯誤版本無意識的修改。作為一種特殊情況，“*”匹配任何現(xiàn)有源的實體。

If-Modified-Since用一種方法使If-Modified-Since請求報頭域被用來使得如果請求的變量自從這個域說明的時間以來沒有被修改過，實體將不會從服務(wù)器返回；相反的，將返回304響應(yīng)（沒有修改的）而沒有任何報文實體。

“如果不匹配”（If-None-Match）If-None-Match報頭區(qū)伴隨一種使其條件化的算法使用。一個已從源端獲得實體的客戶可以校驗得出：這些實體沒有通過在If-None-Match報頭區(qū)標明相應(yīng)實體標簽而流通。此特征的目的是達到最小代價的高效緩存信息刷新。它也可以防止一些算法無意中修改客戶認為不存在而實際存在的資源。If-Range如果客戶機在其緩存中有實體的部分拷貝，并希望向緩存中添入整個實體的更新后拷貝，它可以在條件GET（If-Unmodified-Since和If-Match兩者兼用或只取其一）中使用范圍請求報頭域。然而，若由于實體已被修改而導(dǎo)致條件不滿足，客戶機就需要再次發(fā)出獲取當前整個實體正文的請求。If-Unmodified-SinceIf-Unmodified-Since請求報頭域用來使某方法變?yōu)闂l件的。若請求的資源在此域中指定的時間之后即未被修改，則服務(wù)器應(yīng)按If-Unmodified-Since報頭不存在的方式執(zhí)行所請求的操作。上次修改上次修改實體報頭域指明原服務(wù)器認為的變量上次被修改的日期和時間。上次修改="上次修改""："HTTP-日期位置（Location）除了應(yīng)用于關(guān)于請求完成或新資源確認的請求