本備忘錄的狀態
本備忘錄為Internet定義了一個實驗的協議。它本不屬于任何已具體說明的Internet標準。
仍需進一步的探討和改進。此備忘錄的發行是無約束的。

版權聲明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

IESG注釋
這篇文章最初是作為推薦標準而提出的。但是，由于最終確認時的綜合考慮以及在HTTP工
作組中，它是作為一篇實驗性文檔而提出的。這并不是說這篇文章有任何技術上的缺陷；更
恰當地說，這更全面地涉及到是否這篇文章確實在HTTP的變革方面提出了與社會上大多數人
不同的新的見解。再此決定之前需要更多的研究和討論。

同樣需要注重的是當HTTP被用作其它協議的基礎時，它可能有必要和應該適當地用到一些
其它擴展的機制，增加或代替一些東西，在這里會具體說明。因此這篇文章不應該被看作是
擴展HTTP的藍圖，但它所具體說明的機制可能在具體情況中非常有用。

概要
應用程序的廣泛延伸已經提出了各式各樣的HTTP協議的擴展。當前的協作橫跨了一個巨
大的范圍，包括分布式創造，協作，打印，和細微的程序響應機制。這些HTTP的擴展并不是并
列同等的，因為還沒有任何的框架標準來定義它們，因此它們便相互獨立起來。這篇文章描述
了一個一般性的HTTP擴展機制，試圖緩和這些獨立的協議和公眾規范之間的矛盾，并讓那些使
用HTTP協議的客戶端，服務器和代理兼容這些擴展的應用程序。這個提議用全球化獨一無二的
標識符連接了每一個擴充，而且用HTTP的標題字段來顯示這些擴展的標識符，并講述了與他們
有關的通訊延伸的信息。



目錄
1.序論 3
2.協定表記法 3
3.擴展申明 3
3.1標題字段前綴 4
4.擴展標題字段 5
4.1End-to-End擴展 5
4.2Hop-by-Hop擴展 5
4.3標題字段擴展響應 6
5．強制HTTP請求 6
5.1強制請求的實現 7
6.強制HTTP響應 7
7.510不擴展 8
8.發布擴展 8
9.緩沖考慮 8
10.安全考慮 9
11.參考書目 9
12.感謝 9
13.作者地址 9
14.交互式協議概要 10
15.例子 11
15.1使用源服務器的代理 11
15.2通過HTTP/1.1PRoxy的源服務器用戶代理 11
15.3通過HTTP/1.0Proxy的源服務器用戶代理 12
全部版權陳述 13
感謝 14



1.序論

這個提議原意是用來緩和私人協定和大眾規范的沖突；并調和由軟件構成的HTTP客戶與服務器
之間的動態擴展矛盾。其擴展能力的方式如下：
o擴展單一的HTTP信息；
o引入新的符號；
o為新的應用程序開起源HTTP協議；
o協議間的轉換，這些協議一旦開啟，就能在原始的一堆協議中不受約束的運行；
這個提議預計在如下地方起作用：
o一些當事人創建并具體說明了一個擴展；他們指定給其一個全球內唯一的URI，而且制定了
在這個地址可用擴展的一個或多個表現法（見第8節）。
o一個實現此擴展機制（后來稱為代理）的HTTP用戶或服務器通過在HTTP信息中的擴展聲明所
涉及到的URI定義了這個擴展的用途（見第3節）。
o實現擴展聲明的HTTP應用程序（后來成為終端）能演繹怎樣合適的中斷基于擴展聲明的延伸
信息。
這個建議使用了HTTP/1.1的特性，并通過讓擴展程序與現有的HTTP應用程序共存的方式實現與
HTTP/1.0相兼容。應用程序實現此建議必須基于HTTP/1.1（或者是HTTP的更高版本）。

