HTTP遠程變量選擇算法—RVSA/1.0

本備忘錄的狀態
本文檔講述了一種Inte.net社區的Internet標準跟蹤協議，它需要進一步進行討論和
建議以得到改進。請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標準
化程度和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright(C)TheInternetSociety(2001).
摘要
HTTP允許web站點作者在單一URL下放置相同信息的多個版本。透明內容協商是用來
在存取URL時自動選擇最佳變量的一種機制。一個遠程變量選擇算法能用來加速透明協商進
程。這篇文檔定義了1.0版本的遠程變量選擇算法。
目錄
1．介紹 2
2．術語和符號 3
3．遠程變量選擇算法 3
3.1輸入 3
3.2輸出 3
3.3計算總體品質因數 3
3.4確定及不確定的品質值 4
3.5確定結果 5
4．算法的使用 5
4.1使用品質因數為參數劃分等級 5
4.2.1折疊接收報頭元素 6
4.2.2忽略接收報頭 7
4.2.3動態長度請求 7
4.3本地和遠程算法的區別 8
4.3避免主要區別 8
4．3．2解決細微區別 8
5．0安全和隱私考慮 8
6．致謝 9
7．參考文獻 9
8．作者地址 9
9．完整版權說明 9

1．介紹
HTTP允許web站點作者在單一URL下放置相同信息的多個版本。透明內容協商［2］是
用來在存取URL時自動選擇最好版本的一種機制。遠程變量選擇算法能被HTTP服務器用來
為一個協商用戶代理選擇一個最好的變量。通過減少一個請求－響應來回，遠程變量選擇算
法的使用能夠加速透明協商進程。
這篇文檔定義了1.0版本的遠程變量選擇算法。此算法計算請求的接收報頭里是否包含
足夠的信息來進行一個選擇，并且在包含足夠信息的情況下，決定選擇哪一個變量。
2．術語和符號
這篇說明使用HTTP透明內容協商說明［2］中的術語和符號。
3．遠程變量選擇算法
這篇文檔定義了1.0版本的遠程變量選擇算法。為了實現這個定義，服務器可能運行任
何產生相同結果的算法。
注意：根據［2］，服務器也可以返回一個列表響應，而不運行一個遠程算法。因此，任
何時候，服務器只要可以運行一個遠程算法，它就可以運行該算法的部分實現，只要部分實
現在不能計算真實結果時也返回列表響應。
3.1輸入
算法通常為一個特別的請求而運行，這個特別的請求請求一特殊的透明可協商資源。它
將以下信息作為輸入。
1． 資源的變量列表，正如資源的備用報頭所示。
2． （部分）關于這個特殊請求的用戶代理的功能和參數信息，和請求的接收報頭里給
出的一樣。
如果在備用報頭里存在一個回撤變量描述{“fallback.html”},這個算法必須將它解釋為下
面的變量描述{“fallback.html”0.000001}。這個極低的品質因數確保了只有當所有其它
選擇都用盡時回撤變量才會被選中。
3.2輸出
作為它的輸出，遠程變量選擇算法接著將產生合適的動作。存在兩種可能：
選擇響應
接收報頭包含足夠的信息來為可能的用戶代理作出選擇，而且在一個選擇響應中必
須返回一個最佳變量。
列表響應
接收報頭沒有包含足夠的信息為可能的用戶代理作出選擇。必須返回一個列表響
應，這樣就允許用戶代理自己作出選擇。
3.3計算總體品質因數
遠程變量選擇算法的第一步，是計算列表中的個體變量的總體品質因數。
一個變量的總體品質Q的值為
Q=round5(qs*qt*qc*ql*qf)
這里round5是一個函數，它將一個浮點值四舍五入直到小數點后有5個十進制數，參
數qs,qt,qc,ql和qf按如下方式決定。
qs是變量描述中的源品質因數。
qt如果變量描述中沒有類型屬性，或者在請求中沒有接收報頭，媒體類型品質因數
就是1。否則，它就是接收報頭在類型屬性中給媒體類型賦的值。
注意：如果一個類型不能和接收報頭中的任何元素匹配，接收報頭就把這種類型的
品質因數賦為0。
qc如果在變量描述中沒有字符集屬性，或在請求中沒有接收字符集報頭，字符集
品質因數就是1。否則，字符集品質因數就是接收字符集報頭在字符集屬性中給字符集賦
的值。
ql如果在變量描述中沒有語言屬性，或在請求中沒有接收語言報頭，語言品質因
數就是1。否則，語言品質因數就是接收語言報頭在語言屬性中給列出的任何一種語言賦
予的所有的品質因數中的最高值。
qf如果在變量描述中沒有特征屬性，或在請求中沒有接收特征報頭，特征品質因
數就是1。否則，它就是特征屬性的品質退化因數，參見［2］的6.4節。
例如，如果一個變量列表包含變量描述｛“paper.html.en"0.7{type
text/html}{languagefr}｝并且請求包含接收報頭
Accept:text/html:q=1.0,*/*=0.8
Accept-Language:en;q=1.0,fr;q=0.5
遠程變量選擇算法會按下面方式為變量計算一個總體品質:
{"paper.html.fr"0.7{typetext/html}{languagefr}}
|||
|||
VVV
round5(0.7*1.0*0.5)=0.35000
按上面的接收報頭,下面完整的變量列表
{"paper.html.en"0.9{typetext/html}{languageen}},
{"paper.html.fr"0.7{typetext/html}{languagefr}},
{"paper.ps.en"1.0{typeapplication/postscript}{languageen}}
會產生下面的計算式：
round5(qs*qt*qc*ql*qf)=Q
----------------------
paper.html.en:0.9*1.0*1.0*1.0*1.0=0.90000
paper.html.fr:0.7*1.0*1.0*0.5*1.0=0.35000
paper.ps.en:1.0*0.8*1.0*1.0*1.0=0.80000
3.4確定及不確定的品質值
一個計算好的總體品質值既可能是確定的，也可能是不確定的。如果計算時沒有使用
任何接收報頭中的‘*’通配符，并且不需要一個特殊接收報頭不存在，那么它就是確定的。
相反，它就是不確定的。
比如，在這節里，paper.html.en和paper.html.fr的品質值是確定的，paper.ps.en
的品質值是不確定的，因為application/postscript類型和范圍*/*匹配。
確定性可以定義地更正規，如下所示。一個總體品質值Q是確定的，如果在請求信息
按照如下方式改變之后還能計算出相同的品質值Q的話：
1．如果一個接收報頭,接收字符集報頭,接收語言報頭,或接收特征報頭從請求中丟失了,向
這個報頭中加上一個空字段。
2．從接收報頭中刪除任何包含一個通配符‘＊’的媒體域。從接收字符集報頭，接收語言
報頭，和接收特征報頭中刪除所有通配符‘＊’。
這里是另外一個例子，變量｛“blah.html”1｛languageen-gb｝{featuresblebber[x
y]}｝，如果它的接收報頭是
Accept-Language:en-gb,fr
Accept-Features:blebber,x,!y,*和
Accept-Language:en,fr
Accept-Features:blebber,x,*
它的總體品質因數是1并且是確定的
如果接收報頭是
Accept-language:en-gb,fr
Accept-Features:blebber,!y,*和
Accept-Language:fr,*
Accept-Features:blebber,x,!y,*
總體品質因數還是1，但是是不確定的，
3.5確定結果
最優變量，由遠程變量選擇算法決定的，是具有最高總體品質值的變量，或者當有許
多變量具有此相同的最高品質值時，是列表中的第一個具此值的變量。
當下列所有條件都滿足時，遠程變量選擇算法的最終結果是選擇響應：
a． 最優變量的總體品質值大于0。
b． 最優變量的總體品質值是一個確定的品質值。
c． 變量資源和可協商資源相鄰。這個條件的存在確保了一個對選擇響應的安全相關限
制得到滿足。參見［2］的10.2和10.4節。
在所有其它情況下，最終結果都是列表響應。
上面對確定性的要求以一種戲劇性的方式影響對接收報頭的解釋。比如，它使得遠程算
法將報頭
Accept:image/gif;q=0.9,*/*;q=1.0解釋成
‘我接收品質值為0.9的image/gif,并把其它媒體類型的品質類型賦為1.0。如果此信息
不夠我自己作出選擇，就不作選擇而是發送變量列表'。
沒有以上要求的話，解釋就會是
‘我接收品質值為0.9的image/gif，和品質值為1.0的所有其它媒體類型'。
4．算法的使用
這一節討論用戶代理怎樣以一種最佳方式使用遠程算法。這節是非標準化的，把它包括
進來只是出于提供信息的目的。
4.1使用品質因數為參數劃分等級
使用品質因數，用戶代理不僅可以為一個特別接收報頭里的元素劃分等級，而且也能表
示不同接收報頭之間的優先等級。比如考慮下面的變量列表：
{"paper.english"1.0{languageen}{charsetISO-8859-1}},
{"paper.greek"1.0{languageel}{charsetISO-8859-7}}
并且假設用戶選擇“el”而不是“en”，這時用戶代理能使“ISO-8859-1”的品質比“ISO-8859-7”
的高。如果接收報頭是：
Accept-Language:gr,en；q=0.8
Accept-Charset:ISO-8859-1,ISO-8859-7；q=0.6,*
那么遠程變量選擇算法會選擇English變量，因為這個變量的總體品質退化最少。但是如果
接收報頭是
Accept-Language:gr,en;q=0.8
Accept-Charset:ISO-8859-1,ISO-8859-7;q=0.95,*
那么算法就會選擇Greek變量。一般地,品質因數之間差額最大的接收報頭獲得最高優先權。
如果用戶代理允許用戶為一些報頭設置品質因數，同時其它因數都是hard-coded的，它就
應該對hard-coded的因數使用一個低差額，對用戶提供的因數提供一個高差額，所以用戶
設置比內置設置具有更高的優先權。
4.2短請求的構造
在對透明可協商資源的一個請求中，用戶代理不需要發送一個列出所有功能的長接收報
頭。比如，不發送
Accept:image/gif;q=0.9,image/jpeg;q=0.8,image/png;q=1.0,

image/tiff;q=0.5,image/ief;q=0.5,image/x-xbitmap;q=0.8,
application/plugin1;q=1.0,application/plugin2;q=0.9
用戶代理發送
Accept:image/gif;q=0.9,*/*;q=1.0
它能發送短報頭，從而不冒獲得一個次等image/tiff變量的選擇響應的危險。例如，對變
量列表
{"x.gif"1.0{typeimage/gif}},{"x.tiff"1.0{typeimage/tiff}},
遠程算法將為x.gif計算一個確定的總體品質0.9，并為x.tiff計算一個不確定的總體品
質因值1.0。因為最優變量擁有一個不確定的品質值，算法不會選擇x.tiff，而是返回一個
列表響應，在此之后用戶代理的選擇算法會正確地選擇x.gif。最終結果和發送長接收報頭
得到的結果相同。
因此，用戶能改變接收報頭的長度以在首次請求發送速度，和遠程算法擁有足夠信息消除第
二次請求的機會之間獲得最佳平衡。
4.2.1折疊接收報頭元素
這節討論一個列出所有功能和參數的長接收報頭如何被安全地縮短。遠程變量算法按某
種方式設計，使得它總可以這安全地縮短接收或接收字符集報頭，它提取兩個報頭元素
‘A;q=f’和‘B;q=g’并用一個元素‘P;q=m’代替它們，這里P是一個匹配A和B的通配
符類型，m是f和g的最大值。這里是一些例子
text/html;q=1.0,text/plain;q=0.8-->text/*;q=1.0
image/*;q=0.8,application/*;q=0.7-->*/*;q=0.8
iso-8859-5;q=1.0,unicode-1-1;q=0.8-->*;q=1.0
注意上面的個‘;q=1.0’都是可選的，可以忽略：
iso-8859-7;q=0.6,*-->*
對于接收語言，可以安全地將所有具有相同主要標記符的語言域折疊為一個通配符：
en-us;q=0.9,en-gb;q=0.7,en;q=0.8,da-->*;q=0.9,da
也可以安全地將一個語言域折疊為一個通配符，或者將它替代為一個通配符，如果它的主要
標記符只出現一次：
*;q=0.9,da-->*
最后，在接收特征報頭中，每一個特征表達式都能夠被折疊為一個通配符，或者替代為一個
通配符：
colordepth!=5,*-->*
4.2.2忽略接收報頭
根據HTTP/1.1說明［1］，一個接收報頭完全不存在于請求中等價于‘Accept:*/*’。因
此，如果接收報頭被折疊成‘Accept:*/*’，用戶代理可能完全忽略它。包含‘*’的接收字
符集，接收語言，或接收特征也可能被忽略。
4.2.3動態長度請求
一個能進行透明內容協商的用戶代理也能缺省發送短請求。一些短接收報頭為了已存的
使用HTTP/1.0的服務器的利益，也能被包括進來（參見［2］的4.2節）。這是一個例子：
GET/paperHTTP/1.1
Host:x.org
User-Agent:WuxtaWeb/2.4
Negotiate:1.0
Accept-Language:en,*;q=0.9
如果這樣一個作為輸入的缺省請求包含的接收報頭和遠程變量選擇算法不匹配，用戶代理就
能夠發送‘Negotiate:trans’而不是‘Negotiate:1.0’，從而使算法失效。
如果用戶代理發現了，不管是否接收到一個列表或選擇響應，一個特別的源服務器包含透明
協商資源，它就能動態設置對這個服務器的以后的請求的長度，例如GET/paper/chapter1
HTTP/1.1
Host:x.org
User-Agent:WuxtaWeb/2.4
Negotiate:1.0
Accept:text/html,application/postscript;q=0.8,*/*
Accept-Language:en,fr;q=0.5,*;q=0.9
Accept-Features:tables,*
這將增加遠程變量選擇算法擁有足夠信息為用戶代理作出選擇的機會，因而會使協商進程最
優化。一個動態擴展的優良算法是用這些媒體類型，語言，字符集，和特征標記符來擴展報
頭，這些都是在過去來自服務器的響應的變量列表中提到的。
4.3本地和遠程算法的區別
一個用戶代理只能最優化內容協商，即使使用遠程算法，而它的本地算法一般會做出相
同的選擇。如果用戶代理收到一個包括由遠程算法選擇的變量X，而本地算法會選擇Y，用
戶代理有兩種選擇：
1． 在接下來的請求中重新得到Y。這不是最佳方案，因為它費時間。
2． 無論如何也要顯示X。這不是最佳方案，因為它使最終結果依賴于會隨機改變的因數。
對于對同一資源的下個請求，中間代理緩沖會返回一個列表響應，這會導致本地算法選
擇并重新得到Y而不是X。和穩定的表示相比，一個隨機地在X和Y之間轉換的表示的
品質低得多。
因為上面的兩種選擇都沒有吸引力，用戶代理應該試著一起避免上面的兩種情況。下面
的幾節討論了這該如何實現。
4.3避免主要區別
如果用戶代理使這篇說明中的遠程算法生效了，它應該按照慣例使用一個很類似遠程算
法的本地算法。此算法也應該使用乘法組合品質因數。如果用戶代理通過加法組合品質因數，
定義一個新遠程變量選擇算法會更有利，這個算法有一個新的主要版本號。
4．3．2解決細微區別
即使一個本地算法使用乘法組合品質因數，它還是可以使用擴展的品質公式像：
Q=round5(qs*qt*qc*ql*qf)*q_adjust
以解決維之間的特殊相互依賴，這種依賴源自用戶代理的局限性。例如，如果用戶代理，由
于某種原因，在翻譯text/plain文檔時不能處理iso-8859-7字符集，而text/plain-
iso-8859-7組合在變量描述中出現時，q_adjuster因數就會為0，否則為1。
通過選擇性地扣留來自遠程變量選擇算法的信息，用戶代理能確保如果本地q_adjust
小于1，遠程算法永遠不會作出一個選擇。例如，為阻止遠程算法返回一個text/plain-
iso-8859-7選擇響應，用戶代理應該小心永遠不要產生一個精確說明text/plain和
iso-8859-7品質因數的請求。對一個請求的任一因數的忽略都會任何text/plain-
iso-8859-7變量的總體品質值成為不確定的，擁有不確定品質值的變量永遠不會在一個選
擇響應中返回。
一般地，對一個特殊的組合X-Y-X，如果本地q_adjust不等于1，一個遠程選擇可以
通過如下方式阻止，總是忽略來自接收報頭的組合中的元素，并加上一個合適的通配符類型
來匹配忽略的元素，如果這樣的類型還沒有存在的話。
5．0安全和隱私考慮
這部分說明沒有介紹任何［2］中還沒有涉及到的安全和隱私考慮。參見［2］以獲得和
接收報頭相關的隱私風險。
6．致謝
有關HTTP內容協商的工作至少自1993年就已經做好了。作者不能夠追溯這篇文檔中的
許多觀點的來源。許多HTTP工作組的成員對這篇說明中的協商模型作出了貢獻。作者衷心
感謝那些對這篇文檔早期版本作出評論的個人，包括BrianBehlendorf,DanielDuBois,
TedHardie,LarryMasinter,andRoyT.Fielding.
7．參考文獻
[1]Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.,and
T.Berners-Lee,"HypertextTransferProtocol--HTTP/1.1",RFC
2068,January1997.
[2]Holtman,K.,andA.Mutz,"TransparentContentNegotiationin
HTTP",RFC2295,March1998.
8．作者地址
KoenHoltman
TechnischeUniversiteitEindhoven
Postbus513
KamerHG6.57
5600MBEindhoven(TheNetherlands)
EMail:koen@win.tue.nl

AndrewH.Mutz
Hewlett-PackardCompany
1501PageMillRoad3U-3
PaloAltoCA94304,USA
Fax:+14158574691
EMail:mutz@hpl.hp.com
9．完整版權說明
Copyright(C)TheInternetSociety(1998).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.
RFC2296——HTTPRemoteVariantSelectionAlgorithm--RVSA/1.0HTTP遠程變量選擇算法—RVSA/1.0