組織：中國互動出版網（http://www.china-pub.com/） RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：[email protected] 譯者：x1982212（x1982212） 譯文發佈時間：2001-11-24 版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用於非商業用途自由轉載，但必須 保留本文檔的翻譯及版權信息。 Network Working Group K. Holtman Request for Comments: 2296 TUE Category: Experimental A. Mutz Hewlett-Packard March 1998 HTTP遠程變量選擇算法—RVSA/1.0 （RFC2296——HTTP Remote Variant Selection Algorithm -- RVSA/1.0） 本備忘錄的狀態 本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和 建議以得到改進。請參考最新版的“Internet正式協議標準” (STD1)來獲得本協議的標準 化程度和狀態。本備忘錄的發佈不受任何限制。 版權聲明 Copyright (C) The Internet Society (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}{language fr}｝並且請求包含接收報頭 Accept:text/html:q=1.0,*/*=0.8 Accept-Language:en;q=1.0,fr;q=0.5 遠程變量選擇算法會按下面方式爲變量計算一個總體品質: {"paper.html.fr" 0.7 {type text/html} {language fr}} | | | | | | V V V round5 ( 0.7 * 1.0 * 0.5 ) = 0.35000 按上面的接收報頭,下面完整的變量列表 {"paper.html.en" 0.9 {type text/html} {language en}}, {"paper.html.fr" 0.7 {type text/html} {language fr}}, {"paper.ps.en" 1.0 {type application/postscript} {language en}} 會產生下面的計算式： 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｛language en-gb｝{features blebber [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 {language en} {charset ISO-8859-1}}, {"paper.greek" 1.0 {language el} {charset ISO-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 {type image/gif}}, {"x.tiff" 1.0 {type image/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 /paper HTTP/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工作組的成員對這篇說明中的協商模型作出了貢獻。作者衷心 感謝那些對這篇文檔早期版本作出評論的個人，包括Brian Behlendorf, Daniel DuBois, Ted Hardie, Larry Masinter, and Roy T.Fielding. 7．參考文獻 [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [2] Holtman, K., and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998. 8．作者地址 Koen Holtman Technische Universiteit Eindhoven Postbus 513 Kamer HG 6.57 5600 MB Eindhoven (The Netherlands) EMail: [email protected] Andrew H. Mutz Hewlett-Packard Company 1501 Page Mill Road 3U-3 Palo Alto CA 94304, USA Fax: +1 415 857 4691 EMail: [email protected] 9．完整版權說明 Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. RFC2296——HTTP Remote Variant Selection Algorithm -- RVSA/1.0 HTTP遠程變量選擇算法—RVSA/1.0 1 RFC文檔中文翻譯計劃