2.協定表記法
這篇說明書使用了與RFC2068[5]相同的表記法慣例和基本分析構架。非凡是BNF的結構記法，
例如文章中的"token","quoted-string","Request-Line","field-name",和
"absoluteURI"，與RFC2068[5]所解釋的一樣。
文檔中的要害字"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT",
"SHOULD","SHOULDNOT","RECOMMENDED","MAY",和"OPTIONAL"與RFC2119[6]所
解釋的一樣。
這個建議不同于具體說明的URLs[8]的特點，不能潛在地用URNs來表達（見第8節）。
因此，更多一般性的術語URI[8]貫穿于這篇規范書的始終。

3.擴展申明
擴展申明適用于指示已經適用于一個信息的擴展和可能保留的標題namespace的一部分，藉著
標題字段的前綴來進行識別（見3.1）。這個區段定義了擴展聲明的本身；第四節定義了正在使用
擴展聲明的標題字段的設定。
這個規范并不定義任何適用于信息擴展的分枝或是兩個擴展在邏輯上能或是不能在同一信息中
共存。它只是一個用來描述被應用的擴展和最終接受者為了在信息中合理地解釋擴展聲明可能或必
須做的一個框架。
擴展聲明的語法如下：
ext-decl=<">(絕對URI字段名)<">
[namespace][decl-擴展]

namespace=";""ns""="標題前綴
標題前綴=2*DIGIT

decl-擴展=*(decl-ext)
decl-ext=";"表征["="(表征引用串)]
一個擴展被一個絕對的全球獨一無二的URI或字段名所識別。一個字段名必須在IETF標準方面唯
一的敘述一個標題字段的定義，見RFC[3]。一個URI能清楚地從冒號（“：”）標記識別一個字段名。
標題名的支持如同擴展提供了使分散的擴展到擴展的轉變策略一樣，按照IETF標準定義RFC映射在全
球獨一無二的URI空間和在IETF標準定義RFC的特征之間，這個特征已按照第8節描述的方法被定義。
擴展聲明的例子是：
“http://www.company.com/extension”；ns=11
“Range”
一個代理人可能使用decl-擴展機制來包含可選擇的擴展聲明參數但不能保證這些參數能被接
受者清楚地辨認出來。一個代理人不能使用decl-擴展來通過擴展例證數據，這些數據可能通過標題
字段前綴的值進行驗證（見第3.1節）。為被識別的decl-ext參數應該被忽略并且在轉寄擴展聲明是
不能被代理移動。

3.1標題字段前綴
標題字段前綴是一個動態產生的串。所有在信息中與此串相匹配的標題字段，使用串的前綴匹
配，屬于此擴展聲明。標題字段前綴答應一個擴展聲明動態地保留在一個協議信息中的標題空間的
子空間，為了避免標題字段名的沖突并答應多樣化的聲明使用適用于相同信息的沒有沖突的同一擴
展。使用標題前綴的標題字段有如下形式：
前綴標題=匹配的前綴字段名
匹配的前綴=標題前綴“-”
線性的白色空間（LWS）不能在標題前綴與“-”或匹配的前綴與字段名之間被使用。串的前綴
匹配算法則被用于匹配的前綴串。
使用數字的一個組合的前綴格式和“-”保證沒有擴展生命能保留全部的標題字段名空間。標題
前綴機制已超過了其他的引用參數實現交互擴展的解決辦法，因為它的建立是基于或因此考慮到使
得新的擴展與現有的HTTP特征更輕易整合的標題。
代理不答應在同一信息中重復地使用標題前綴，除非擴展明確規定（見第4.1節的一個擴展聲明
的最終接受者的討論）。
客戶端在產生標題前綴值時，就像在響應中多樣化的標題字段的簡便用途一樣，在此多樣化被
認為是需求擴展聲明的功能，應該盡可能地一致（見[5]，第13.6節）。
包含在變化的標題字段值中的前綴標題的標題字段的服務器必須同樣包含相應的擴展聲明的域
名，作為其值的一部分。例如，假如一個響應依靠于16-use-transform的標題字段的值，而這個字
段在請求中已被可選擇的擴展聲明所定義，那么在響應中的多樣化的標題字段可能如下：
Vary：Opt，16-use-transform
需要注重的，標題前綴的一致性不是在信息中包含一個擴展聲明的替代：帶標題前綴值的標題
字段在同一信息中的擴展聲明中不被定義，在這篇規范書中也不被定義。
標題前綴值的例子如下：
12
15
23
舊的應用軟件可能介紹獨立于此擴展機制的標題字段，就可能造成與前綴機制描述的標題字段
的潛在沖突。為了使這種風險最小化，前綴必須包含至少兩個阿拉伯數字。

4.擴展標題字段
這個提議介紹了兩種類型的擴展聲明的實力：強制性的和可選擇性的，和這兩種類型擴展聲
的應用范圍：Hop-by-Hop及End-to-End（見第4.1節與第4.2節）。
一個強制的擴展聲明指出最終接受者在處理信息或是提交錯誤報告時必須參考并使用由擴展給
定的規則(見第5節和第7節)。
一個可選擇的擴展聲明指出擴展最終接受者在處理信息時可能參考或使用由擴展聲明給定的規
則，或是完全忽視擴展聲明。代理也許就不能識別是否最終接受者明白通過可選擇性擴展或是簡單
地忽視擴展聲明后擴展所涉及的。
擴展的實力與范圍的合并具體說明了一個2*2的矩陣，由于四個新的全面的HTTP標題字段而十分
聞名：Man,Opt,C-Man,andC-Opt。（見第4.1節與第4.2節；同樣在附錄14中，有一張源服務器
與代理的交互作用表。）
這標題字段是普通的標題字段，就像擴展實際應用于HTTP信息中所描述的一樣。假如適當的話，
可選擇的聲明也許能被應用于任何的HTTP信息（見第5節，怎樣將強制擴展聲明應用于請求中和第6
節，在響應中怎樣應用它們）。
4.1End-to-End擴展
End-to-End聲明必須被傳送帶擴展的最終接受者。全面的標題字段Man和Opt是End-to-End標題
字段并被如下定義：
強制=“Man”“：”1#ext-decl
可選擇=“Opt”“：”1#ext-decl
例如
HTTP/1.1200OK
Content-Length:421
Opt:"http://www.digest.org/Digest";ns=15
15-digest:"snfksjgor2tsajkt52"
……
一個End-to-End強制擴展聲明的最終接受者必須運用擴展聲明，像第5節和第6節所描述的一樣。

4.2Hop-by-Hop擴展
Hop-by-Hop擴展聲明只對單一的HTTP連接有意義。在HTTP/1.1，C-Man，C-Opt和所有被
C-Man,C-Opt定義的由匹配標題前綴值的標題字段必須被連接標題字段所保護。也就是說，這些標題
字段將被包含，作為連接標題字段指示（見[5]，第14.10節）。這兩個標題字段有如下語法：
c-mandatory="C-Man"":"1#ext-decl
c-optional="C-Opt"":"1#ext-decl
例如
M-GET/HTTP/1.1
Host:some.host
C-Man:"http://www.digest.org/ProxyAuth";ns=14
14-Credentials="g5gj262jdw@4df"
Connection:C-Man,14-Credentials
一個Hop-by-Hop強制擴展聲明的最終接受者必須運用擴展聲明，像第5節和第6節所描述的一樣。

4.3標題字段擴展響應
兩個標題字段擴展響應被用于指出一個包含被最終接受者實行的強制擴展聲明的請求，像第5.1
節所描述的一樣。標題字段擴展響應專門被用于確認擴展的服務，并不能攜帶其他任何信息。
Ext標題字段被用于指示所有在請求中被實行的End-to-End強制擴展聲明：
ext=“Ext"“：”
C-Ext標題字段響應別用于指示所有在請求中被實行的Hop-by-Hop強制擴展聲明：
c-ext=“C-Ext"“：”
在HTTP/1.1中，C-Ext標題字段必須被標題連接所保護（見[5]，第14.10節）。
Ext和C-Ext標題字段并不互相排斥；它們能在同一信息中同時出現，就像第5.1節所描述的
一樣。

5．強制HTTP請求
一個HTTP請求，假如它包含至少一個強制擴展聲明（使用Man或C-Man標題字段），就被稱為
強制請求。強制請求的方法名必須被加上前綴“M-”。例如，一個客戶端可能在HTTP輸出中表示管
理約束權限如下：
M-PUT/a-resourceHTTP/1.1
Man:"http://www.copyright.org/rights-management";ns=16
16-copyright:http://www.copyright.org/COPYRIGHT.Html
16-contributions:http://www.copyright.org/PATCHES.html
Host:www.w3.org
Content-Length:1203
Content-Type:text/html
<!doctypehtml...
一個遵守這篇規范的終端接收者受到強制請求必須按如下列出的步驟處理請求：
1.識別所有的強制擴展聲明（包括Hop-by-Hop和End-to-End）；服務器可能忽視可選擇
聲明，并不影響處理HTTP信息的結果；
2.檢查1）中已識別的擴展而且決定他們是否用來支持此信息。假如不，返回510（無擴展）
狀態碼（見第7節）；
3.假如2）的結果并不是返回510（無擴展）狀態碼，那么按照擴展的語義和已存在的在
HTTP/1.1[5]中或HTTP的更高版本中具體說明了的HTTP方法名處理請求。HTTP方發明
可以通過忽略方法名前綴“M-”來獲得。
4.假如3）中的賦值成功而且強制請求完成。服務器必須像第5.1節所定義的作出響應。
一臺服務器不能不了解和服從在請求中的所有強制擴展就實現請求。
一個不作為強制擴展聲明終端用戶的代理在推進信息時不能移動擴展聲明或是方法名前綴“M-”
（見第5.1節，在強制擴展聲明已經實現后怎樣進行探測）。
一臺服務器接收到一條HTTP/1.0（或更早版本的HTTP）信息，包含了連接標題必須，對此字段
中的每一個連接記號，像連接記號用同樣的名字移動并忽視任何來源于信息的標題字段。
一臺服務器收到沒有任何強制擴展聲明來遵從并包含方法名前綴“M-”的強制擴展聲明，必須
返回510（無擴展）響應。
擴展名“M-”被此建議保留并不能用于其它的HTTP擴展。

5.1強制請求的實現
一臺服務器不能要求實現任何擴展請求，除非它明白并能服從請求中的所有強制擴展聲明。這
一部分定義了一個以某種方式把信息傳送給客戶端的機制，它能與已存在的HTTP應用程序共同實行
并能阻止損壞的服務器發送錯誤的信息，不理解方法就用200（OK）響應完成擴展請求。
假如任何End-to-End強制擴展聲明是在已完成的擴展中，那么服務器就必須在響應中包含一個
Ext響應標題字段。為避免一個Ext響應標題字段不注重地在一個HTTP/1.1高速緩沖寄存器中緩沖，
響應必須包含無緩沖，緩沖控制指示。假如響應以其他方式進行緩沖，無緩沖，緩沖控制指示應該
被限制在Ext標題字段內起作用：
HTTP/1.1200OK
Ext:
Cache-Control:no-cache="Ext"
...
假如強制請求已經被一個HTTP/1.0中介代理傳送，接著這就被直接地在請求線指示或是通過標
題字段的HTTP/1.1地使用。假如真是這樣，服務器必須包括一個等于或早于數據標題字段值的失效
標題字段（見第9節，緩沖考慮的討論）：
HTTP/1.1200OK
Date:Sun,25Oct199808:12:31GMT
EXPires:Sun,25Oct199808:12:31GMT
Ext:
Cache-Control:no-cache="Ext",max-age=3600
...
假如任何的Hop-by-Hop強制擴展聲明在已實現的擴展中，那么服務器必須在響應中包含一個
C-Ext響應標題字段。C-Ext響應標題字段必須被連接標題字段所保護（見[5]，第14.10節）。
HTTP/1.1200OK
C-Ext:
Connection:C-Ext
需要注重的是，Ext和C-Ext標題字段并不互相排斥；它們能在完成強制請求時，包括Hop-by-Hop
和End-to-End強制擴展聲明，同時在一個響應中出現。

6.強制HTTP響應
一臺服務器在HTTP響應中并不包含強制擴展聲明，除非它是給一個強制HTTP請求做的應答，
而且這個請求的定義答應強制響應或是服務器更先進足以使接受者操縱擴展響應。一臺服務器可能
在任何HTTP響應中包含可選擇的擴展聲明（見第4節）。
假如客戶是包含強制擴展聲明的強制HTTP響應的終端接收者，客戶或者不明白或者不想用這擴
展聲明，那么它應該放棄完全響應，把它視為一個500（Internet服務器錯誤）響應。

7.510不擴展
訪問資源的機制并不在請求中。服務器應該返回所有發出擴展請求的客戶的必要信息。擴展怎
樣具體地告知用戶并不在這篇規范的討論范圍。
假如510響應包含了在初始請求中不存在的擴展信息，那么假如有理由相信它能根據510響應
中提供的信息通過修改請求來實現擴展機制，客戶端就有可能重復地發出請求。相反的，客戶端可
能對用戶呈現出任何包含在510請求中的實體，這個實體可能與診斷信息相關。

8.發布擴展
當擴展協議的具體說明應該在擴展標識符的地址發布時，這篇規范就不需要它。唯一絕對的需
求是擴展標識符應該是全球獨一無二的標識符，而且這個獨特的名字被用于獨特的語義。
同樣的，不需要應用程序來嘗試包含在擴展聲明中的擴展標識符的解析工作。唯一絕對的需求
是應用程序不需與它不能識別的擴展（不管它是否嘗試解決擴展標識符）保持一致。這篇文檔沒有
為多久或多頻繁一個應用程序可能嘗試解析擴展標識符提供任何方針。
擴展標識符與規范的結合可能由發布規范來完成，這篇規范就涉及到擴展標識符。
強類推薦擴展標識符的完整性和持續性應該在擴展的壽命中被毫無疑問的維護和保持。應該注
意不發布涉及到相同名字的有沖突的規范。即使當擴展規范在URI地址是可利用的，還必須小心在
這個URI地址，擴展規范不隨時間而發生變化。一個代理可能把標識符與老的語義結合，其它的可
能把它與心的語義結合。
擴展標識符的能在如下排列的不同表現中可利用：
o由擴展語義定義的易讀規格（見[7]中的例子），
o由擴展定義的實現語義的可下載的代碼，
o由擴展提供的正式接口描述，
o由擴展語義定義的機器可讀規格。
例如，一個執行規范的軟件組件可能向人們易讀的規格一樣（通過商定的內容所區別）借居在
相同的地址。人們易讀的表現法適用于證實擴展和鼓勵使用，在軟件的組件答應客戶端及服務器的
動態擴展。

9.緩沖考慮
使用由這篇文檔定義的句法結構的擴展的用途可能在HTTP響應信息的可緩沖性，除了在第5.1
節所描述的，有附加的含義。
擴展信息的創始人應該能夠從擴展機制中決定是否擴展的存在與響應信息的緩存約束相抵觸。
假如一個擴展在響應的可緩沖性方面不需要很緊的約束，創造者必須包含適當的有緩沖標題字段的
組合（緩沖控制，變更，期限），與有擴展語義的組合的必須級別所對應。

10.安全考慮
動態的擴展便利裝置，如簡介中描述的一樣，包括了某一方公司（執行的提供者）所寫的軟件
必須在另一個權威機構（生產主機軟件的公司）下執行。這就使得主機公司對各式各樣的由提供者
進行攻擊的木馬開放，或是偽裝在供給商名下執行的惡意的第三方公司。可以參考，RFC2046[4]中
的例子，第4.5.2節關于這種風險的討論。

11.參考書目
[1]Crocker,D.,“ARPAInternet文本信息的格式標準”，STD11,RFC822,1982年8月。
[2]Berners-Lee,T.,Fielding,R.與H.Frystyk,“超文本傳輸協議——HTTP/1.0”，
RFC1945,1996年5月。
[3]Bradner,S.,“Internet標準方法——修訂3”，BCP9,RFC2026,1996年10月。
[4]Freed,N.與N.Borenstein,“多用途的Internet郵件擴展（MIME）第二部分：媒介類
型”，RFC2046，1996年11月。
[5]Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.與T.Berners-Lee,“超文本傳輸
協議——HTTP/1.1”，RFC2068，1997年三月。
[6]Bradner,S.,“要害字用于使用在RFCs指出要求水平”，BCP14,RFC2119,1997年3
月。
[7]Masinter,L.,“超文本CoffeePot控制協議(HTCPCP/1.0)”，RFC2324，11998年4
月。
[8]Berners-Lee,T.,Fielding,R.與L.Masinter,“統一資源標識符URI):普通語法”，
RFC2396，1998年8月。
[9]Nielsen,H.,Connolly,D.與R.Khare,“PEP–HTTP擴展機制”，正在發展中。

12.感謝
RoyFielding,RohitKhare,YaronY.Goland,和KoenHoltman，非凡感謝他們在這篇規范
書中所有段落注釋中所作出的努力。同樣感謝JoshCohen,RossPatterson,JimGettys,Larry
Masinter，和所有與PEP[9]有關的人。
所有環球網協會（W3C）職員的貢獻是HTTP活躍性的一部分(見
“http://www.w3.org/Protocols/Activity”）。

13.作者地址
HenrikFrystykNielsen
微軟公司
1MicrosoftWay
Redmond,WA98052,USA

EMail:frystyk@microsoft.com
PaulJ.Leach
微軟公司
1MicrosoftWay
Redmond,WA98052,USA

EMail:paulle@microsoft.com

ScottLawrence
AgranatSystems,Inc.
5ClocktowerPlace,Suite400
Maynard,MA01754,USA

EMail:lawrence@agranat.com

14.交互式協議概要
下面的表格總結了適應或不適應HTTP代理和源服務器的強制建議的實力與范圍標準的成果。這
個總結預期是作為這篇文章的向導和索引，但有必要隱藏和不完善。這個總結不應該完全獨立于這
篇規范而被使用或是參考。
表1:源服務器

ScopeHop-by-hopEnd-to-end

Strength可選擇的必須的可選擇的必須的
(可能)(必須)(可能)(必須)

無支持強制標準處理501(不執行)標準處理501(不執行)

無支持擴展標準處理510(不擴展)標準處理510(不擴展)
支持擴展擴展處理擴展處理擴展處理擴展處理


表2:代理服務器

ScopeHop-by-hopEnd-to-end

Strength可選擇的必須的可選擇的必須的
(可能)(必須)(可能)(必須)

無支持強制精簡擴展501(不執行)迅速擴展501(不執行)
或隧道或隧道

無支持擴展精簡擴展501(不執行)迅速擴展迅速擴展

支持擴展擴展處理擴展處理擴展處理擴展處理
并精簡并精簡可能精簡可能精簡

15.例子
下面的例子演示了HTTP/1.1請求與響應中強制使用的各種可能的用途。不需要過多解釋的例子
的信息就被省略了（指文章中的“……”）

15.1使用源服務器的代理
表3：直接指向源服務器的用戶代理
客戶端發出一個帶M-GET/some-documentHTTP/1.1
有可選擇性和強制Opt:“http://www.my.com/tracking”
性擴展的請求Man:http://www.foo.com/privacy
……

通過忽略可選擇響應來接受強HTTP/1.1200OK
制的源服務器。一旦可選擇響Ext:
應被忽略，客戶端在這種情況Cache-Control:max-age=120,no-cache=“Ext”
下不可見。……

表4：有多樣化標題字段的源服務器
發送強制擴展請M-GET/p/qHTTP/1.1
求的客戶端Man:"http://www.x.y/transform";ns=16
16-use-transform：xyzzy
……

接受強制的源服務器HTTP/1.1200OK
但需要基于請求擴展Ext:
聲明的相應的多樣性Vary:Man,16-use-transform
日期:1998年19月25號星期日08:12:31GMT
期限:1998年19月25號星期日08:12:31GMT
Cache-Control:no-cache="Ext",max-age=1000
……

15.2通過HTTP/1.1Proxy的源服務器用戶代理
這兩個例子演示了一個擴展請求怎樣與HTTP/1.1代理相互作用。
表5：HTTP/1.1代理向前擴展請求
發送帶有可選擇性M-GET/some-documentHTTP/1.1
與強制性hop-by-hopC-Opt:“http://www.meter.org/hits”
擴展請求的客戶端C-Man:http://www.copy.org/rights
Connection:C-Opt,C-Man
……

HTTP/1.1代理向前請M-GET/some-documentHTTP/1.1
求并獲取連接標題Via:1.1new
……

請求不包含任何歸屬HTTP/1.1510不擴展
于M-GET方法的源服……
務器失敗

表6：HTTP/1.1代理不向前擴展請求
發送帶有可選擇性M-GET/some-documentHTTP/1.1
與強制性hop-by-hopC-Opt:“http://www.meter.org/hits”
擴展請求的客戶端C-Man:http://www.copy.org/rights
Connection:C-Opt,C-Man
……

HTTP/1.1代理拒絕HTTP/1.1501不執行
傳輸M-GET方法并……
返回錯誤

源服務器從不接受
擴展請求

15.3通過HTTP/1.0Proxy的源服務器用戶代理
這兩個例子演示了在信息路徑上一個擴展請求怎樣同一個HTTP/1.0代理相互作用。
表7：HTTP/1.0代理向前擴展請求
發送一個包含強制M-GET/some-documentHTTP/1.1
擴展請求的客戶端Man:http://www.price.com/sale
……

HTTP/1.0代理傳輸M-GET/some-documentHTTP/1.1
不改變方法的HTTP/1.0Man:http://www.price.com/sale
請求……

源服務器接受聲明并返回HTTP/1.1200OK
200響應和擴展確認。響Ext:
應能在HTTP/1.1緩沖器日期：1998年10月25號星期日08:12:31GMT
中緩沖10分鐘。期限：1998年10月25號星期日08:12:31GMT
Cache-Control:no-cache="Ext",max-age=600
……

表8：HTTP/1.0與HTTP/1.1代理系列
發送帶有一個強制M-GET/some-documentHTTP/1.1
和一個hop-by-hopMan:“http://www.copy.org/rights”
可選擇擴展請求的C-Opt:“http://www.ads.org/noads”
客戶端Connection:C-Opt
……

不改變方法并不遵守M-GET/some-documentHTTP/1.0
連接指示的HTTP/1.0Man:"http://www.copy.org/rights"
代理的向前請求C-Opt:"http://www.ads.org/noads"
連接:C-Man
……

HTTP/1.1代理清除M-GET/some-documentHTTP/1.1
(或忽視)可選擇擴展Man:"http://www.copy.org/rights"
并保持包含標題字段C-Man:"http://www.ads.org/givemeads"
的靜止狀態。同樣添連接:C-Man
加一個hop-by-hop通過:1.0new
……

同樣接受強制擴展的HTTP/1.1200OK
源服務器。響應在Ext:
HTTP/1.0緩沖器中不C-Ext
可緩沖但在HTTP/1.1連接：C-Ext
緩沖器中緩沖1個小時日期:1998年19月25號星期日08:12:31GMT
期限:1998年19月25號星期日08:12:31GMT
Cache-Control:no-cache="Ext",max-age=1000
……

HTTP/1.1代理移動HTTP/1.1200OK
hop-by-hop擴展，Ext:
承認并運送其他響應日期：1998年10月25號星期日08:12:31GMT
期限：1998年10月25號星期日08:12:31GMT
Cache-Control:no-cache="Ext",max-age=600
……

全部版權陳述

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsUChcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurpoSEOf
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.