RFC2227 日本語訳
2227 Simple Hit-Metering and Usage-Limiting for HTTP. J. Mogul, P.Leach. October 1997. (Format: TXT=85127 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Mogul
Request for Comments: 2227 DECWRL
Category: Standards Track P. Leach
Microsoft
October 1997
コメントを求めるワーキンググループJ.要人要求をネットワークでつないでください: 2227年のDECWRLカテゴリ: 標準化過程P.リーチマイクロソフト1997年10月
Simple Hit-Metering and Usage-Limiting for HTTP
HTTPのための簡単なヒット計量と用法制限
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 All rights reserved。
ABSTRACT
要約
This document proposes a simple extension to HTTP, using a new "Meter" header, which permits a limited form of demographic information (colloquially called "hit-counts") to be reported by caches to origin servers, in a more efficient manner than the "cache-busting" techniques currently used. It also permits an origin server to control the number of times a cache uses a cached response, and outlines a technique that origin servers can use to capture referral information without "cache-busting."
このドキュメントはHTTPに単純拡大を提案します、限局型に関する人口学的情報(口語的に「ヒット数」と呼ばれる)がキャッシュによって発生源サーバに報告されるのを可能にする新しい「メーター」ヘッダーを使用して、現在使用されている「キャッシュを破産した」テクニックより効率的な方法で。 また、それは、発生源サーバが「キャッシュ破産」なしでキャッシュが紹介情報を得るために、キャッシュされた応答を使用して、発生源サーバが使用できるテクニックについて概説する回数を制御することを許可します。
TABLE OF CONTENTS
目次
1 Introduction 2
1.1 Goals, non-goals, and limitations 3
1.2 Brief summary of the design 4
1.3 Terminology 5
2 Overview 5
2.1 Discussion 7
3 Design concepts 8
3.1 Implementation of the "metering subtree" 8
3.2 Format of the Meter header 10
3.3 Negotiation of hit-metering and usage-limiting 10
3.4 Transmission of usage reports 14
3.5 When to send usage reports 15
3.6 Subdivision of usage-limits 16
1つの序論、2、1.1Goals、非目標、および制限、3、1.2Brief概要、デザイン4 1.3Terminology5 2Overview5 2.1Discussion7 3Design概念、8、3.1Implementation、「計量下位木」8、Meterヘッダーの3.2Format、10、3.3Negotiation、ヒット計量と用法制限、10、3.4Transmission、用法レポート、14、3.5When、用法レポートを送る、15、3.6Subdivision、用法限界16
Mogul & Leach Standards Track [Page 1] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[1ページ]RFC2227
4 Analysis 17
4.1 Approximation accuracy for counting users 18
4.2 What about "Network Computers"? 19
4.3 Critical-path delay analysis 19
5 Specification 20
5.1 Specification of Meter header and directives 20
5.2 Abbreviations for Meter directives 23
5.3 Counting rules 24
5.3.1 Counting rules for hit-metering 24
5.3.2 Counting rules for usage-limiting 25
5.3.3 Equivalent algorithms are allowed 26
5.4 Counting rules: interaction with Range requests 27
5.5 Implementation by non-caching proxies 27
5.6 Implementation by cooperating caches 28
6 Examples 28
6.1 Example of a complete set of exchanges 28
6.2 Protecting against HTTP/1.0 proxies 30
6.3 More elaborate examples 30
7 Interactions with content negotiation 31
7.1 Treatment of responses carrying a Vary header 31
7.2 Interaction with Transparent Content Negotiation 32
8 A Note on Capturing Referrals 32
9 Alternative proposals 33
10 Security Considerations 34
11 Acknowledgments 35
12 References 35
13 Authors' Addresses 36
14 Full Copyright Statement 37
4 「ネットワーク・コンピュータ」でユーザ18 4.2Whatを数えるための分析17 4.1Approximation精度? 19 4.3クリティカルパス遅れ分析19 5Specification、20、5.1Specification、Meterヘッダーと指示、20、5.2Abbreviations、Meter指示23 5.3Countingに関しては、規則24 5.3に、.1Countingは、ヒットを計量する24のために5.3に、.2Countingが5.3の.3Equivalentアルゴリズムが許容されている25を用法で制限するために、5.4Countingが統治する26を統治すると裁決します: Range要求との相互作用、27、5.5Implementation、非キャッシュしているプロキシ、27、5.6Implementation、協力することによって28 6Examplesをキャッシュする、28、6.1Example、完全な交換、28、6.2Protecting、満足している交渉があるHTTP/1.0のプロキシ30 6.3Moreの入念な例の30 7Interactions、31、7; Varyヘッダーを運ぶ応答の1つの処理、31、7.2Interaction、Capturing Referrals32 9つのAlternative提案33 10Security Considerations34 11Acknowledgments35 12References35 13AuthorsのAddresses36 14Full Copyright Statement37の上のTransparent Content Negotiation32 8A Note
1 Introduction
1つの序論
For a variety of reasons, content providers want to be able to
collect information on the frequency with which their content is
accessed. This desire leads to some of the "cache-busting" done by
existing servers. ("Cache-busting" is the use by servers of
techniques intended to prevent caching of responses; it is unknown
exactly how common this is.) This kind of cache-busting is done not
for the purpose of maintaining transparency or security properties,
but simply to collect demographic information. Some cache-busting is
also done to provide different advertising images to appear on the
same page (i.e., each retrieval of the page sees a different ad).
さまざまな理由で、コンテンツプロバイダーはそれらの内容がアクセスされている頻度の情報を集めることができるようになりたがっています。 この願望は既存のサーバによって行われた「キャッシュ破産」のいくつかに通じます。 (「キャッシュ破産」は応答がキャッシュされるのを防ぐことを意図するテクニックのサーバで使用です; これがまさにどれくらい一般的であるかは、未知です。) 単に透明かセキュリティの特性を維持する目的ではなく、料金先方払いの人口学的情報にこの種類のキャッシュ破産をします。 また、同じページに現れるように異なった広告イメージを提供するためにいくつかのキャッシュ破産をします(すなわち、ページの各検索は異なった広告を見ます)。
This proposal supports a model similar to that of publishers of hard-copy publications: such publishers (try to) report to their advertisers how many people read an issue of a publication at least once; they don't (try to) report how many times a reader re-reads an issue. They do this by counting copies published, and then try to estimate, for their publication, on average how many people read a
この提案はハードコピー刊行物の出版社のものと同様のモデルをサポートします: そのような出版社(そうしようとする)は、何人の人々が少なくとも一度刊行物の問題を読むと彼らの広告主に報告します。 彼らは報告しません(そうしようとします)。読者は何回、問題を再読しますか? 彼らは、発行されたコピーを数えることによってこれをして、次に、見積もっていようとします、それらの公表、平均的に何人の人々がaを読むように
Mogul & Leach Standards Track [Page 2] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[2ページ]RFC2227
single copy at least once. The key point is that the results aren't exact, but are still useful. Another model is that of coding inquiries in such a way that the advertiser can tell which publication produced the inquiry.
シングルは少なくとも一度コピーされます。 要所は結果が正確ではありませんが、まだ役に立っているということです。 別のモデルはコード化では、広告主がどの公表を言うことができるかような方法における問い合せが問い合せを起こしたということです。
1.1 Goals, non-goals, and limitations
1.1 目標、非目標、および制限
HTTP/1.1 already allows origin servers to prevent caching of responses, and evidence exists [9] that at least some of the time, this is being done for the sole purpose of collecting counts of the number of accesses of specific pages. Some of this evidence is inferred from the study of proxy traces; some is based on explicit statements of the intention of the operators of Web servers. Information collected this way might or might not be of actual use to the people who collect it; the fact is that they want to collect it, or already do so.
発生源サーバは、HTTP/1.1で応答がキャッシュされるのを既に防ぐことができます、そして、[9] 少なくとも時々、特定のアクセスの数のカウントを集める唯一の目的のためにこれをしているという証拠は存在しています。 この何らかの証拠がプロキシ跡の研究から推論されます。 或るものはウェブサーバのオペレータの意志のはっきりした説明に基づいています。 このように集められた情報は、役に立つかもしれないか、または実際それを集める人々の役に立たないかもしれません。 事実は彼らがそれを集めたいか、または既にそうしたがっているということです。
The goal of this proposal is to provide an optional performance optimization for this use of HTTP/1.1.
この提案の目標はHTTP/1.1のこの使用のための任意のパフォーマンスの最適化を提供することです。
This specification is:
この仕様は以下の通りです。
- Optional: no server or proxy is required to implement it.
- 任意: どんなサーバもプロキシもそれを実装する必要はありません。
- Proxy-centered: there is no involvement on the part of
end-client implementations.
- プロキシ中心: かかわり合いが全く終わりクライアント実装側のありません。
- Solely a performance optimization: it provides no
information or functionality that is not already available
in HTTP/1.1. The intent is to improve performance overall,
and reduce latency for almost all interactions; latency
might be increased for a small fraction of HTTP
interactions.
- 唯一パフォーマンスの最適化: それはどんな既に利用可能でない情報も機能性もHTTP/1.1に提供しません。 意図は、全体的に見て性能を向上させて、ほとんどすべての相互作用のためにレイテンシを減少させることです。 潜在はHTTP相互作用のわずかな部分のために増強されるかもしれません。
- Best-efforts: it does not guarantee the accuracy of the
reported information, although it does provide accurate
results in the absence of persistent network failures or
host crashes.
- 最善の努力: それは報告された情報の精度を保証しません、永続的なネットワーク失敗かホストクラッシュがないとき正確な結果を提供しますが。
- Neutral with respect to privacy: it reveals to servers no
information about clients that is not already available
through the existing features of HTTP/1.1.
- プライバシーに関する中立: それはクライアントのどんなHTTP/1.1の既存の特徴を通して既に利用可能でない情報もサーバに明らかにしません。
The goals of this specification do not include:
この仕様の目標は:でない
- Solving the entire problem of efficiently obtaining
extensive information about requests made via proxies.
- 効率的にプロキシを通してされた要求の大規模な情報を得るという全体の問題を解決します。
Mogul & Leach Standards Track [Page 3] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[3ページ]RFC2227
- Improving the protection of user privacy (although our
proposal may reduce the transfer of user-specific
information to servers, it does not prevent it).
- ユーザプライバシー(私たちの提案はユーザ特殊情報の転送をサーバに抑えるかもしれませんが、それはそれを防がない)の保護を改良します。
- Preventing or encouraging the use of log-exchange
mechanisms.
- ログ交換メカニズムの使用を防ぐか、または奨励します。
- Avoiding all forms of "cache-busting", or even all
cache-busting done for gathering counts.
- すべてのフォームの「キャッシュ破産」、または集会カウントのために行われたすべてのキャッシュ破産さえ避けます。
This design has certain potential limitations:
このデザインには、ある潜在的制限があります:
- If it is not deployed widely in both proxies and servers,
it will provide little benefit.
- プロキシとサーバの両方で広く配布されないと、それはほとんど利益を提供しないでしょう。
- It may, by partially solving the hit-counting problem,
reduce the pressure to adopt more complete solutions, if
any become available.
- ヒットが重要な問題を部分的に解決することによって、それは、より完全なソリューションを採用する圧力を減少させるかもしれません、いずれか利用可能になるなら。
- Even if widely deployed, it might not be widely used, and
so might not significantly improve performance.
- 広く配布されても、それは、広く使用されないかもしれないので、性能をかなり向上させないかもしれません。
These potential limitations might not be problems in actual practice.
これらの潜在的制限は実際行なわれているところでは問題でないかもしれません。
1.2 Brief summary of the design
1.2 デザインの簡潔な概要
This section is included for people not wishing to read the entire document; it is not a specification for the proposed design, and over-simplifies many aspects of the design.
このセクションは全体のドキュメントを読みたがっていない人々のために含まれています。 それは、提案されたデザインのための仕様でなく、デザインの多くの局面を簡素化し過ぎます。
The goal of this design is to eliminate the need for origin servers to use "cache-busting" techniques, when this is done just for the purpose of counting the number of users of a resource. (Cache- busting includes techniques such as setting immediate Expiration dates, or sending "Cache-control: private" in each response.)
このデザインの目標は発生源サーバが「キャッシュを破産した」テクニックを使用する必要性をなくします、まさしくリソースのユーザの数を数える目的のためにこれをすると。 (キャッシュ破産が即座のExpirationを設定などなどのテクニック日付を含んでいるか、または発信は各応答で「個人的に以下をキャッシュで制御します」。)
The design adds a new "Meter" header to HTTP; the header is always protected by the "Connection" header, and so is always hop-by-hop. This mechanism allows the construction of a "metering subtree", which is a connected subtree of proxies, rooted at an origin server. Only those proxies that explicitly volunteer to join in the metering subtree for a resource participate in hit-metering, but those proxies that do volunteer are required to make their best effort to provide accurate counts. When a hit-metered response is forwarded outside of the metering subtree, the forwarding proxy adds "Cache-control: s- maxage=0", so that other proxies (outside the metering subtree) are forced to forward all requests to a server in the metering subtree.
デザインは新しい「メーター」ヘッダーをHTTPに追加します。 いつも「接続」ヘッダーによって保護されるので、いつもヘッダーは、ホップホップです。 プロキシの接続下位木、発生源サーバに根づいて. リソースのために計量下位木に参加するのを明らかに買って出るそれらのプロキシだけがヒット計量に参加しますが、買って出るそれらのプロキシが必要であるということである「計量下位木」の工事がこのメカニズムで作ることができる、彼ら、正確な計算を提供するために、ベストエフォート型です。 ヒットで計量された応答を計量下位木の外に送るとき、「キャッシュで制御してください。」と、推進プロキシは言い足します。 s maxage=0インチ、他ように、プロキシ(計量下位木の外における)はやむを得ず計量下位木におけるサーバにすべての要求を転送します。
Mogul & Leach Standards Track [Page 4] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[4ページ]RFC2227
NOTE: the HTTP/1.1 specification does not currently define a "s-
maxage" Cache-control directive. The HTTP working group has
decided to add such a directive to the next revision of the
HTTP/1.1 specification [7].
以下に注意してください。 HTTP/1.1仕様は現在、「s maxage」Cache-コントロール指示を定義しません。 HTTPワーキンググループは、HTTP/1.1仕様[7]の次の改正にそのような指示を加えると決めました。
The Meter header carries zero or more directives, similar to the way that the Cache-control header carries directives. Proxies may use certain Meter directives to volunteer to do hit-metering for a resource. If a proxy does volunteer, the server may use certain directives to require that a response be hit-metered. Finally, proxies use a "count" Meter directive to report the accumulated hit counts.
Meterヘッダーは指示で、Cache-コントロールヘッダーが指示を運ぶ方法と同様の状態でゼロか以上を運びます。 プロキシは、リソースのためのヒット計量をするのを買って出るのに、あるMeter指示を使用するかもしれません。 プロキシが買って出るなら、サーバは、応答がヒットによって計量されているのが必要であるのに、ある指示を使用するかもしれません。 最終的に、プロキシは、蓄積されたヒット数を報告するのに「カウント」Meter指示を使用します。
The Meter mechanism can also be used by a server to limit the number of uses that a cache may make of a cached response, before revalidating it.
また、Meterメカニズムはサーバによって使用されて、キャッシュがキャッシュされた応答でするかもしれない用途の数を制限できます、それを再有効にする前に。
The full specification includes complete rules for counting "uses" of a response (e.g., non-conditional GETs) and "reuses" (conditional GETs). These rules ensure that the results are entirely consistent in all cases, except when systems or networks fail.
完全な仕様は応答(例えば、条件付きの非GETs)と「再利用」(条件付きのGETs)の「用途」を数えるための完全な規則を含んでいます。 これらの規則は、結果がシステムかネットワークが行き詰まる時以外のすべての場合で完全に一貫しているのを確実にします。
1.3 Terminology
1.3 用語
This document uses terms defined and explained in the HTTP/1.1 specification [4], including "origin server," "resource," "hop-by- hop," "unconditional GET," and "conditional GET." The reader is expected to be familiar with the HTTP/1.1 specification and its terminology.
このドキュメントはHTTP/1.1仕様[4]で定義されて、説明された用語を使用します、「発生源サーバ」、「無条件のGET」、および「条件付きのGET」という「ホップを飛び越している」「リソース」を含んでいて。 読者がHTTP/1.1仕様とその用語によく知られさせると予想されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
「キーワード“MUST"、「必要であった」“SHOULD"がそうするべきでない「必須NOT」」、「5月」、このドキュメントで「任意」は「お勧めであり」、RFC2119[1]で説明されるように解釈されることです。
2 Overview
2概要
The design described in this document introduces several new features to HTTP:
本書では説明されたデザインはいくつかの新機能をHTTPに紹介します:
- Hit-metering: allows an origin server to obtain reasonably
accurate counts of the number of clients using a resource
instance via a proxy cache, or a hierarchy of proxy caches.
- ヒットを計量しています: 発生源サーバが合理的にクライアントの数がプロキシキャッシュでリソースインスタンスを使用する正確な計算、またはプロキシキャッシュの階層構造を得るのを許容します。
- Usage-limiting: allows an origin server to control the
number of times a cached response may be used by a proxy
cache, or a hierarchy of proxy caches, before revalidation
with the origin server.
- 用法を制限しています: 発生源サーバが再合法化の前で発生源サーバでキャッシュされた応答がプロキシキャッシュによって使用されるかもしれないという回の数、またはプロキシキャッシュの階層構造を制御するのを許容します。
Mogul & Leach Standards Track [Page 5] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[5ページ]RFC2227
These new non-mandatory features require minimal new protocol support, no change in protocol version, relatively little overhead in message headers. The design adds no additional network round-trips in any critical path that directly affects user-perceived latency (see section 4.3 for an analysis).
これらの新しい非義務的な特徴は最小量の新しいプロトコルサポート、プロトコルバージョンにおける変化がない、メッセージヘッダーの比較的少ないオーバーヘッドを必要とします。 デザインは直接ユーザによって知覚された潜在に影響するどんなクリティカルパスでも丸い旅行であるどんな追加ネットワークも加えません(分析に関してセクション4.3を見てください)。
The primary goal of hit-metering and usage-limiting is to obviate the need for an origin server to send "Cache-control: s-maxage=0" with responses for resources whose value is not likely to change immediately. In other words, in cases where the only reason for contacting the origin server on every request that might otherwise be satisfied by a proxy cache entry is to allow the server to collect demographic information or to control the number of times a cache entry is used, the extension proposed here will avoid a significant amount of unnecessary network traffic and latency.
ヒット計量と用法制限のプライマリ目標は発生源サーバが発信する必要性を取り除くためには、「キャッシュで制御してください」ということです。 値がすぐに変化しそうにないリソースのための応答があるs-maxage=0インチ。 言い換えれば、サーバが人口学的情報を集めるか、または回数を制御するのを許容するそうでなければプロキシキャッシュエントリーで満たされるかもしれないあらゆる要求のときに発生源サーバに連絡する唯一の理由がことである場合キャッシュエントリーが使用されている、ここで提案された拡大はかなりの量の不要なネットワークトラフィックと潜在を避けるでしょう。
This design introduces one new "Meter" header, which is used both in HTTP request messages and HTTP response messages. The Meter header is used to transmit a number of directives and reports. In particular, all negotiation of the use of hit-metering and usage limits is done using this header. No other changes to the existing HTTP/1.1 specification [4] are proposed in this document.
このデザインは1個の新しい「メーター」ヘッダーを紹介します。(ヘッダーはHTTP要求メッセージとHTTP応答メッセージに使用されます)。 Meterヘッダーは、多くの指示とレポートを伝えるのに使用されます。 特に、ヒット計量と用法限界の使用のすべての交渉がこのヘッダーを使用し終わっています。 既存のHTTP/1.1仕様[4]への他の変化は全く本書では提案されません。
This design also introduces several new concepts:
また、このデザインはいくつかの新しい概念を紹介します:
1. The concepts of a "use" of a cache entry, which is when a
proxy returns its entity-body in response to a conditional
or non-conditional request, and the "reuse" of a cache
entry, which is when a proxy returns a 304 (Not Modified)
response to a conditional request which is satisfied by
that cache entry.
1. それは、プロキシが条件付きであるか非条件付き要求に対応して実体本体を返す時です。(それは、プロキシがそれによって満たされている条件付き要求への304(Modifiedでない)応答を返す時です)。キャッシュエントリーの「使用」の概念、およびキャッシュエントリーの「再利用」はエントリーをキャッシュします。
2. The concept of a hit-metered resource, for which proxy
caches make a best-effort attempt to report accurate
counts of uses and/or reuses to the origin server.
2. ヒットで計量されたリソースの概念。(プロキシキャッシュはそれに関して用途、そして/または、再利用の正確な計算を発生源サーバに報告するベストエフォート型試みをします)。
3. The concept of a usage-limited resource, for which the
origin server expects proxy caches to limit the number of
uses and/or reuses.
3. 用法で限られたリソースの概念。(発生源サーバは、用途、そして/または、再利用の数を制限するためにそれに関してプロキシキャッシュを予想します)。
The new Meter directives and reports interact to allow proxy caches and servers to cooperate in the collection of demographic data. The goal is a best-efforts approximation of the true number of uses and/or reuses, not a guaranteed exact count.
新しいMeter指示とレポートは、プロキシキャッシュとサーバが人口統計のデータの収集に協力するのを許容するために相互作用します。 目標は保証された正確なカウントではなく、用途、そして/または、再利用の真の数の最善の努力近似です。
Mogul & Leach Standards Track [Page 6] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[6ページ]RFC2227
The new Meter directives also allow a server to bound the inaccuracy of a particular hit-count, by bounding the number of uses between reports. It can also, for example, bound the number of times the same ad is shown because of caching.
また、新しいMeter指示は特定のヒット数の不正確を縛って、バウンドしていることへの間の用途の数が報告するサーバを許容します。 それはまた、例えばそうすることができて、バウンドは同じ広告がキャッシュに示される回数です。
Section 7.1 describes a way to use server-driven content negotiation (the Vary header) that allows an HTTP origin server to flexibly separate requests into categories and count requests by category. Implementation of such a categorized hit counting is likely to be a very small modification to most implementations of Vary; some implementations may not require any modification at all.
セクション7.1はHTTP発生源サーバが柔軟にカテゴリに要求を切り離して、カテゴリで要求を数えるサーバ駆動の満足している交渉(Varyヘッダー)を使用する方法を述べます。 そのような分類されたヒット勘定の実装はVaryのほとんどの実装への非常に小さい変更である傾向があります。 いくつかの実装は全く少しの変更も必要としないかもしれません。
2.1 Discussion
2.1 議論
Mapping this onto the publishing model, a proxy cache would increment the use-count for a cache entry once for each unconditional GET done for the entry, and once for each conditional GET that results in sending a copy of the entry to update a client's invalid cached copy. Conditional GETs that result in 304 (Not Modified) are not included in the use-count, because they do not result in a new user seeing the page, but instead signify a repeat view by a user that had seen it before. However, 304 responses are counted in the reuse-count. HEADs are not counted at all, because their responses do not contain an entity-body.
出版モデルにこれを写像する場合、プロキシキャッシュは、エントリーに行われたそれぞれの無条件のGETのために一度キャッシュエントリーにカウントを使用するのを増加するでしょう、そして、かつてのアップデートするエントリーのコピーを送るのに結果になるそれぞれの条件付きのGETのためにクライアントの病人はコピーをキャッシュしました。 304(Modifiedでない)における結果をある条件付きのGETsは、中にカウントを使用するのを含んでいませんでした、代わりに以前それを見たことがあったユーザで反復視点を意味して彼らがページを参照する新しいユーザをもたらさないので。 しかしながら、304の応答が再利用カウントで数えられます。 彼らの応答が実体本体を含んでいないので、HEADsは全く数えられません。
The Meter directives apply only to shared proxy caches, not to end- client (or other single-user) caches. Single user caches should not use Meter, because their hits will be automatically counted as a result of the unconditional GET with which they first fetch the page, from either the origin-server or from a proxy cache. Their subsequent conditional GETs do not result in a new user seeing the page.
Meter指示は、クライアント(または、他のシングルユーザー)キャッシュを終わらせないように共有されたプロキシキャッシュだけに適用されます。 シングルユーザーキャッシュはMeterを使用するべきではありません、彼らのヒットが発生源サーバか最初にそれらとページをとって来る無条件のGETの結果、プロキシキャッシュから自動的に数えられるので。 それらのその後の条件付きのGETsはページを参照する新しいユーザをもたらしません。
The mechanism specified here counts GETs; other methods either do not result in a page for the user to read, aren't cached, or are "written-through" and so can be directly counted by the origin server. (If, in the future, a "cachable POST" came into existence, whereby the entity-body in the POST request was used to select a cached response, then such POSTs would have to be treated just like GETs.) The applicability of hit-metering to any new HTTP methods that might be defined in the future is currently unspecifiable.
メカニズムはここでカウントGETsを指定しました。 他のメソッドを、ユーザが読む1ページをもたらさないか、「書かれて突き抜け」て、または発生源サーバは、キャッシュされないので、直接数えることができます。. (「キャッシュ可能ポスト」(ポストの要求における実体本体はキャッシュされた応答を選択するのに使用された)が将来生まれるなら、そのようなPOSTsはまさしくGETsのように扱われなければならないでしょうに。) 将来定義されるどんな新しいHTTPメソッドへのヒット計量の適用性も現在、「非-明記でき」です。
In the case of multiple caches along a path, a proxy cache does the obvious summation when it receives a use-count or reuse-count in a request from another cache.
受信するとき、aは、使用して数えるか、または再利用して数えられます。経路に沿った複数のキャッシュの場合では、プロキシキャッシュが明白な足し算をする、別のキャッシュからの要求で。
Mogul & Leach Standards Track [Page 7] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[7ページ]RFC2227
3 Design concepts
3 デザイン概念
In order to allow the introduction of hit-metering and usage-limiting without requiring a protocol revision, and to ensure a reasonably close approximation of accurate counts, the negotiation of metering and usage-limiting is done hop-by-hop, not end-to-end. If one considers the "tree" of proxies that receive, store, and forward a specific response, the intent of this design is that within some (possibly null) "metering subtree", rooted at the origin server, all proxies are using the hit-metering and/or usage-limiting requested by the origin server.
プロトコル改正を必要としないでヒット計量と用法制限の導入を許して、正確な計算の合理的に厳密な近似を確実にするために、ホップごとに計量と用法制限の交渉をします、終わらせる終わりでない。 人が特定の応答を受けて、保存して、進めるプロキシの「木」を考えるなら、このデザインの意図は発生源サーバに根づくいくつかの(ことによるとヌル)の「計量下位木」の中では、すべてのプロキシが発生源サーバによって要求されたヒット計量、そして/または、用法制限を使用しているということです。
Proxies at the leaves of this subtree will insert a "Cache-control: s-maxage=0" directive, which forces all other proxies (below this subtree) to check with a leaf of the metering subtree on every request. However, it does not prevent them from storing and using the response, if the revalidation succeeds.
この下位木の葉のプロキシは挿入するでしょう。aは「以下をキャッシュで制御します」。 s-maxageは0インチの指示と等しいです。(他のすべてのプロキシ(この下位木の下における)があらゆる要求のときにそれによってやむを得ず計量下位木の葉に問い合わせます)。 しかしながら、それは、再合法化が成功するなら、彼らが応答を保存して、使用するのを防ぎません。
No proxy is required to implement hit-metering or usage-limiting. However, any proxy that transmits the Meter header in a request MUST implement every unconditional requirement of this specification, without exception or amendment.
プロキシは全くヒット計量か用法制限を実装する必要はありません。 しかしながら、要求でMeterヘッダーを伝えるどんなプロキシもこの仕様のあらゆる無条件の要件を実装しなければなりません、例外も修正なしで。
This is a conservative design, which may sometimes fail to take advantage of hit-metering support in proxies outside the metering subtree. However, it is likely that without the reliability offered by a conservative design, managers of origin servers with requirements for accurate approximations will not take advantage of any hit-metering proposal.
これは昔からのデザインです。(その昔からのデザインはプロキシで計量下位木の外でヒットを計量するサポートを時々利用しないかもしれません)。 しかしながら、昔からのデザインによって提供された信頼性がなければ、正確な近似のための要件がある発生源サーバのマネージャは少しのヒットを計量する提案も利用しそうにないでしょう。
The hit-metering/usage-limiting mechanism is designed to avoid any extra network round-trips in the critical path of any client request, and (as much as possible) to avoid excessively lengthening HTTP messages.
ヒットを計量しているか、または用法を制限するメカニズムは、HTTPメッセージを過度に伸すのを避けるために旅行する状態で丸いどんな付加的なネットワークも(できるだけどんなクライアント要求のクリティカルパス、および)も避けるように設計されています。
The Meter header is used to transmit both negotiation information and numeric information.
Meterヘッダーは、交渉情報と数値情報の両方を伝えるのに使用されます。
A formal specification for the Meter header appears in section 5; the following discussion uses an informal approach to improve clarity.
Meterヘッダーへの形式仕様はセクション5に現れます。 以下の議論は、明快を改良するのに砕けた口調を使用します。
3.1 Implementation of the "metering subtree"
3.1 「計量下位木」の実装
The "metering subtree" approach is implemented in a simple, straightforward way by defining the new "Meter" header as one that MUST always be protected by a Connection header in every request or response. I.e., if the Meter header is present in an HTTP message, that message:
「計量下位木」アプローチは、Connectionヘッダーがあらゆる要求か応答でいつも保護しなければならないものと新しい「メーター」ヘッダーを定義することによって、簡単で、簡単な方法で実装されます。 すなわち、MeterヘッダーがHTTPメッセージ、そのメッセージに出席しているなら:
Mogul & Leach Standards Track [Page 8] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[8ページ]RFC2227
1. MUST contain "Connection: meter", and MUST be handled
according to the HTTP/1.1 specification of the Connection
header.
1. 含まなければならない、「接続:」 「計量してください」、ConnectionヘッダーのHTTP/1.1仕様通りに扱わなければなりません。
2. MUST NOT be sent in response to a request from a client
whose version number is less than HTTP/1.1.
2. バージョン番号がHTTP/1.1より少ないクライアントからの要求に対応して送ってはいけません。
3. MUST NOT be accepted from a client whose version number is
less than HTTP/1.1.
3. バージョン番号がHTTP/1.1より少ないクライアントから受け入れてはいけません。
The reason for the latter two restrictions is to protect against proxies that might not properly implement the Connection header. Otherwise, a subtree that includes an HTTP/1.0 proxy might erroneously appear to be a metering subtree.
後者の2つの制限の理由は適切にConnectionヘッダーを実装しないかもしれないプロキシから守ることです。 さもなければ、HTTP/1.0プロキシを含んでいる下位木は計量下位木であるように誤って見えるかもしれません。
Note: It appears that for the Connection header mechanism to
function correctly, a system receiving an HTTP/1.0 (or lower-
version) message that includes a Connection header must act as if
this header, and all of the headers it protects, ought to have
been removed from the message by an intermediate proxy.
以下に注意してください。 Connectionヘッダーメカニズムが正しく機能するように、まるでこのヘッダー、およびそれが保護するヘッダーのすべてが中間的プロキシによってメッセージから取り除かれるべきであるかのようにConnectionヘッダーを含んでいるHTTP/1.0(または、低いバージョン)メッセージを受け取るシステムが作動しなければならないように見えます。
Although RFC2068 does not specifically require this behavior, it
appears to be implied. Otherwise, one could not depend on the
stated property (section 14.10) that the protected options "MUST
NOT be communicated by proxies over further connections." This
should probably be clarified in a subsequent draft of the HTTP/1.1
specification.
RFC2068は明確にこの振舞いを必要としませんが、それは含意されるように見えます。 さもなければ、1つは保護が「プロキシはさらなる接続の上でNOTを伝えなければならないこと」をゆだねる述べられた所有地(セクション14.10)に依存できませんでした。 これはたぶんHTTP/1.1仕様のその後の草稿ではっきりさせられるべきです。
This specification does not, in any way, propose a modification of
the specification of the Connection header.
この仕様は何らかの方法でConnectionヘッダーの仕様の変更を提案しません。
From the point of view of an origin server, the proxies in a metering subtree work together to obey usage limits and to maintain accurate usage counts. When an origin server specifies a usage limit, a proxy in the metering subtree may subdivide this limit among its children in the subtree as it sees fit. Similarly, when a proxy in the subtree receives a usage report, it ensures that the hits represented by this report are summed properly and reported to the origin server.
発生源サーバの観点から、計量下位木におけるプロキシは、用法限界に従って、正確な用法カウントを維持するために一緒に働いています。 発生源サーバが用法限界を指定するとき、計量下位木におけるプロキシは適していると決めるように子供で下位木でこの限界を細分するかもしれません。 下位木におけるプロキシが用法レポートを受け取るとき、同様に、それは、このレポートによって表されたヒットが発生源サーバに適切にまとめられて、報告されるのを確実にします。
When a proxy forwards a hit-metered or usage-limited response to a client (proxy or end-client) not in the metering subtree, it MUST omit the Meter header, and it MUST add "Cache-control: s-maxage=0" to the response.
プロキシがいずれの計量下位木でもクライアント(プロキシか終わりクライアント)へのヒットで計量されたか用法で限られた応答を進めないとき、Meterヘッダーを省略しなければなりません、そして、「キャッシュで制御してください。」と言い足さなければなりません。 応答へのs-maxage=0インチ。
Mogul & Leach Standards Track [Page 9] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[9ページ]RFC2227
3.2 Format of the Meter header
3.2 Meterヘッダーの形式
The Meter header is used to carry zero or more directives. Multiple Meter headers may occur in an HTTP message, but according to the rules in section 4.2 of the HTTP/1.1 specification [4], they may be combined into a single header (and should be so combined, to reduce overhead).
Meterヘッダーは、ゼロか、より多くの指示を運ぶのに使用されます。 複数のMeterヘッダーがHTTPメッセージに起こるかもしれませんが、HTTP/1.1仕様[4]のセクション4.2の規則に従って、それらは独身のヘッダー(そして、経費を削減するためにそのように結合されるべきである)に結合されるかもしれません。
For example, the following sequence of Meter headers
例えば、Meterヘッダーの以下の系列
Meter: max-uses=3
Meter: max-reuses=10
Meter: do-report
以下を計量してください。 最大用途は3Meterと等しいです: 最大再利用は10Meterと等しいです: レポートします。
may be expressed as
言い表されるかもしれません。
Meter: max-uses=3, max-reuses=10, do-report
以下を計量してください。 用途=3、最大再利用=10に最大限にして、レポートします。
3.3 Negotiation of hit-metering and usage-limiting
3.3 ヒット計量と用法制限の交渉
An origin server that wants to collect hit counts for a resource, by simply forcing all requests to bypass any proxy caches, would respond to requests on the resource with "Cache-control: s-maxage=0". (An origin server wishing to prevent HTTP/1.0 proxies from improperly caching the response could also send both "Expires: <now>", to prevent such caching, and "Cache-control: max-age=NNNN", to allow newer proxies to cache the response).
リソースのための料金先方払いのヒット数への必需品がリソースで単に、どんなプロキシキャッシュも迂回させるというすべての要求を強制することによって要求に応じる発生源サーバは「以下をキャッシュで制御します」。 s-maxage=0インチ。 (また、HTTP/1.0のプロキシが不適切に応答をキャッシュするのを防ぎたがっている発生源サーバが両方を送るかもしれない、「現在: <を吐き出す、>、」、そのようなキャッシュを防いで、より新しいプロキシが応答をキャッシュするのを許容するために「: 最大時代=NNNNをキャッシュで制御する」、)
The purpose of the Meter header is to obviate the need for "Cache- control: s-maxage=0" within a metering subtree. Thus, any proxy may negotiate the use of hit-metering and/or usage-limiting with the next-hop server. If this server is the origin server, or is already part of a metering subtree (rooted at the origin server), then it may complete the negotiation, thereby extending the metering subtree to include the new proxy.
Meterヘッダーの目的は「キャッシュは以下を制御する」必要性を取り除くことです。 計量下位木の中のs-maxage=0インチ。 したがって、どんなプロキシも次のホップサーバによるヒット計量、そして/または、用法制限の使用を交渉するかもしれません。このサーバが発生源サーバである、または既に計量下位木の一部(発生源サーバでは、根づく)であるなら交渉を終了するかもしれません、その結果、新しいプロキシを含むように計量下位木について敷衍しています。
To start the negotiation, a proxy sends its request with one of the following Meter directives:
交渉を始めるために、プロキシは以下のMeter指示の1つで要求を送ります:
will-report-and-limit
indicates that the proxy is willing and able to
return usage reports and will obey any usage-limits.
意志のレポートと限界は、プロキシが望んでいて用法レポートを返すことができるのを示して、どんな用法限界にも従うでしょう。
wont-report indicates that the proxy will obey usage-limits but
will not send usage reports.
習慣のレポートは、プロキシが用法限界に従いますが、用法レポートを送らないのを示します。
wont-limit indicates that the proxy will not obey usage-limits
but will send usage reports.
習慣の限界は、プロキシが用法限界に従いませんが、用法レポートを送るのを示します。
Mogul & Leach Standards Track [Page 10] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[10ページ]RFC2227
A proxy willing to neither obey usage-limits nor send usage reports MUST NOT transmit a Meter header in the request.
用法限界に従わないで、また用法レポートを送らないように望んでいるプロキシは要求でMeterヘッダーを伝えてはいけません。
By definition, an empty Meter header:
定義上空のMeterヘッダー:
Meter:
以下を計量してください。
is equivalent to "Meter: will-report-and-limit", and so, by the definition of the Connection header (see section 14.10 of the HTTP/1.1 specification [4]), a request that contains
同等物は「以下を計量することになっています」。 「レポートと限界を望んでください」、そのように、Connectionヘッダーの定義で(HTTP/1.1仕様[4])のセクション14.10を見てください、それが含む要求
Connection: Meter
接続: メーター
and no explicit Meter header is equivalent to a request that contains
そして、どんな明白なMeterヘッダーもそれが含む要求に同等ではありません。
Connection: Meter
Meter: will-report-and-limit
接続: メーターを計量してください: レポートと限界を望んでください。
This makes the default case more efficient.
これで、不履行格は、より効率的になります。
An origin server that is not interested in metering or usage-limiting the requested resource simply ignores the Meter header.
要求されたリソースを計量したくないか、用法で制限したがっていない起源サーバは単にMeterヘッダーを無視します。
If the server wants the proxy to do hit-metering and/or usage- limiting, its response should include one or more of the following Meter directives:
サーバが、プロキシがヒット計量、そして/または、用法制限をする必要があるなら、応答は以下のMeter指示の1つ以上を含むべきです:
For hit-metering:
ヒット計量のために:
do-report specifies that the proxy MUST send usage reports to
the server.
レポートする、プロキシが用法レポートをサーバに送らなければならないと指定します。
dont-report specifies that the proxy SHOULD NOT send usage
reports to the server.
dont-レポートは、プロキシSHOULD NOTが用法レポートをサーバに送ると指定します。
timeout=NNN sets a metering timeout of NNN minutes, from the time
that this response was originated, for the reporting
of a hit-count. If the proxy has a non-zero hit
count for this response when the timeout expires, it
MUST send a report to the server at or before that
time. Implies "do-report".
タイムアウト=NNNは分間NNNの計量タイムアウトを設定します、この応答が溯源された時間から、ヒット数の報告のために。 タイムアウトが期限が切れるとプロキシにこの応答のための非ゼロヒット数があるなら、それはその時かその時以前、レポートをサーバに送らなければなりません。 含意、「レポートする、」
By definition, an empty Meter header in a response, or any Meter header that does not contain "dont-report", means "Meter: do-report"; this makes a common case more efficient.
定義上、「計量してください。」と、応答、または「dont-レポート」を含まないどんなMeterヘッダーという空のMeterヘッダーも言っています。 「レポートする、」、。 これで、よくある例は、より効率的になります。
Mogul & Leach Standards Track [Page 11] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[11ページ]RFC2227
Note: an origin server using the metering timeout mechanism to
bound the collection period over which hit-counts are obtained
should adjust the timeout values in the responses it sends so that
all responses generated within that period reach their metering
timeouts at or before the end of that period.
以下に注意してください。 ヒット数がその期間中に発生したすべての応答が得て、それが送る応答におけるタイムアウト値を調整するべきであるので終わりにおいて、または、終わりまでにそれらの計量タイムアウトに達するということであるその期間の収集の期間のバウンドするのに計量タイムアウトメカニズムを使用する起源サーバ。
If the origin server simply sends a constant metering timeout T
with each response for a resource, the reports that it receives
will reflect activity over a period whose duration is between T
and N*T (in the worst case), where N is the maximum depth of the
metering subtree.
起源サーバがリソースのための各応答と共に一定の計量タイムアウトにTを単に送ると、受信するというレポートはTとNが計量下位木の最大の深さであるN*T(最悪の場合には)の間に持続時間がある期間、活動を反映するでしょう。
For usage-limiting
用法制限のために
max-uses=NNN sets an upper limit of NNN "uses" of the response,
not counting its immediate forwarding to the
requesting end-client, for all proxies in the
following subtree taken together.
最大用途=NNNは応答のNNN「用途」の上限を設定します、要求している終わりクライアントまで即座の推進を数えないで、一緒に取られた以下の下位木におけるすべてのプロキシのために。
max-reuses=NNN sets an upper limit of NNN "reuses" of the response
for all proxies in the following subtree taken
together.
最大再利用=NNNは一緒に取られた以下の下位木ですべてのプロキシのための応答のNNN「再利用」の上限を設定します。
When a proxy has exhausted its allocation of "uses" or "reuses" for a cache entry, it MUST revalidate the cache entry (using a conditional request) before returning it in a response. (The proxy SHOULD use this revalidation message to send a usage report, if one was requested and it is time to send it. See sections 3.4 and 3.5.)
キャッシュエントリーのための「用途」か「再利用」の配分がプロキシでくたくたになったとき、応答でそれを返す前に、それはキャッシュエントリー(条件付き要求を使用する)を再有効にしなければなりません。 (プロキシSHOULDは用法レポートを送るこの再合法化メッセージを使用します、1つが要求されて、もうそれを送るべき時間であるなら。 セクション3.4と3.5を見てください。)
These Meter response-directives apply only to the specific response that they are attached to.
これらのMeter応答指示はそれらが付けられている特定の応答だけに適用されます。
Note that the limit on "uses" set by the max-uses directive does
not include the use of the response to satisfy the end-client
request that caused the proxy's request to the server. This
counting rule supports the notion of a cache-initiated prefetch: a
cache may issue a prefetch request, receive a max-uses=0 response,
store that response, and then return that response (without
revalidation) when a client makes an actual request for the
resource. However, each such response may be used at most once in
this way, so the origin server maintains precise control over the
number of actual uses.
最大用途指示で設定された「用途」における限界がプロキシの要求をサーバに引き起こした終わりクライアント要求を満たすために応答の使用を含んでいないことに注意してください。この勘定規則はキャッシュで開始している先取りの概念を支持します: クライアントがリソースに関する実際の要求をすると、キャッシュは、先取り要求を出して、用途=に最大限にしている0応答を受けて、その応答を格納して、次に、その応答を返すかもしれません(再合法化なしで)。 しかしながら、そのような各応答が高々一度このように使用されるかもしれないので、起源サーバは実際の用途の数の正確なコントロールを維持します。
A server MUST NOT send a Meter header that would require a proxy to do something that it has not yet offered to do. A proxy receiving a Meter response-directive asking the proxy to do something it did not volunteer to do SHOULD ignore that directive.
サーバはプロキシがするそれが、まだ申し出でないことをするのを要求するMeterヘッダーを送ってはいけません。 応答指示がその指示を無視するようにそれがSHOULDをするために買って出なかった何かをするプロキシに頼むMeterを受け取るプロキシ。
Mogul & Leach Standards Track [Page 12] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[12ページ]RFC2227
A proxy receiving a Meter header in a response MUST either obey it, or it MUST revalidate the corresponding cache entry on every access. (I.e., if it chooses not to obey the Meter header in a response, it MUST act as if the response included "Cache-control: s-maxage=0".)
応答でMeterヘッダーを受け取るプロキシはそれに従わなければなりませんか、またはそれがあらゆるアクセサリーの上で対応するキャッシュエントリーを再有効にしなければなりません。 (すなわち、応答でMeterヘッダーに従わないのを選ぶなら、まるで応答を含んでいるかのように行動しなければならない、「キャッシュ制御: s-maxage=0インチ)。」
Note: a proxy that has not sent the Meter header in a request for
the given resource, and which has therefore not volunteered to
honor Meter directives in a response, is not required to honor
them. If, in this situation, the server does send a Meter header
in a response, this is a protocol error. However, based on the
robustness principle, the proxy may choose to interpret the Meter
header as an implicit request to include "Cache-control: s-
maxage=0" when it forwards the response, since this preserves the
apparent intention of the server.
以下に注意してください。 与えられたリソースに関する要求でMeterヘッダーを送らないで、またしたがって応答におけるMeter指示を光栄に思うのを買って出ていないプロキシは、それらを光栄に思うのに必要ではありません。 この状況で、サーバが応答でMeterヘッダーを送るなら、これはプロトコル誤りです。 堅牢性の原則に基づいたプロキシが、含んでいる暗黙の要求としてMeterヘッダーを解釈するのをどのように選んでも「キャッシュで制御してください」 これ以来応答を進めるときのs maxage=0インチはサーバの見かけの意志を保存します。
A proxy that receives the Meter header in a request may ignore it only to the extent that this is consistent with its own duty to the next-hop server. If the received Meter request header is inconsistent with that duty, or if no Meter request header is received and the response from the next-hop server requests any form of metering or limiting, then the proxy MUST add "Cache-control: s- maxage=0" to any response it forwards for that request. (A proxy SHOULD NOT add or change the Expires header or max-age Cache-control directive.)
要求にMeterヘッダーを受け取るプロキシはそれを単にこれが次のホップサーバへのそれ自身の義務と一致しているという範囲まで無視するかもしれません。容認されたMeter要求ヘッダーがその義務に矛盾しているか、どんなMeter要求ヘッダーも受け取られていないで、または次のホップサーバからの応答がどんなフォームの計量か制限も要求するなら、「キャッシュで制御してください。」と、プロキシは言い足さなければなりません。 それがその要求のために進めるどんな応答へのs maxage=0インチ。 (プロキシSHOULD NOTはExpiresヘッダーか最大時代Cache-コントロール指示を加えるか、または変えます。)
For example, if proxy A receives a GET request from proxy B for
URL X with "Connection: Meter", but proxy A's cached response for
URL does not include any Meter directives, then proxy A may ignore
the metering offer from proxy B.
例えばAとURL XのためのプロキシBからのGET要求を受け取るプロキシである、「接続:」 URLのための「という」 プロキシAのものを計量してくださいキャッシュされた応答はどんなMeter指示も含まないで、次に、プロキシAはプロキシBから計量申し出を無視するかもしれません。
However, if proxy A has previously told the origin server "Meter:
wont-limit" (implying will-report), and the cached response
contains "Meter: do-report", and proxy B's request includes
"Meter: wont-report", then proxy B's offer is inconsistent with
proxy A's duty to the origin server. Therefore, in this case
proxy A must add "Cache-control: s-maxage=0" when it returns the
cached response to proxy B, and must not include a Meter header in
this response.
しかしながら、プロキシAが以前に起源サーバを言ったなら「計量してください」 「習慣の限界」(意志で報告するように含意する)、およびキャッシュされた応答、含有、「計量してください」 「レポートする、」 プロキシビーズは、インクルードが「以下を計量する」よう要求します。 「習慣のレポート」です、次に、ビーズが提供するプロキシは起源サーバへのプロキシAの義務に矛盾しています。したがって、この場合、「キャッシュで制御してください。」と、プロキシAは言い足さなければなりません。 それであるときに、s-maxage=0インチは、プロキシBへのキャッシュされた応答を返して、この応答にMeterヘッダーを含んではいけません。
If a server does not want to use the Meter mechanism, and will not want to use it any time soon, it may send this directive:
サーバがMeterメカニズムを使用したくなくて、すぐいつでもそれを使用したくならないなら、この指示を送るかもしれません:
wont-ask recommends that the proxy SHOULD NOT send any Meter
directives to this server.
習慣で尋ねてください。プロキシSHOULD NOTがどんなMeter指示もこのサーバに送ることを勧めます。
Mogul & Leach Standards Track [Page 13] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[13ページ]RFC2227
The proxy SHOULD remember this fact for up to 24 hours. This avoids virtually all unnecessary overheads for servers that do not wish to use or support the Meter header. (This directive also implies "dont-report".)
プロキシSHOULDは24時間までこの事実を覚えています。 これはMeterヘッダーを使用したくないか、支えたがっていないサーバのために、ほとんどすべての不要なオーバーヘッドを避けます。 (また、この指示は「dont-レポート」を含意します。)
3.4 Transmission of usage reports
3.4 用法レポートの伝達
To transmit a usage report, a proxy sends the following Meter header in a request on the appropriate resource:
用法レポートを伝えるために、プロキシは要求で以下のMeterヘッダーを適切なリソースに送ります:
Meter: count=NNN/MMM
以下を計量してください。 =NNN/を数えてください、えー。
The first integer indicates the count of uses of the cache entry since the last report; the second integer indicates the count of reuses of the entry (see section 5.3 for rules on counting uses and reuses). The transmission of a "count" directive in a request with no other Meter directive is also defined as an implicit transmission of a "will-report-and-limit" directive, to optimize the common case. (A proxy not willing to honor usage-limits would send "Meter: count=NNN/MMM, wont-limit" for its reports.)
最初の整数は最後のレポート以来のキャッシュエントリーの用途のカウントを示します。 2番目の整数はエントリーの再利用のカウントを示します(用途と再利用を数えるとき、規則に関してセクション5.3を見てください)。 また、他のMeter指示のない要求における、「カウント」指示の送信は、よくある例を最適化するために「レポートと限界を望んでください」という指示の暗黙の送信と定義されます。 (用法限界を光栄に思うことを望んでいないプロキシはレポートのために「計量してください: =NNN/MMM、習慣の限界を数えてください」を送るでしょう。)
Note that when a proxy forwards a client's request and receives a response, the response that the proxy sends immediately to the requesting client is not counted as a "use". I.e., the reported count is the number of times the cache entry was used, and not the number of times that the response was used.
プロキシがクライアントの要求を転送して、応答を受けるとき、プロキシがすぐ要求しているクライアントに送る応答が「使用」にみなされないことに注意してください。 すなわち、報告されたカウントは応答が使用されたという回の数ではなく、キャッシュエントリーが使用されたという回の数です。
A proxy SHOULD NOT transmit "Meter: count=0/0", since this conveys no useful information.
SHOULD NOTが伝えるプロキシは「以下を計量します」。 これが役に立つ情報を全く伝えないので、=0/0インチを数えてください。
Usage reports MUST always be transmitted as part of a conditional request (such as a GET or HEAD), since the information in the conditional header (e.g., If-Modified-Since or If-None-Match) is required for the origin server to know which instance of a resource is being counted. Proxys forwarding usage reports up the metering subtree MUST NOT change the contents of the conditional header, since otherwise this would result in incorrect counting.
条件付き要求(GETかHEADなどの)の一部としていつも用法レポートを伝えなければなりません、起源サーバが、リソースのどの例が数えられているかを知るのに条件付きのヘッダー(例えば以来変更されたIfかなにも合わせないIf)の情報が必要であるので。 用法レポートを計量下位木に転送するProxysは条件付きのヘッダーのコンテンツを変えてはいけません、さもなければ、これが不正確な勘定をもたらすでしょう、したがって。
A usage report MUST NOT be transmitted as part of a forwarded request that includes multiple entity tags in an If-None-Match or If-Match header.
複数の実体タグを含んでいる転送された要求の一部としてなにも合わせないIfかIf-マッチヘッダーで用法レポートを伝えてはいけません。
Note: a proxy that offers its willingness to do hit-metering
(report usage) must count both uses and reuses. It is not
possible to negotiate the reporting of one but not the other.
以下に注意してください。 ヒット計量(レポート用法)をする意欲を提供するプロキシは用途と再利用の両方を数えなければなりません。 もう片方ではなく、1の報告を交渉するのは可能ではありません。
Mogul & Leach Standards Track [Page 14] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[14ページ]RFC2227
3.5 When to send usage reports
3.5 いつ用法を送るかは報告します。
A proxy that has offered to send usage reports to its parent in the metering subtree MUST send a usage report in each of these situations:
計量下位木で用法レポートを親に送ると申し出たプロキシはそれぞれのこれらの状況における用法レポートを送らなければなりません:
1. When it forwards a conditional GET on the resource
instance on behalf of one of its clients (if the GET is
conditional on at most one entity-tag).
1. リソース例でクライアントのひとりを代表して条件付きのGETを進めるとき(GETが高々1個の実体タグしか依存していないなら)。
2. When it forwards a conditional HEAD on the resource
instance on behalf of one of its clients.
2. リソース例でクライアントのひとりを代表して条件付きのHEADを進めるとき。
3. When it must generate a conditional GET to satisfy a
client request because the max-uses limit has been
exceeded.
3. 最大用途限界が超えられているのでクライアント要求を満たすために条件付きのGETを発生させなければならないと。
4. Upon expiration of a metering timeout associated with a
cache entry that has a non-zero hit-count.
4. キャッシュエントリーに関連している計量タイムアウトの満了のときに、それには、非ゼロヒット数があります。
5. When it removes the corresponding non-zero hit-count entry
from its storage for any reason including:
5. 推論して、:それがいずれのための格納から対応する非ゼロヒット数エントリーを取り除いたら推論してください。
- the proxy needs the storage space for another
hit-count entry.
- プロキシは別のヒット数エントリーに集積スペースを必要とします。
- the proxy is not able to store more than one response
per resource, and a request forwarded on behalf of a
client has resulted in the receipt of a new response
(one with a different entity-tag or last-modified
time).
- プロキシは1リソースあたり1つ以上の応答を格納できません、そして、クライアントを代表して転送された要求は新しい応答(異なった実体タグか最後変更された時間がある1)の領収書をもたらしました。
Note that a cache might continue to store hit-count information
even after having deleted the body of the response, so it is
not necessary to report the hit-count when deleting the body;
it is only necessary to report it if the proxy is about to
"forget" a non-zero value.
ボディーを削除するとき、ヒット数を報告するのは必要でないようにキャッシュが、応答のボディーを削除さえした後にさえヒット数情報を格納し続けるかもしれないことに注意してください。 プロキシが非ゼロ値を「忘れようとしている」なら、単にそれを報告するのが必要です。
(Section 5.3 explains how hit-counts become zero or non-zero.)
(セクション5.3はヒット数がどうゼロか非ゼロになるかを説明します。)
If the usage report is being sent because the proxy is about to remove the hit-count entry from its storage, or because of an expired metering timeout:
プロキシが格納、または満期の計量タイムアウトのためにヒット数エントリーを取り除こうとしているので用法レポートを送るなら:
- The proxy MUST send the report as part of a conditional
HEAD request on the resource instance.
- プロキシは条件付きのHEAD要求の一部としてリソース例にレポートを送らなければなりません。
Mogul & Leach Standards Track [Page 15] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[15ページ]RFC2227
- The proxy is not required to retry the HEAD request if it
fails (this is a best-efforts design). To improve
accuracy, however, the proxy SHOULD retry failed HEAD
requests, subject to resource constraints.
- 失敗するなら(これは最善の努力デザインです)、プロキシはHEAD要求を再試行する必要はありません。 しかしながら、精度を改良するために、プロキシSHOULD再試行はリソース規制を条件としてHEAD要求に失敗しました。
- The proxy is not required to serialize any other operation
on the completion of this request.
- プロキシはこの要求の完成のときにいかなる他の操作も連載する必要はありません。
Note: proxy implementors are strongly encouraged to batch several
HEAD-based reports to the same server, when possible, over a
single persistent connection, to reduce network overhead as much
as possible. This may involve a non-naive algorithm for
scheduling the deletion of hit-count entries.
以下に注意してください。 ただ一つのパーシステントコネクションの上で可能であるときに、プロキシ作成者がネットワークオーバーヘッドをできるだけ下げるよう強く同じサーバへのバッチいくつかのHEADベースのレポートに奨励されます。 これはヒット数エントリーの削除の計画をするための非ナイーブなアルゴリズムにかかわるかもしれません。
If the usage count is sent because of an arriving request that also carries a "count" directive, the proxy MUST combine its own (possibly zero) use and reuse counts with the arriving counts, and then attempt to forward the request.
また、「カウント」指示を運ぶ到着要求のために用法カウントを送るなら、プロキシは、それ自身(ことによるとゼロ)の使用を結合して、到着カウントでカウントを再利用して、要求を転送するのを試みなければなりません。
However, the proxy is not required to forward an arriving request with a "count" directive, provided that:
しかしながら、プロキシが「カウント」指示と共に到着要求を転送する必要はない、:
- it can reply to the request using a cached response, in
compliance with other requirements of the HTTP
specification.
- それは、HTTP仕様の他の要件に従ってキャッシュされた応答を使用することで要求に答えることができます。
- such a response does not exceed a max-uses limit.
- そのような応答は最大用途限界を超えていません。
- it is not required to forward the request because of an
expired metering timeout.
- それは、満期の計量タイムアウトのために要求を転送するのに必要ではありません。
If an arriving request carries a "count" directive, and the proxy no longer has a cache entry for the resource, the proxy MUST forward the "count" directive. (This is, in any case, what a proxy without a suitable cache entry would normally do for any valid request it receives.)
到着要求が「カウント」指示を運んで、プロキシにリソースのためのキャッシュエントリーがもうないなら、プロキシは「カウント」指示を進めなければなりません。 (どのような場合でも、これは通常、適当なキャッシュエントリーのないプロキシがそれが受け取るどんな有効な要求のためにもすることです。)
3.6 Subdivision of usage-limits
3.6 用法限界の下位区分
When an origin server specifies a usage limit, a proxy in the metering subtree may subdivide this limit among its children in the subtree as it sees fit.
起源サーバが用法限界を指定するとき、計量下位木におけるプロキシは適していると決めるように子供で下位木でこの限界を細分するかもしれません。
For example, consider the situation with two proxies P1 and P2, each of which uses proxy P3 as a way to reach origin server S. Imagine that S sends P3 a response with
例えば、2つのプロキシがある状況がP1とP2であると考えてください。それは応答をP3にSと送る起源サーバS.イマジンに達する方法としてそれぞれプロキシP3を使用します。
Mogul & Leach Standards Track [Page 16] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[16ページ]RFC2227
Meter: max-uses=10
以下を計量してください。 最大用途=10
The proxies use that response to satisfy the current requesting end- client. The max-uses directive in this example allows the combination of P1, P2, and P3 together to satisfy 10 additional end- client uses (unconditional GETs) for the resource.
プロキシは、終わりのクライアントを要求する電流を満たすのにその応答を使用します。 この例における最大用途指示で、P1、P2、および一緒にP3の組み合わせはリソースへの10の追加終わりのクライアント用途(無条件のGETs)を満たすことができます。
This specification does not constrain how P3 divides up that allocation among itself and the other proxies. For example, P3 could retain all of max-use allocation for itself. In that case, it would forward the response to P1 and/or P2 with
この仕様はP3がそれ自体と他のプロキシの中でどうその配分に分割するかを抑制しません。 例えば、P3はそれ自体のための最大使用配分のすべてを保有できました。 その場合、それはP1、そして/または、P2への応答を進めるでしょう。
Meter: max-uses=0
以下を計量してください。 最大用途=0
P3 might also divide the allocation equally among P1 and P2, retaining none for itself (which may be the right choice if P3 has few or no other clients). In this case, it could send
また、P3はP1とP2の中で等しく配分を分割するかもしれません、それ自体(P3にどんなわずかも他のクライアントもいないなら、正しい選択であるかもしれない)のためのなにも保有しないで。 この場合、それは発信できました。
Meter: max-uses=5
以下を計量してください。 最大用途=5
to the proxy (P1 or P2) that made the initial request, and then record in some internal data structure that it "owes" the other proxy the rest of the allocation.
プロキシ(P1かP2)に、それは、初期の要求をして、次に、もう片方のプロキシに配分の残りを「負っている」という何らかの内部のデータ構造における記録をしました。
Note that this freedom to choose the max-uses value applies to the origin server, as well. There is no requirement that an origin server send the same max-uses value to all caches. For example, it might make sense to send "max-uses=2" the first time one hears from a cache, and then double the value (up to some maximum limit) each time one gets a "use-count" from that cache. The idea is that the faster a cache is using up its max-use quota, the more likely it will be to report a use-count value before removing the cache entry. Also, high and frequent use-counts imply a corresponding high efficiency benefit from allowing caching.
最大用途値を選ぶこの自由がまた、起源サーバに適用されることに注意してください。 起源サーバが同じ最大用途値をすべてのキャッシュに送るという要件が全くありません。 例えば、それは「何最大用途=2インチも、初めての人の声がキャッシュから聞いて、次に、各回1値(何らかの最大の限界までの)の二重はaがそれから「使用して数えられる」というキャッシュを得ること」を送る意味になるかもしれません。 考えはキャッシュが、より速く最大使用割当てを使いきれば使いきるほど、キャッシュエントリーを取り除く前にカウントを使用している値をより報告しそうであるということです。 また、高く頻繁である、使用して数える、キャッシュするのを許容するので、対応する高性能利益を含意してください。
Again, the details of such heuristics would be outside the scope of this specification.
一方、この仕様の範囲の外にそのような発見的教授法の詳細があるでしょう。
4 Analysis
4 分析
This section includes informal analyses of several aspects of hit- metering:
このセクションはヒット計量のいくつかの局面の非公式の分析を含んでいます:
1. the accuracy of results when applied to counting users
(section 4.1).
1. 精度、結果について、いつがユーザ(セクション4.1)を数えるのに適用されましたか?
2. the problem of counting users whose browsers do not
include caches, such as Network Computers (section 4.2).
2. ブラウザがNetworkコンピュータなどのキャッシュ(セクション4.2)を含んでいないユーザを数えるという問題。
Mogul & Leach Standards Track [Page 17] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[17ページ]RFC2227
3. delays imposed on "critical paths" for HTTP operations
(section 4.3).
3. HTTP操作(セクション4.3)のために「クリティカルパス」に課された遅れ。
4.1 Approximation accuracy for counting users
4.1 ユーザを数えるための近似精度
For many (but not all) service operators, the single most important aspect of the request stream is the number of distinct users who have retrieved a particular entity within a given period (e.g., during a given day). The hit-metering mechanism is designed to provide an origin server with an approximation of the number of users that reference a given resource. The intent of the design is that the precision of this approximation is consistent with the goals of simplicity and optional implementation.
多くの(すべてでない)サービスオペレータにとって、要求ストリームの最も重要な局面は与えられた期間(例えば、与えられた日間の)以内に特定の実体を検索した異なったユーザの数です。 ヒットを計量するメカニズムは、当然のことのリソースに参照をつけるユーザの数の近似を起源サーバに提供するように設計されています。 デザインの意図はこの近似の精度が簡単さと任意の実現の目標と一致しているということです。
Almost all Web users use client software that maintains local caches, and the state of the art of local-caching technology is quite effective. (Section 4.2 discusses the case where end-client caches are small or non-existent.) Therefore, assuming an effective and persistent end-client cache, each individual user who retrieves an entity does exactly one GET request that results in a 200 or 203 response, or a 206 response that includes the first byte of the entity. If a proxy cache maintains and reports an accurate use-count of such retrievals, then its reported use-count will closely approximate the number of distinct users who have retrieved the entity.
ほとんどすべてのウェブユーザがローカルなキャッシュを維持するクライアントソフトウェアを使用します、そして、地方のキャッシュ技術の到達技術水準はかなり効果的です。 (セクション4.2は終わりクライアントキャッシュが小さいか、または実在しないケースについて論じます。) したがって、有効でしつこい終わりクライアントキャッシュを仮定して、実体を検索するそれぞれの個々のユーザがまさに200か203応答をもたらすGETが要求するもの、または実体の最初のバイトを含んでいる206応答をします。 プロキシキャッシュが正確なカウントを使用しているそのようなretrievalsを維持して、報告するなら、報告されたカウントを使用している意志は密接に実体を検索した異なったユーザの数に近似します。
There are some circumstances under which this approximation can break down. For example, if an entity stays in a proxy cache for much longer than it persists in the typical client cache, and users often re-reference the entity, then this scheme will tend to over-count the number of users. Or, if the cache-management policy implemented in typical client caches is biased against retaining certain kinds of frequently re-referenced entities (such as very large images), the use-counts reported will tend to overestimate the user-counts for such entities.
この近似が故障できるいくつかの事情があります。 典型的なクライアントキャッシュに固執するよりはるかに長い間、実体はプロキシキャッシュに残っているかどうか、そして、例えば、ユーザしばしば数を数え過ぎる次に、実体、この計画が、傾向がある再参照ユーザ。 または、典型的なクライアントキャッシュで実施されるキャッシュ管理政策が保有のある種類の頻繁に再参照をつけられた実体(非常に大きいイメージなどの)に対して偏られると、カウントを使用するのは、報告されるそのような実体のためのユーザカウントを過大評価する傾向があるでしょう。
Browser log analysis has shown that when a user revisits a resource, this is almost always done very soon after the previous visit, almost always with fewer than eight intervening references [11]. Although this result might not apply universally, it implies that almost all reuses will hit in the end-client cache, and will not be seen as unconditional GETs by a proxy cache.
ログ解析でユーザがすぐリソースを再訪させるとき、前の訪問の後にほとんどこれをほとんどいつもいつもするのを8つ未満の介入している参照箇所[11]で示すブラウザ。 この結果はあまねく当てはまらないかもしれませんが、それは、ほとんどすべての再利用が終わりクライアントキャッシュで当たって、プロキシキャッシュによって無条件のGETsと考えられないのを含意します。
The existing (HTTP/1.0) "cache-busting" mechanisms for counting distinct users will certainly overestimate the number of users behind a proxy, since it provides no reliable way to distinguish between a user's initial request and subsequent repeat requests that might have been conditional GETs, had not cache-busting been employed. The
異なったユーザを数えると条件付きのGETsであったかもしれないユーザの初期の要求とその後の反復要求を見分けるどんな信頼できる方法も提供しないのでユーザの数が確かにプロキシの後ろで過大評価されるので、(HTTP/1.0)既存の「キャッシュを破産した」メカニズムには、使われたキャッシュ破産がありませんでした。 The
Mogul & Leach Standards Track [Page 18] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[18ページ]RFC2227
"Cache-control: s-maxage=0" feature of HTTP/1.1 does allow the separation of use-counts and reuse-counts, provided that no HTTP/1.0 proxy caches intervene.
「キャッシュで制御してください」 HTTP/1.0のプロキシキャッシュに全く介入しなければ、0インチが特集するHTTP/1.1のs-maxage=はカウントを使用してカウントを再利用する分離を許容します。
Note that if there is doubt about the validity of the results of hit-metering a given set of resources, the server can employ cache- busting techniques for short periods, to establish a baseline for validating the hit-metering results. Various approaches to this problem are discussed in a paper by James Pitkow [9].
与えられたセットのリソースをヒットで計量するという結果の正当性に関する疑問があれば、サーバがヒットを計量する結果を有効にするために基線を証明するためにテクニックを短い間破産させながらキャッシュを使うことができることに注意してください。 この問題への様々なアプローチは論文でジェームスPitkow[9]によって議論されています。
4.2 What about "Network Computers"?
4.2 「ネットワーク・コンピュータ」はどうですか?
The analysis in section 4.1 assumed that "almost all Web users" have client caches. If the Network Computers (NC) model becomes popular, however, then this assumption may be faulty: most proposed NCs have no disk storage, and relatively little RAM. Many Personal Digital Assistants (PDAs), which sometimes have network access, have similar constraints. Such client systems may do little or no caching of HTTP responses. This means that a single user might well generate many unconditional GETs that yield the same response from a proxy cache.
セクション4.1での分析は、「ほとんどすべてのウェブユーザ」にはクライアントキャッシュがあると仮定しました。 しかしながら、Networkコンピュータ(NC)モデルがポピュラーになるなら、この仮定は不完全であるかもしれません: ほとんどの提案されたNCsには、ディスク格納、およびどんな比較的小さいRAMもありません。 多くのパーソナルDigital Assistants(PDA)には、同様の規制があります。(Assistantsは時々ネットワークアクセスを持っています)。 そのようなクライアントシステムはまずHTTP応答のキャッシュをしないかもしれません。 これは、シングルユーザーがたぶんプロキシキャッシュから同じ応答をもたらす多くの無条件のGETsを発生させるだろうことを意味します。
First note that the hit-metering design in this document, even with such clients, provides an approximation no worse than available with unmodified HTTP/1.1: the counts that a proxy would return to an origin server would represent exactly the number of requests that the proxy would forward to the server, if the server simply specifies "Cache-control: s-maxage=0".
まず最初に、ヒットを計量するデザインが本書ではそのようなクライアントがいても変更されていないHTTP/1.1を利用可能であるほど悪くない近似に提供することに注意してください: プロキシが起源サーバに返すカウントはまさに表すでしょう。サーバがプロキシがサーバに転送する要求単に指定するなら、数は「以下をキャッシュで制御します」。 s-maxage=0インチ。
However, it may be possible to improve the accuracy of these hit- counts by use of some heuristics at the proxy. For example, the proxy might note the IP address of the client, and count only one GET per client address per response. This is not perfect: for example, it fails to distinguish between NCs and certain other kinds of hosts. The proxy might also use the heuristic that only those clients that never send a conditional GET should be treated this way, although we are not at all certain that NCs will never send conditional GETs.
しかしながら、プロキシのいくつかの発見的教授法の使用でこれらのヒットカウントの精度を改良するのは可能であるかもしれません。 例えば、プロキシは、クライアントのIPアドレスに注意して、応答単位でクライアントアドレスあたり1GETだけを数えるかもしれません。 これは完全ではありません: 例えば、それはNCsと他のある種類のホストを見分けません。 プロキシは送るかもしれません、また、それらのクライアントだけが条件付きのGETを決して送らないヒューリスティックがそうするべきである使用がこのように扱われて、私たちが全く確信していませんが、そのNCsは条件付きのGETsは決して送らないでしょう。
Since the solution to this problem appears to require heuristics based on the actual behavior of NCs (or perhaps a new HTTP protocol feature that allows unambiguous detection of cacheless clients), it appears to be premature to specify a solution.
この問題の解決がNCs(または、恐らくcachelessクライアントの明白な検出を許す新しいHTTPプロトコル機能)の実際の動きに基づく発見的教授法を必要とするように見えるので、解決策を指定するのが時期尚早であるように見えます。
4.3 Critical-path delay analysis
4.3 クリティカルパス遅れ分析
In systems (such as the Web) where latency is at issue, there is usually a tree of steps which depend on one another, in such a way that the final result cannot be accomplished until all of its predecessors have been. Since the tree structure admits some
問題には潜在があるシステム(ウェブなどの)には、通常、お互いに頼るステップの木があります、前任者が皆、いるまで最終的な結果を達成できないような方法で。 木構造がいくつかを認めるので
Mogul & Leach Standards Track [Page 19] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[19ページ]RFC2227
parallelism, it is not necessary to add up the timings for each step to discover the latency for the entire process. But any single path through this dependency tree cannot be parallelized, and the longest such path is the one whose length (in units of seconds) determines the overall latency. This is the "critical path", because no matter how much shorter one makes any other path, that cannot change the overall latency for the final result.
平行関係、各ステップが全体の過程に関して潜在を発見するようにタイミングを合計するのは必要ではありません。 しかし、この依存木を通したどんなただ一つの経路もparallelizedされることができません、そして、そのような最も長い経路は長さ(ユニットの秒の)が総合的な潜在を決定するものです。 これは「クリティカルパス」です、どのくらいのより短い1つが他の経路を作っても、それが最終的な結果のために総合的な潜在を変えることができないので。
If one views the final result, for a Web request, as rendering a page at a browser, or otherwise acting on the result of a request, clearly some network round trips (e.g., exchanging TCP SYN packets if the connection doesn't already exist) are on the critical path. This hit-metering design does add some round-trips for reporting non-zero counts when a cache entry is removed, but, by design, these are off any critical path: they may be done in parallel with any other operation, and require only "best efforts", so a proxy does not have to serialize other operations with their success or failure.
人が最終的な結果を見るなら、周遊旅行(例えば、接続が既に存在していないなら、TCP SYNパケットを交換する)がウェブ要求のために明確に何らかのネットワークをブラウザに1ページ表すか、またはそうでなければ、要求の結果に活動させるとして、クリティカルパスにあります。 このヒットを計量するデザインはキャッシュエントリーを取り除きますが、これらが故意にどんなクリティカルパスにもあるとき非ゼロカウントを報告するためのいくつかの周遊旅行を加えます: 彼らがいかなる他の操作と平行してして、「最善の努力」だけ、を必要とするかもしれないので、プロキシはそれらの成否に伴う他の操作を連載する必要はありません。
Clearly, anything that changes network utilization (either increasing or decreasing it) can indirectly affect user-perceived latency. Our expectation is that hit-metering, on average, will reduce loading and so even its indirect effects should not add network round-trips in any critical path. But there might be a few specific instances where the added non-critical-path operations (specifically, usage reports upon cache-entry removal) delay an operation on a critical path. This is an unavoidable problem in datagram networks.
明確に、ネットワーク利用(それを増加するか、または減少させる)を変える何でも間接的にユーザによって知覚された潜在に影響できます。 私たちの期待はヒット計量がローディングを平均的に抑えて、間接的な効果さえどんなクリティカルパスでも丸い旅行であるネットワークを加えるべきでないということです。 しかし、いくつかの特定の例が加えられた非クリティカルパス操作(明確に、用法はキャッシュエントリー取り外しについて報告する)が操作をクリティカルパスに遅らせるところにあるかもしれません。 これはデータグラム・ネットワークで避けて通れない問題です。
5 Specification
5 仕様
5.1 Specification of Meter header and directives
5.1 Meterヘッダーと指示の仕様
The Meter general-header field is used to:
Meterの一般的なヘッダーフィールドは以下のことに使用されます。
- Negotiate the use of hit-metering and usage-limiting among
origin servers and proxy caches.
- 起源サーバとプロキシキャッシュの中でヒット計量と用法制限の使用を交渉してください。
- Report use counts and reuse counts.
- レポート使用は重要です、そして、再利用は重要です。
Implementation of the Meter header is optional for both proxies and origin servers. However, any proxy that transmits the Meter header in a request MUST implement every requirement of this specification, without exception or amendment.
プロキシと起源サーバの両方に、Meterヘッダーの実現は任意です。 しかしながら、要求でMeterヘッダーを伝えるどんなプロキシもこの仕様のあらゆる要件を実行しなければなりません、例外も修正なしで。
The Meter header MUST always be protected by a Connection header. A proxy that does not implement the Meter header MUST NOT pass it through to another system (see section 5.5 for how a non-caching proxy may comply with this specification). If a Meter header is
ConnectionヘッダーはいつもMeterヘッダーを保護しなければなりません。 Meterヘッダーを実行しないプロキシは別のシステムに突き抜けた状態でそれを通過してはいけません(非キャッシュしているプロキシがどうこの仕様に従うことができるように、セクション5.5を見てくださいか)。 Meterヘッダーがそうなら
Mogul & Leach Standards Track [Page 20] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[20ページ]RFC2227
received in a message whose version is less than HTTP/1.1, it MUST be ignored (because it has clearly flowed through a proxy that does not implement Meter).
バージョンがHTTP/1.1以下であるメッセージで受け取られていて、それを無視しなければなりません(Meterを実行しないプロキシを通して明確に流れたので)。
A proxy that has received a response with a version less than HTTP/1.1, and therefore from a server (or another proxy) that does not implement the Meter header, SHOULD NOT send Meter request directives to that server, because these would simply waste bandwidth. This recommendation does not apply if the proxy is currently hit-metering or usage-limiting any responses from that server. If the proxy receives a HTTP/1.1 or higher response from such a server, it should cease its suppression of the Meter directives.
バージョンでMeterヘッダーを実行しないサーバ(または、別のプロキシ)からHTTP/1.1よりそれほどと、そして、したがって、応答を受けたプロキシ、SHOULD NOTはそのサーバへの要求指示をMeterに送ります、これらが単に帯域幅を浪費するでしょう、したがって。 プロキシが現在何かそのサーバからの応答をヒットで計量するか、または用法で制限しているなら、この推薦は適用されません。プロキシがそのようなサーバからHTTP/1.1以上応答を受けるなら、それはMeter指示の抑圧をやめるべきです。
All proxies sending the Meter header MUST adhere to the "metering subtree" design described in section 3.
Meterヘッダーを送るすべてのプロキシがセクション3で説明された「計量下位木」デザインを固く守らなければなりません。
Meter = "Meter" ":" 0#meter-directive
「メーター=「メーター」」:、」 0#メーター指示
meter-directive = meter-request-directive
| meter-response-directive
| meter-report-directive
メーター指示=メーター要求指示| メーター応答指示| メーターレポート指示
meter-request-directive =
"will-report-and-limit"
| "wont-report"
| "wont-limit"
メーター要求指示は「レポートと限界を望んでください」と等しいです。| 「習慣のレポート」| 「習慣の限界」
meter-report-directive =
| "count" "=" 1*DIGIT "/" 1*DIGIT
メーターレポート指示=| 「「」 「=」1*ケタを数えてください」という/」1*ケタ
meter-response-directive =
"max-uses" "=" 1*DIGIT
| "max-reuses" "=" 1*DIGIT
| "do-report"
| "dont-report"
| "timeout" "=" 1*DIGIT
| "wont-ask"
メーター応答指示=「最大用途」は1*ケタと「等しいです」。| 「最大再利用」は1*ケタと「等しいです」。| 「レポートする、」| 「dont-レポート」| 「タイムアウト」は1*ケタと「等しいです」。| 「習慣で尋ねてください」
A meter-request-directive or meter-report-directive may only appear in an HTTP request message. A meter-response-directive may only appear in an HTTP response directive.
メーター要求指示かメーターレポート指示がHTTP要求メッセージに現れるだけであるかもしれません。 メーター応答指示はHTTP応答指示に現れるだけであるかもしれません。
An empty Meter header in a request means "Meter: will-report-and- limit". An empty Meter header in a response, or any other response including one or more Meter headers without the "dont-report" or "wont-ask" directive, implies "Meter: do-report".
「計量してください。」と、要求における空のMeterヘッダーは言っています。 そして、「意志で報告してください、-、-、限界、」 「計量してください。」と、応答、または「dont-レポート」も「習慣で尋ねている」指示なしで1個以上のMeterヘッダーを含むいかなる他の応答における空のMeterヘッダーも暗示します。 「レポートする、」
Mogul & Leach Standards Track [Page 21] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[21ページ]RFC2227
The meaning of the meter-request-directives are as follows:
メーター要求指示の意味は以下の通りです:
will-report-and-limit
indicates that the proxy is willing and able to
return usage reports and will obey any usage-limits.
意志のレポートと限界は、プロキシが望んでいて用法レポートを返すことができるのを示して、どんな用法限界にも従うでしょう。
wont-report indicates that the proxy will obey usage-limits but
will not send usage reports.
習慣のレポートは、プロキシが用法限界に従いますが、用法レポートを送らないのを示します。
wont-limit indicates that the proxy will not obey usage-limits
but will send usage reports.
習慣の限界は、プロキシが用法限界に従いませんが、用法レポートを送るのを示します。
A proxy willing neither to obey usage-limits nor to send usage reports MUST NOT transmit a Meter header in the request.
用法限界に従って、用法レポートを送るどちらも要求でMeterヘッダーを伝えてはいけないことを望んでいるプロキシ。
The meaning of the meter-report-directives are as follows:
メーターレポート指示の意味は以下の通りです:
count "=" 1*DIGIT "/" 1*DIGIT
Both digit strings encode decimal integers. The
first integer indicates the count of uses of the
cache entry since the last report; the second integer
indicates the count of reuses of the entry.
両方のケタストリングがコード化する「カウントが「」 1*ケタと等しい」という/」1*ケタ、10進整数。 最初の整数は最後のレポート以来のキャッシュエントリーの用途のカウントを示します。 2番目の整数はエントリーの再利用のカウントを示します。
Section 5.3 specifies the counting rules.
セクション5.3は勘定規則を指定します。
The meaning of the meter-response-directives are as follows:
メーター応答指示の意味は以下の通りです:
max-uses "=" 1*DIGIT
sets an upper limit on the number of "uses" of the
response, not counting its immediate forwarding to
the requesting end-client, for all proxies in the
following subtree taken together.
最大用途「=」1*ケタは応答の「用途」の数に上限を設定します、要求している終わりクライアントまで即座の推進を数えないで、一緒に取られた以下の下位木におけるすべてのプロキシのために。
max-reuses "=" 1*DIGIT
sets an upper limit on the number of "reuses" of the
response for all proxies in the following subtree
taken together.
最大再利用「=」1*ケタはすべてのプロキシのための応答の「再利用」の数に一緒に取られた以下の下位木で上限を設定します。
do-report specifies that the proxy MUST send usage reports to
the server.
レポートする、プロキシが用法レポートをサーバに送らなければならないと指定します。
dont-report specifies that the proxy SHOULD NOT send usage
reports to the server.
dont-レポートは、プロキシSHOULD NOTが用法レポートをサーバに送ると指定します。
timeout "=" 1*DIGIT
sets a metering timeout of the specified number of
minutes (not seconds) after the origination of this
response (as indicated by its "Date" header). If the
タイムアウト「=」1*ケタはこの応答の創作の何分も後(秒でない)の指定された数の計量タイムアウトを設定します(「日付」ヘッダーによって示されるように)。 the
Mogul & Leach Standards Track [Page 22] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[22ページ]RFC2227
proxy has a non-zero hit count for this response when
the timeout expires, it MUST send a report to the
server at or before that time. Timeouts should be
implemented with an accuracy of plus or minus one
minute. Implies "do-report".
プロキシには、タイムアウトが期限が切れると、この応答のための非ゼロヒット数があって、それはその時かその時以前、レポートをサーバに送らなければなりません。 タイムアウトはプラスかマイナス1分の精度で実行されるべきです。 含意、「レポートする、」
wont-ask specifies that the proxy SHOULD NOT send any Meter
headers to the server. The proxy should forget this
advice after a period of no more than 24 hours.
習慣で尋ねてください。プロキシが24時間未満の期間の後にこのアドバイスを忘れるべきであると指定します。プロキシSHOULD NOTはどんなMeterヘッダーもサーバに送ります。
Section 5.3 specifies the counting rules, and in particular specifies a somewhat non-obvious interpretation of the max-uses value.
セクション5.3は、勘定規則を指定して、最大用途価値のいくらか非明白な解釈を特に指定します。
5.2 Abbreviations for Meter directives
5.2 Meter指示のための略語
To allow for the most efficient possible encoding of Meter headers, we define abbreviated forms of all Meter directives. These are exactly semantically equivalent to their non-abbreviated counterparts. All systems implementing the Meter header MUST implement both the abbreviated and non-abbreviated forms. Implementations SHOULD use the abbreviated forms in normal use.
Meterヘッダーの可能な限り効率的なコード化を考慮するために、私たちはすべてのMeter指示の簡略化された書式を定義します。 彼らの非簡略化された対応者には、これらはまさに意味的に同等です。 Meterヘッダーを実行するすべてのシステムが簡略化されて非簡略化されたフォームを実行しなければなりません。実現SHOULDは通常の使用で簡略化されたフォームを使用します。
The abbreviated forms of Meter directive are shown below, with the corresponding non-abbreviated literals in the comments:
Meter指示の簡略化された書式は以下にコメントにおける対応する非簡略化された誤字誤植で示されます:
Abb-Meter = "Meter" ":" 0#abb-meter-directive
「Abb-メーター=「メーター」」:、」 0#abb-メーター指示
abb-meter-directive = abb-meter-request-directive
| abb-meter-response-directive
| abb-meter-report-directive
abbメーター指示=abbメーター要求指示| abbメーター応答指示| abbメーターレポート指示
abb-meter-request-directive =
"w" ; "will-report-and-limit"
| "x" ; "wont-report"
| "y" ; "wont-limit"
abbメーター要求指示は「w」と等しいです。 「レポートと限界を望んでください」| 「x」。 「習慣のレポート」| 「y」。 「習慣の限界」
abb-meter-report-directive =
| "c" "=" 1*DIGIT "/" 1*DIGIT ; "count"
abbメーターレポート指示=| 「「c」「=」1*ケタ」/」1*ケタ。 「数えてください」
abb-meter-response-directive =
"u" "=" 1*DIGIT ; "max-uses"
| "r" "=" 1*DIGIT ; "max-reuses"
| "d" ; "do-report"
| "e" ; "dont-report"
| "t" "=" 1*DIGIT ; "timeout"
| "n" ; "wont-ask"
abbメーター応答指示=「u」は1*ケタと「等しいです」。 「最大用途」| 「r」は1*ケタと「等しいです」。 「最大再利用」| 「d」。 「レポートする、」| 「e」。 「dont-レポート」| 「t」は1*ケタと「等しいです」。 「タイムアウト」| 「n」。 「習慣で尋ねてください」
Mogul & Leach Standards Track [Page 23] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[23ページ]RFC2227
Note: although the Abb-Meter BNF rule is defined separately from
the Meter rule, one may freely mix abbreviated and non-abbreviated
Meter directives in the same header.
以下に注意してください。 Abb-メーターBNF定規は別々にMeter規則から定義されますが、同じヘッダーで自由に簡略化されて非簡略化されたMeter指示を混ぜるかもしれません。
5.3 Counting rules
5.3 規則を数えること。
Note: please remember that hit-counts and usage-counts are
associated with individual responses, not with resources. A cache
entry that, over its lifetime, holds more than one response is
also not a "response", in this particular sense.
以下に注意してください。 ヒット数と用法カウントがリソースではなく、個々の応答に関連しているのを覚えていてください。 また、一生のうちに1つ以上の応答を保持するキャッシュエントリーは「応答」ではありません、この特定の意味で。
Let R be a cached response, and V be the value of the Request-URI and selecting request-headers (if any, see section 14.43 of the HTTP/1.1 specification [4]) that would select R if contained in a request. We define a "use" of R as occurring when the proxy returns its stored copy of R in a response with any of the following status codes: a 200 (OK) status; a 203 (Non-Authoritative Information) status; or a 206 (Partial Content) status when the response contains byte #0 of the entity (see section 5.4 for a discussion of Range requests).
Rがキャッシュされた応答であることをさせてください、Vは、Request-URIの値であり、要求ヘッダーを選んでいます。(いずれかであるなら、要求に含まれているならRを選択するセクション14.43のHTTP/1.1仕様[4])を見てください。 私たちは以下のステータスコードのどれかで応答でプロキシが格納されたコピーのRを返すとき起こるとRの「使用」を定義します: 200(OK)状態。 203(非正式の情報)状態。 または、応答が0つのバイト#実体を含むときの(Range要求の議論に関してセクション5.4を見てください)206(部分的なContent)状態。
Note: when a proxy forwards a client's request and receives a
response, the response that the proxy sends immediately to the
requesting client is not counted as a "use". I.e., the reported
count is the number of times the cache entry was used, and not the
number of times that the response was used.
以下に注意してください。 プロキシがクライアントの要求を転送して、応答を受けるとき、プロキシがすぐ要求しているクライアントに送る応答は「使用」にみなされません。 すなわち、報告されたカウントは応答が使用されたという回の数ではなく、キャッシュエントリーが使用されたという回の数です。
We define a "reuse" of R as as occurring when the proxy responds to a request selecting R with a 304 (Not Modified) status, unless that request is a Range request that does not specify byte #0 of the entity.
私たちはプロキシが304(Modifiedでない)状態でRを選択する要求に応じると起こるようにRの「再利用」を定義します、その要求が0つのバイト#実体を指定しないRange要求でないなら。
5.3.1 Counting rules for hit-metering
5.3.1 ヒット計量のための規則を数えること。
A proxy participating in hit-metering for a cache response R maintains two counters, CU and CR, associated with R. When a proxy first stores R in its cache, it sets both CU and CR to 0 (zero). When a subsequent client request results in a "use" of R, the proxy increments CU. When a subsequent client request results in a "reuse" of R, the proxy increments CR. When a subsequent client request selecting R (i.e., including V) includes a "count" Meter directive, the proxy increments CU and CR using the corresponding values in the directive.
キャッシュ応答Rが、2台のカウンタ(CUとCR)が最初にR.Whenにプロキシを関連づけたと主張するので、ヒット計量に参加するプロキシはキャッシュにRを格納して、それは0(ゼロ)にCUとCRの両方を設定します。 その後のクライアント要求がRの「使用」をもたらすと、プロキシはCUを増加します。 その後のクライアント要求がRの「再利用」をもたらすと、プロキシはCRを増加します。 R(すなわち、Vを含んでいる)を選択するその後のクライアント要求が「カウント」Meter指示を含んでいると、プロキシは、指示に換算値を使用することでCUとCRを増加します。
When the proxy sends a request selecting R (i.e., including V) to the inbound server, it includes a "count" Meter directive with the current CU and CR as the parameter values. If this request was caused by the proxy's receipt of a request from a client, upon receipt of the server's response, the proxy sets CU and CR to the
プロキシが要求にR(すなわち、Vを含んでいる)を本国行きのサーバに選択させるとき、パラメタが評価するようにそれは現在のCUとCRとの「カウント」Meter指示を含んでいます。 この要求はプロキシのプロキシがサーバの応答を受け取り次第CUとCRを設定するクライアントからの要求の領収書で引き起こされました。
Mogul & Leach Standards Track [Page 24] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[24ページ]RFC2227
number of uses and reuses, respectively, that may have occurred while the request was in progress. (These numbers are likely, but not certain, to be zero.) If the proxy's request was a final HEAD-based report, it need no longer maintain the CU and CR values, but it may also set them to the number of intervening uses and reuses and retain them.
要求が進行していた間、それぞれそれがそうする用途と再利用の数は現れています。 (これらの数は、ありそうですが、ゼロになるように確かではありません。) プロキシの要求が最終的なHEADベースのレポートであったなら、もうCUとCR値を維持する必要はありませんが、それは、また、介入している用途と再利用の数にそれらを設定して、それらを保有するかもしれません。
5.3.2 Counting rules for usage-limiting
5.3.2 用法制限のための規則を数えること。
A proxy participating in usage-limiting for a response R maintains either or both of two counters TU and TR, as appropriate, for that resource. TU and TR are incremented in just the same way as CU and CR, respectively. However, TU is zeroed only upon receipt of a "max-uses" Meter directive for that response (including the initial receipt). Similarly, TR is zeroed only upon receipt of a "max- reuses" Meter directive for that response.
応答Rのための用法制限に参加するプロキシは、2のどちらかか両方がTUとTRを打ち返すと主張します、適宜、そのリソースのために。 TUとTRはCUとCRとちょうど同じようにそれぞれ増加されます。 しかしながら、TUのゼロは単にその応答のための「最大用途」Meter指示を受け取り次第合わせられています(初期の領収書を含んでいて)。 同様に、TRのゼロは単にその応答のための「再利用に最大限にしてください」というMeter指示を受け取り次第合わせられています。
A proxy participating in usage-limiting for a response R also stores values MU and/or MR associated with R. When it receives a response including only a max-uses value, it sets MU to that value and MR to infinity. When it receives a response including only a max-reuses value, it sets MR to that value and MU to infinity. When it receives a response including both max-reuses and max-reuses values, it sets MU and MR to those values, respectively. When it receives a subsequent response including neither max-reuses nor max-reuses values, it sets both MU and MR to infinity.
それをR.Whenに関連している応答Rの店のも値のMU、そして/または、MRに用法で制限するのに参加するプロキシは最大用途値だけを含む応答を受けて、それはその値とMRにMUを無限で設定します。 最大再利用値だけを含む応答を受けるとき、それはその値とMUにMRを無限で設定します。 最大再利用と最大再利用値の両方を含む応答を受けるとき、それはそれぞれそれらの値にMUとMRを設定します。 最大再利用も最大再利用値も含まないその後の応答を受けるとき、それはMUとMRの両方を無限で設定します。
If a proxy participating in usage-limiting for a response R receives a request that would cause a "use" of R, and TU >= MU, it MUST forward the request to the server. If it receives a request that would cause a "reuse" of R, and TR >= MR, it MUST forward the request to the server. If (in either case) the proxy has already forwarded a previous request to the server and is waiting for the response, it should delay further handling of the new request until the response arrives (or times out); it SHOULD NOT have two revalidation requests pending at once that select the same response, unless these are Range requests selecting different subranges.
応答Rのための用法制限に参加するプロキシがRの「使用」を引き起こす要求を受け取って、TU>がMUと等しいなら、それは要求をサーバに転送しなければなりません。Rの「再利用」を引き起こす要求を受け取って、TR>がMRと等しいなら、それは要求をサーバに転送しなければなりません。(どちらかの場合における)プロキシが既に前の要求をサーバに転送して、応答を待っているなら、応答が到着するまで(または、回のアウト)、新しい要求の、より遠い取り扱いを遅らせるべきです。 SHOULD NOTには、すぐに、未定の2つの再合法化要求があります。それ、それは同じ応答を選択します、これらが異なったサブレンジを選択するRange要求でないなら。
There is a special case of this rule for the "max-uses" directive: if the proxy receives a response with "max-uses=0" and does not forward it to a requesting client, the proxy should set a flag PF associated with R. If R is true, then when a request arrives while if TU >= MU, if the PF flag is set, then the request need not be forwarded to the server (provided that this is not required by other caching rules). However, the PF flag MUST be cleared on any use of the response.
「最大用途」指示のためのこの規則の特別なケースがあります: プロキシが応答を受ける、「=0インチを最大に使用して、要求しているクライアント、プロキシにそれを送らない、設定aが弛むならR.If Rに関連しているPFが本当である、次に、PF旗を設定するなら>がTUであるならMUと等しいのですが、要求が到着するとき要求をサーバに転送する必要はない、(これが規則をキャッシュするもう一方によって必要とされなければ)」 しかしながら、応答のどんな使用のときにもPF旗をきれいにしなければなりません。
Mogul & Leach Standards Track [Page 25] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[25ページ]RFC2227
Note: the "PF" flag is so named because this feature is useful
only for caches that could issue a "prefetch" request before an
actual client request for the response. A proxy not implementing
prefetching need not implement the PF flag.
以下に注意してください。 この特徴が応答を求める実際のクライアント要求の前に「先取り」要求を出すことができたキャッシュだけの役に立つので、「pf」旗は非常に命名されます。 「前-とって」来ることを実行しないプロキシはPF旗を実行する必要はありません。
5.3.3 Equivalent algorithms are allowed
5.3.3 同等なアルゴリズムは許容されています。
Any other algorithm that exhibits the same external behavior (i.e., generates exactly the same requests from the proxy to the server) as the one in this section is explicitly allowed.
このセクションのものとして同じ外部の振舞いを示す(すなわち、まさに同じプロキシからサーバまでの要求を発生させます)いかなる他のアルゴリズムも明らかに許容されています。
Note: in most cases, TU will be equal to CU, and TR will be
equal to CR. The only two cases where they could differ are:
以下に注意してください。 多くの場合、TUはCUと等しくなるでしょう、そして、TRはCRと等しくなるでしょう。 それらが異なることができた唯一の2つのケースは以下の通りです。
1. The proxy issues a non-conditional request for the
resource using V, while TU and/or TR are non-zero, and
the server's response includes a new "max-uses" and/or
"max-reuses" directive (thus zeroing TU and/or TR, but
not CU and CR).
1. プロキシはVを使用するリソースのための非条件付き要求を発行します、TU、そして/または、TRが非ゼロです、そして、サーバの応答は新しい「最大用途」、そして/または、「最大再利用」指示(その結果、CUとCRではなく、TUのゼロを合わせる、そして/または、TR)を含んでいますが。
2. The proxy issues a conditional request reporting the
hit-counts (and thus zeroing CU and CR, but not TU or
TR), but the server's response does not include a new
"max-uses" and/or "max-reuses" directive.
2. プロキシはヒット数を報告する条件付き要求を発行しますが(その結果、TUかTRではなく、CUとCRのゼロを合わせます)、サーバの応答は新しい「最大用途」、そして/または、「最大再利用」指示を含んでいません。
To solve the first case, the proxy has several implementation
options
最初のケースを解決するために、プロキシには、いくつかの実現オプションがあります。
- Always store TU and TR separately from CU and CR.
- 別々にCUとCRからTUとTRをいつも格納してください。
- Create "shadow" copies of TU and TR when this situation
arises (analogous to "copy on write").
- この状況が起こったらTUとTRの「影」コピーを作成してください、(類似、「コピーする、書く、」、)
- Generate a HEAD-based usage report when the
non-conditional request is sent (or when the
"max-uses=0" is received), causing CU and CR to be
zeroed (analogous in some ways to a "memory barrier"
instruction).
- 非条件付き要求を送るときにはHEADベースの用法レポートを作ってください、(いつ、「受け取られた最大用途=0インチ)、CUとCRのゼロが合わせられることを(ある点では「メモリバリア」指示に類似の)引き起こすか、」
In the second case, the server implicitly has removed the
usage-limit(s) on the response (by setting MU and/or MR to
infinity), and so the fact that, say, TU is different from CU
is not significant.
2番目の場合では、サーバがそれとなく応答(MU、そして/または、MRを無限で設定するのによる)における用法限界を取り除いたので、たとえば、TUがCUと異なっているという事実は重要ではありません。
Note: It may also be possible to eliminate the PF flag by
sending extra HEAD-based usage-report requests, but we
recommend against this; it is better to allocate an extra bit
per entry than to transmit extra requests.
以下に注意してください。 また、しかし、送付の余分なHEADベースの用法レポートでPF旗を排除するのが、私たちがこれに対して推薦するよう要求するのも、可能であるかもしれません。 1エントリーあたり余分な1ビットを割り当てるのは余分な要求を伝えるより良いです。
Mogul & Leach Standards Track [Page 26] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[26ページ]RFC2227
5.4 Counting rules: interaction with Range requests
5.4 勘定規則: Range要求との相互作用
HTTP/1.1 allows a client to request sub-ranges of a resource. A client might end up issuing several requests with the net effect of receiving one copy of the resource. For uniformity of the results seen by origin servers, proxies need to observe a rule for counting these references, although it is not clear that one rule generates accurate results in every case.
HTTP/1.1で、クライアントはリソースのサブ範囲を要求できます。 クライアントは結局、リソースのコピー1部を受けるというネットの効果にいくつかの要求を出すかもしれません。 起源サーバによって見られた結果の一様性のために、プロキシは、これらの参照を数えるための規則を守る必要があります、1つの規則が正確な結果をあらゆる場合に発生させるのが、明確ではありませんが。
The rule established in this specification is that proxies count as a "use" or "reuse" only those Range requests that result in the return of byte #0 of the resource. The rationale for this rule is that in almost every case, an end-client will retrieve the beginning of any resource that it references at all, and that it will seldom retrieve any portion more than once. Therefore, this rule appears to meet the goal of a "best-efforts" approximation.
この仕様に確立された規則はプロキシが「使用」にみなすか、または0つのバイト#リソースの復帰をもたらすそれらのRange要求だけを「再利用する」ということです。 この規則のための原理はほとんどすべての場合、終わりクライアントがそれが全く参照をつけるどんなリソースの始まりも検索して、一度ほどめったにどんな部分も検索しないということです。 したがって、この規則は「最善の努力」近似の目標を達成するように見えます。
5.5 Implementation by non-caching proxies
5.5 非キャッシュしているプロキシによる実現
A non-caching proxy may participate in the metering subtree; this is strongly recommended.
非キャッシュしているプロキシは計量下位木に参加するかもしれません。 これは強く推薦されます。
A non-caching proxy (HTTP/1.1 or higher) that participates in the metering subtree SHOULD forward Meter headers on both requests and responses, with the appropriate Connection headers.
適切なConnectionヘッダーと共に要求と応答の両方で計量の下位木のSHOULDの前進のMeterヘッダーに参加する非キャッシュしているプロキシ(HTTP/1.1以上)。
If a non-caching proxy forwards Meter headers, it MUST comply with these restrictions:
非キャッシュしているプロキシがMeterヘッダーを進めるなら、これらの制限に従わなければなりません:
1. If the proxy forwards Meter headers in responses, such a
response MUST NOT be returned to any request except the
one that elicited it.
1. プロキシが応答でMeterヘッダーを進めるなら、それを引き出したもの以外のどんな要求にもそのような応答を返してはいけません。
2. Once a non-caching proxy starts forwarding Meter headers,
it should not arbitrarily stop forwarding them (or else
reports may be lost).
2. 非キャッシュしているプロキシがいったんMeterヘッダーを進め始めると、それによって、彼らは任意に進めることができないべきではありません(レポートは失われるかもしれません)。
A proxy that caches some responses and not others, for whatever reason, may choose to implement the Meter header as a caching proxy for the responses that it caches, and as a non-caching proxy for the responses that it does not cache, as long as its external behavior with respect to any particularly response is fully consistent with this specification.
いかなる理由による他のものではなく、いくつかの応答をキャッシュするAプロキシも、それがキャッシュする応答のためのキャッシュしているプロキシとしてそれが外部の振舞いと同じくらい長いどんなキャッシュもしない応答のための非キャッシュしているプロキシとしてMeterヘッダーを実行するのを選ぶかもしれない、いくらか、特に応答、この仕様と完全に一致しています。
Mogul & Leach Standards Track [Page 27] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[27ページ]RFC2227
5.6 Implementation by cooperating caches
5.6 協力関係を持っているキャッシュによる実現
Several HTTP cache implementations, most notably the Harvest/Squid cache [2], create cooperative arrangements between several caches. If such caches use a protocol other than HTTP to communicate between themselves, such as the Internet Cache Protocol (ICP) [12], and if they implement the Meter header, then they MUST act to ensure that their cooperation does not violate the intention of this specification.
いくつかのHTTPキャッシュ実現(最も著しくハーベスト/イカキャッシュ[2])がいくつかのキャッシュの間で協力的な措置を作成します。 そのようなキャッシュが自分たちの間で交信するのにHTTP以外のプロトコルを使用するなら、インターネットCacheプロトコル(ICP)[12]やそれらがMeterヘッダーを実行するかどうかなどような当時のそれらは、彼らの協力がこの仕様の意志に違反しないのを保証するために行動しなければなりません。
In particular, if one member of a group of cooperating caches agrees with a server to hit-meter a particular response, and then passes this response via a non-HTTP protocol to a second cache in the group, the caches MUST ensure that the server which requested the metering receives reports that appropriately account for any uses or resues made by the second cache. Similarly, if the first cache agreed to usage-limit the response, the total number of uses by the group of caches MUST be limited to the agreed-upon number.
協力キャッシュのグループの1人のメンバーが特定の応答をヒットで計量するのをサーバに同意して、次に、グループで2番目のキャッシュにこの応答を非HTTPプロトコルで通過するなら、特に、キャッシュは、計量を要求したサーバが適切にどんな用途も説明したレポートか2番目のキャッシュによって作られたresuesを受け取るのを確実にしなければなりません。 同様に、最初のキャッシュが、応答を用法で制限するのに同意したなら、キャッシュのグループによる用途の総数を同意している数に制限しなければなりません。
6 Examples
6つの例
6.1 Example of a complete set of exchanges
6.1 完全な交換に関する例
This example shows how the protocol is intended to be used most of the time: for hit-metering without usage-limiting. Entity bodies are omitted.
たいていプロトコルが使用されることをどう意図するかをこの例は示しています: 用法制限のないヒット計量のために。 実体本体は省略されます。
A client sends request to a proxy:
クライアントは要求をプロキシに送ります:
GET http://foo.com/bar.html HTTP/1.1
http://foo.com/bar.html HTTP/1.1を得てください。
The proxy forwards request to the origin server:
プロキシフォワードは起源サーバに以下を要求します。
GET /bar.html HTTP/1.1
Host: foo.com
Connection: Meter
bar.html HTTP/1.1が接待する/を手に入れてください: foo.com Connection: メーター
thus offering (implicitly) "will-report-and-limit".
その結果、(それとなく、)「レポートと限界を望んでください」を提供します。
The server responds to the proxy:
サーバはプロキシに反応します:
HTTP/1.1 200 OK
Date: Fri, 06 Dec 1996 18:44:29 GMT
Cache-control: max-age=3600
Connection: meter
Etag: "abcde"
HTTP/1.1 200OK日付: グリニッジ標準時1996年12月6日金曜日18時44分29秒のキャッシュ制御: 最大時代は3600Connectionと等しいです: Etagを計量してください: "abcde"
Mogul & Leach Standards Track [Page 28] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[28ページ]RFC2227
thus (implicitly) requiring "do-report" (but not requiring usage-limiting).
その結果、(それとなく)必要である、「レポートする、」 (用法で制限するのが必要ではありませんが。)
The proxy responds to the client:
プロキシはクライアントに応じます:
HTTP/1.1 200 OK
Date: Fri, 06 Dec 1996 18:44:29 GMT
Etag: "abcde"
Cache-control: max-age=3600, proxy-mustcheck
Age: 1
HTTP/1.1 200OK日付: グリニッジ標準時1996年12月6日金曜日18時44分29秒Etag: "abcde"キャッシュ制御: 最大時代は3600、プロキシ-mustcheck Ageと等しいです: 1
Since the proxy does not know if its client is an end-system, or a proxy that doesn't do metering, it adds the "proxy-mustcheck" directive.
プロキシが、クライアントがエンドシステム、または計量をしないプロキシであるかを知らないので、それは「プロキシ-mustcheck」指示を加えます。
Another client soon asks for the resource:
別のクライアントはすぐ、リソースを求めます:
GET http://foo.com/bar.html HTTP/1.1
http://foo.com/bar.html HTTP/1.1を得てください。
and the proxy sends the same response as it sent to the other client, except (perhaps) for the Age value.
そして、もう片方のクライアントに発信した(恐らく)Age値を除いて、プロキシは同じ応答を送ります。
After an hour has passed, a third client asks for the response:
1時間が経過した後に、3番目のクライアントは応答を求めます:
GET http://foo.com/bar.html HTTP/1.1
http://foo.com/bar.html HTTP/1.1を得てください。
But now the response's max-age has been exceeded, so the proxy revalidates the response with the origin server:
しかし、現在応答の最大時代が超えられているので、プロキシは起源サーバで応答を再有効にします:
GET /bar.html HTTP/1.1
If-None-Match: "abcde"
Host: foo.com
Connection: Meter
Meter: count=1/0
なにも合っていないなら、bar.html HTTP/1.1に/を手に入れてください: "abcde"ホスト: foo.com Connection: メーターを計量してください: =1/0を数えてください。
thus simultaneously fulfilling its duties to validate the response and to report the one "use" that wasn't forwarded.
したがって、同時に応答を有効にして、ものがそれを「使用する」と報告するために義務を果たすのは進められませんでした。
The origin server responds:
起源サーバは反応します:
HTTP/1.1 304 Not Modified
Date: Fri, 06 Dec 1996 19:44:29 GMT
Cache-control: max-age=3600
Etag: "abcde"
HTTP/1.1 304は日付:を変更しませんでした。 グリニッジ標準時1996年12月6日金曜日19時44分29秒のキャッシュ制御: 最大時代は3600Etagと等しいです: "abcde"
so the proxy can use the original response to reply to the new client; the proxy also zeros the use-count it associates with that response.
それで、プロキシは新しいクライアントに答えるのにオリジナルの応答を使用できます。 また、プロキシは、カウントを使用するのをそれがその応答に関連づけるゼロに合わせます。
Mogul & Leach Standards Track [Page 29] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[29ページ]RFC2227
Another client soon asks for the resource:
別のクライアントはすぐ、リソースを求めます:
GET http://foo.com/bar.html HTTP/1.1
http://foo.com/bar.html HTTP/1.1を得てください。
and the proxy sends the appropriate response.
そして、プロキシは適切な応答を送ります。
After another few hours, the proxy decides to remove the cache entry. When it does so, it sends to the origin server:
もう1数時間後に、プロキシは、キャッシュエントリーを取り除くと決めます。 そうすると、起源サーバに発信します:
HEAD /bar.html HTTP/1.1
If-None-Match: "abcde"
Host: foo.com
Connection: Meter
Meter: count=1/0
なにも合っていないなら、/bar.html HTTP/1.1に向かってください: "abcde"ホスト: foo.com Connection: メーターを計量してください: =1/0を数えてください。
reporting that one more use of the response was satisfied from the cache.
それを報告して、応答の、より多くの使用がキャッシュから満たされました。
6.2 Protecting against HTTP/1.0 proxies
6.2 HTTP/1.0のプロキシから守ること。
An origin server that does not want HTTP/1.0 caches to store the response at all, and is willing to have HTTP/1.0 end-system clients generate excess GETs (which will be forwarded by HTTP/1.0 proxies) could send this for its reply:
HTTP/1.0のキャッシュに全く応答を格納して欲しくなく、HTTP/1.0人のエンドシステムクライアントにGETs(HTTP/1.0のプロキシによって進められる)が回答のためにこれを送ることができた過剰を発生させても構わないと思っている起源サーバ:
HTTP/1.1 200 OK
Cache-control: max-age=3600
Connection: meter
Etag: "abcde"
Expires: Sun, 06 Nov 1994 08:49:37 GMT
HTTP/1.1 200はキャッシュ制御を承認します: 最大時代は3600Connectionと等しいです: Etagを計量してください: "abcde"は期限が切れます: グリニッジ標準時1994年11月6日日曜日8時49分37秒
HTTP/1.0 caches will see the ancient Expires header, but HTTP/1.1 caches will see the max-age directive and will ignore Expires.
HTTP/1.0のキャッシュが古代のExpiresヘッダーに会いますが、HTTP/1.1のキャッシュが、最大時代指示を見て、Expiresを無視するでしょう。
Note: although most major HTTP/1.0 proxy implementations observe
the Expires header, it is possible that some are in use that do
not. Use of the Expires header to prevent caching by HTTP/1.0
proxies might not be entirely reliable.
以下に注意してください。 ほとんどのHTTP/1.0の主要なプロキシ実現がExpiresヘッダーを観察しますが、或るものがそうしない使用であるのは、可能です。 HTTP/1.0のプロキシでキャッシュするのを防ぐExpiresヘッダーの使用は完全に信頼できないかもしれません。
6.3 More elaborate examples
6.3 より入念な例
Here is a request from a proxy that is willing to hit-meter but is not willing to usage-limit:
ここに、ヒットメーターに望んでいますが、望んでいないプロキシから用法限界までの要求があります:
GET /bar.html HTTP/1.1
Host: foo.com
Connection: Meter
Meter: wont-limit
bar.html HTTP/1.1が接待する/を手に入れてください: foo.com Connection: メーターを計量してください: 習慣の限界
Mogul & Leach Standards Track [Page 30] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[30ページ]RFC2227
Here is a response from an origin server that does not want hit counting, but does want "uses" limited to 3, and "reuses" limited to 6:
ここに、ヒットが重要である必要がない起源サーバからの応答があります、「用途」を3に制限して欲しく、「再利用」を6に制限して欲しいのを除いて:
HTTP/1.1 200 OK
Cache-control: max-age=3600
Connection: meter
Etag: "abcde"
Expires: Sun, 06 Nov 1994 08:49:37 GMT
Meter: max-uses=3, max-reuses=6, dont-report
HTTP/1.1 200はキャッシュ制御を承認します: 最大時代は3600Connectionと等しいです: Etagを計量してください: "abcde"は期限が切れます: グリニッジ標準時1994年11月6日日曜日8時49分37秒のメーター: 最大用途は3、最大再利用=6、dontレポートと等しいです。
Here is the same example with abbreviated Meter directive names:
ここに、簡略化されたMeter指示の名がある同じ例があります:
HTTP/1.1 200 OK
Cache-control: max-age=3600
Connection: meter
Etag: "abcde"
Expires: Sun, 06 Nov 1994 08:49:37 GMT
Meter:u=3,r=6,e
HTTP/1.1 200はキャッシュ制御を承認します: 最大時代は3600Connectionと等しいです: Etagを計量してください: "abcde"は期限が切れます: グリニッジ標準時1994年11月6日日曜日8時49分37秒のメーター: u=3、r=6、e
7 Interactions with content negotiation
満足している交渉との7回の相互作用
This section describes two aspects of the interaction between hit- metering and "content-negotiated" resources:
このセクションはヒット計量と「内容で交渉された」リソースとの相互作用の2つの局面について説明します:
1. treatment of responses carrying a Vary header (section
7.1).
1. Varyヘッダー(セクション7.1)を運ぶ応答の処理。
2. treatment of responses that use the proposed Transparent
Content Negotiation mechanism (section 7.2).
2. 提案されたTransparent Content Negotiationメカニズム(セクション7.2)を使用する応答の処理。
7.1 Treatment of responses carrying a Vary header
7.1 Varyヘッダーを運ぶ応答の処理
Separate counts should be kept for each combination of the headers named in the Vary header for the Request-URI (what [4] calls "the selecting request-headers"), even if they map to the same entity-tag. This rule has the effect of counting hits on each variant, if there are multiple variants of a page available.
別々のカウントがRequest-URI([4]が「選択している要求ヘッダー」と呼ぶこと)のためのVaryヘッダーの名前付のヘッダーの各組み合わせのために保たれるべきである、彼らは同じ実体タグに写像します。 この規則には、1ページの利用可能な複数の異形があれば各異形の上でヒットを数えるという効果があります。
Note: This interaction between Vary and the hit-counting
directives allows the origin server a lot of flexibility in
specifying how hits should be counted. In essence, the origin
server uses the Vary mechanism to divide the requests for a
resource into arbitrary categories, based on the request- headers.
(We will call these categories "request-patterns".) Since a proxy
keeps its hit-counts for each request-pattern, rather than for
each resource, the origin server can obtain separate statistics
for many aspects of an HTTP request.
以下に注意してください。 Varyとヒットが重要な指示とのこの相互作用はヒットがどう数えられるべきであるかを指定することにおける多くの柔軟性を起源サーバに許容します。 本質では、起源サーバはリソースに関する要求を任意のカテゴリに分割するのにVaryメカニズムを使用します、要求ヘッダーに基づいて。 (これらのカテゴリ「要求パターン」と、私たちは呼ぶつもりです。) プロキシが各リソースのためにというよりむしろそれぞれの要求パターンのためにヒット数を保つので、起源サーバはHTTP要求の多くの局面として別々の統計を得ることができます。
Mogul & Leach Standards Track [Page 31] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[31ページ]RFC2227
For example, if a page varied based on the value of the User-Agent header in the requests, then hit counts would be kept for each different flavor of browser. But it is in fact more general than that; because multiple header combinations can map to the same variant, it also enables the origin server to count the number of times (e.g.) the Swahili version of a page was requested, even though it is only available in English.
例えば、1ページが要求における、User-エージェントヘッダーの値に基づいて異なるなら、ヒット数はブラウザのそれぞれの異なった風味のために保たれるでしょうに。 しかし、事実上、それはそれより一般的です。 複数のヘッダー組み合わせが同じ異形に写像されることができるので、また、起源サーバが回数を数えるのを可能にします、(例えば、)1ページのスワヒリ族バージョンは要求されました、それが単に英語で利用可能ですが。
If a proxy does not support the Vary mechanism, then [4] says that it MUST NOT cache any response that carries a Vary header, and hence need not implement any aspect of this hit-counting or usage-limiting design for varying resources.
プロキシがVaryメカニズムをサポートしないなら、[4]はVaryヘッダーを運ぶ少しの応答もキャッシュしてはいけなくて、したがって、異なったリソースのためにこのヒットを数えているか、または用法を制限するデザインの少しの局面も実行する必要はないと言います。
Note: this also implies that if a proxy supports the Vary
mechanism but is not willing to maintain independent hit-counts
for each variant response in its cache, then it must follow at
least one of these rules:
以下に注意してください。 また、これは、プロキシがVaryメカニズムをサポートしますが、キャッシュにおけるそれぞれの異形応答のために独立しているヒット数を維持することを望んでいないなら少なくともこれらの規則の1つに続かなければならないのを含意します:
1. It must not use the Meter header in a request to offer
to hit-meter or usage-limit responses.
1. それはヒットメーターか用法限界応答に提供する要求でMeterヘッダーを使用してはいけません。
2. If it does offer to hit-meter or usage-limit responses,
and then receives a response that includes both a Vary
header and a Meter header with a directive that it
cannot satisfy, then the proxy must not cache the
response.
2. ヒットメーターへの申し出か用法限界応答をして、次に、それが満たすことができない指示でVaryヘッダーとMeterヘッダーの両方を含んでいる応答を受けるなら、プロキシは応答をキャッシュしてはいけません。
In other words, a proxy is allowed to partially implement the
Vary mechanism with respect to hit-metering, as long as this has
no externally visible effect on its ability to comply with the
Meter specification.
言い換えれば、プロキシはヒット計量に関してVaryメカニズムを部分的に実行できます、これがMeter仕様に従う性能にどんな外部的に目に見える影響も与えない限り。
This approach works for counting almost any aspect of the request stream, without embedding any specific list of countable aspects in the specification or proxy implementation.
このアプローチは要求ストリームのほとんどどんな局面も数えるのに効き目があります、仕様かプロキシ実現における数えられる局面のどんな特定のリストも埋め込まないで。
7.2 Interaction with Transparent Content Negotiation
7.2 わかりやすい満足している交渉との相互作用
[A description of the interaction between this design and the proposed Transparent Content Negotiation (TCN) design [6] will be made available in a later document.]
[このデザインと提案されたTransparent Content Negotiation(TCN)デザイン[6]との相互作用の記述を後のドキュメントで利用可能にするでしょう。]
8 A Note on Capturing Referrals
8 紹介を得ることに関する注
It is alleged that some advertisers want to pay content providers, not by the "hit", but by the "nibble" -- the number of people who actually click on the ad to get more information.
何人かの広告主が「ヒット」で支払いたいのではなく、「少量」でコンテンツプロバイダーに支払いたがっていると申し立てられます--詳しい情報を得るために実際に広告をクリックする人々の数。
Mogul & Leach Standards Track [Page 32] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[32ページ]RFC2227
Now, HTTP already has a mechanism for doing this: the "Referer" header. However, perhaps it ought to be disabled for privacy reasons -- according the HTTP/1.1 spec:
今、HTTPには、これをするためのメカニズムが既にあります: "Referer"ヘッダー。 しかしながら、恐らく、それはプライバシー理由でHTTP/1.1仕様無能にされるべきです:
"Because the source of the link may be private information or may
reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the
Referer field is sent."
「リンクの情報筋が個人情報であるかもしれないかそうでなければ、個人的な情報源を明らかにするかもしれないので、ユーザが、Referer野原が送られるかどうかを選択できることが強く勧められます。」
However, in the case of ads, the source of the link actually wants to let the referred-to page know where the reference came from.
しかしながら、広告の場合では、リンクの源は、実際に参照がどこから来たかを言及しているページに知らせたがっています。
This does not require the addition of any extra mechanism, but rather can use schemes that embed the referrer in the URI in a manner similar to this:
これは、どんな余分なメカニズムの添加も必要としませんが、むしろこれと同様の方法でリファラーをURIに埋め込む計画を使用できます:
http://www.blah.com/ad-reference?from=site1
http://www.blah.com/ad-reference?from=site1
Such a URI should point to a resource (perhaps a CGI script) which returns a 302 redirect to the real page
そのようなURIは実ページに再直接で302を返すリソース(恐らくCGIスクリプト)を示すべきです。
http://www.blah.com/ad-reference.html
http://www.blah.com/ad-reference.html
Proxies which do not cache 302s will cause one hit on the redirection page per use, but the real page will get cached. Proxies which do cache 302s and report hits on the cached 302s will behave optimally.
キャッシュ302sではなく、そうするプロキシが1使用あたりのリダイレクションページで打たれたものを引き起こすでしょうが、実ページはキャッシュされるでしょう。 キャッシュにおけるキャッシュ302sとレポートヒットに302をするプロキシが最適に振る舞うでしょう。
This approach has the advantage that it works whether or not the end-client has disabled the use of Referer. Combined with the rest of the hit-metering proposal in this design, this approach allows, for example, an advertiser to know how often a reference to an advertisement was made from a particular page.
このアプローチには、終わりクライアントがRefererの使用を無効にしたか否かに関係なく、それが扱う利点があります。 このデザインにおける、ヒットを計量する提案の残りに結合されています、このアプローチで、例えば、広告主は広告について特定のページからどれくらいの頻度で言及されたかを知ることができます。
9 Alternative proposals
9つの代案
There might be a number of other ways of gathering demographic and usage information; other mechanisms might respond to a different set of needs than this proposal does. This proposal certainly does not preclude the proposal or deployment of other such mechanisms, and many of them may be complementary to and compatible with the mechanism proposed here.
人口統計と用法情報を集める他の多くの方法があるかもしれません。 他のメカニズムはこの提案が応じるより異なった必要性に応じるかもしれません。 それらの多くが、ここで提案されるメカニズムと、確かに、この提案は他のそのようなメカニズムの提案か展開を排除しないで、補足的であって、互換性があるかもしれません。
There has been some speculation that statistical sampling methods might be used to gather reasonably accurate data. One such proposal is to manipulate cache expiration times so that selected resources are uncachable for carefully chosen periods, allowing servers to accurately count accesses during those periods. The hit-metering mechanism proposed here is entirely complementary to that approach,
統計調査方法が合理的に正確なデータを集めるのに使用されるかもしれないという何らかの思惑がありました。 選択されたリソースはそのような提案の1つがキャッシュ満了回数を操ることであるので、慎重に選ばれた期間、非キャッシュ可能です、サーバがそれらの期間、正確にアクセスを数えるのを許容して。 ここで提案されたヒットを計量するメカニズムはそのアプローチを完全に補足しています。
Mogul & Leach Standards Track [Page 33] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[33ページ]RFC2227
since it could be used to reduce the cost of gathering those counts. James Pitkow has written a paper comparing an earlier draft of this hit-metering proposal with sampling approaches [9].
以来、それらのカウントを集めるコストを削減するのにそれを使用できました。 ジェームスPitkowはこのヒットを計量する提案の以前の草稿を標本抽出アプローチ[9]にたとえる論文を書きました。
Phillip Hallam-Baker has proposed using a log-exchange protocol [5], by which a server could request a proxy's logs by making an HTTP request to the proxy. This proposal asserts that it is "believed to operate correctly in configurations involving multiple proxies", but it is not clear that this is true if an outer proxy is used as a (one-way) firewall. The proposal also leaves a number of open issues, such as how an origin server can be sure that all of the proxies in the request subtree actually support log-exchange. It is also not clear how this proposal couples a proxy's support of log- exchange to a server's permission to cache a response.
フィリップ・ハラム-ベイカーは、ログ交換プロトコル[5]を使用するよう提案しました。(サーバは、プロトコルからHTTP要求をプロキシに出すことによって、プロキシのログを要求できるでしょう)。 この提案は、それが「複数のプロキシにかかわる構成で正しく作動すると信じられています」が、外側のプロキシが(片道)のファイアウォールとして使用されるならこれが本当であることが、明確でないと断言します。 また、提案は多くの未解決の問題を残します、起源サーバが要求下位木におけるプロキシが皆、実際にログ交換を支持するのをどう確信している場合があるのなどように。 また、この提案がどのようにプロキシの応答をキャッシュするサーバの許可へのログ交換のサポートを結合するかも、明確ではありません。
For general background on the topic of Web measurement standards, see the discussion by Thomas P. Novak and Donna L. Hoffman [8]. Also see the "Privacy and Demographics Overview" page maintained by by the World Wide Web Consortium [10], which includes a pointer to some tentative proposals for gathering consumer demographics (not just counting references) [3].
ウェブ測定標準の話題に関する一般的なバックグラウンドに関しては、トーマス・P.ノヴァクとドナL.ホフマン[8]で議論を見てください。 また、「プライバシーと人口統計概観」ページがワールドワイドウェブコンソーシアム[10]によって維持されるのを見てください。(ワールドワイドウェブコンソーシアムは集会消費者人口統計(ただ数えていない参照)[3]のためのいくつかの試案にポインタを含んでいます)。
10 Security Considerations
10 セキュリティ問題
Which outbound clients should a server (proxy or origin) trust to report hit counts? A malicious proxy could easily report a large number of hits on some page, and thus perhaps cause a large payment to a content provider from an advertiser. To help avoid this possibility, a proxy may choose to only relay usage counts received from its outbound proxies to its inbound servers when the proxies have authenticated themselves using Proxy-Authorization and/or they are on a list of approved proxies.
サーバ(プロキシか起源)は、ヒット数を報告するとどの外国行きのクライアントを信じるべきですか? 悪意があるプロキシは、何らかのページで容易に多くのヒットを報告して、その結果、恐らく広告主からコンテンツプロバイダーに大きい支払いを引き起こす場合がありました。 この可能性を避けるのを助けるために、プロキシは、プロキシがいつProxy-認可を使用することで自分たちを認証したかを外国行きのプロキシから本国行きのサーバまで受けられたリレー用法カウントだけに選ぶかもしれません、そして、彼らは承認されたプロキシのリストにいます。
It is not possible to enforce usage limits if a proxy is willing to cheat (i.e., it offers to limit usage but then ignores a server's Meter directive).
プロキシが、不正行為しても構わないと思っているなら(すなわち、それは、用法を制限すると申し出ますが、サーバのMeter指示を無視します)、用法限界を実施するのは可能ではありません。
Regarding privacy: it appears that the design in this document does not reveal any more information about individual users than would already be revealed by implementation of the existing HTTP/1.1 support for "Cache-control: max-age=0, proxy-revalidate" or "Cache- control: s-maxage=0". It may, in fact, help to conceal certain aspects of the organizational structure on the outbound side of a proxy. In any case, the conflict between user requirements for anonymity and origin server requirements for demographic information cannot be resolved by purely technical means.
プライバシーに関して: それに見える、デザイン、このドキュメントが個々のユーザの既存のHTTP/1.1サポートの実現で既に明らかにされるだろうよりそれ以上の情報を明らかにしないコネは「以下をキャッシュで制御します」。 「=0、プロキシ-revalidateの最大に年をとってください」か「コントロールをキャッシュしてください」 s-maxage=0インチ。 事実上、それは、プロキシの外国行きの側面の上の組織体制のある一定の局面を隠すのを助けるかもしれません。 どのような場合でも、純粋に技術的な手段で匿名のためのユーザ要件と人口学的情報のための起源サーバ要件との闘争を解決できません。
Mogul & Leach Standards Track [Page 34] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[34ページ]RFC2227
11 Acknowledgments
11の承認
We gratefully acknowledge the constructive comments received from Anselm Baird-Smith, Ted Hardie, Koen Holtman (who suggested the technique described in section 8), Dave Kristol, Ari Luotonen, Patrick R. McManus, Ingrid Melve, and James Pitkow.
私たちは感謝してAnselmベアード-スミス、テッド・ハーディー、クンHoltman(セクション8で説明されたテクニックを示した)、デーヴ・クリストル、アリLuotonen、パトリック・R.マクマナス、イングリッドMelve、およびジェームスPitkowから受けられた建設的なコメントを承諾します。
12 References
12の参照箇所
1. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
1. ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
2. Anwat Chankhunthod, Peter B. Danzig, Chuck Neerdaels, Michael
F. Schwartz, and Kurt J. Worrell. A Hierarchical Internet Object
Cache. Proc. 1996 USENIX Technical Conf., San Diego, January,
1996, pp. 153-163.
2. Anwat Chankhunthod、ピーター・B.ダンツィグ、チャックNeerdaels、マイケル・F.シュワルツ、およびカート・J.ウォーレル。 階層的なインターネット物のキャッシュ。 Proc。 1996USENIX Technical Conf、サンディエゴ、1996年1月、ページ 153-163.
3. Daniel W. Connolly. Proposals for Gathering Consumer
Demographics.
http://www.w3.org/pub/WWW/Demographics/Proposals.html.
3. ダニエル・W.コノリー。 集会消費者人口統計 http://www.w3.org/pub/WWW/Demographics/Proposals.html のための提案。
4. Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1," RFC 2068,
January, 1997.
4. 1997年1月のフィールディングとR.とGettysとJ.と要人とJ.とニールセン、H.とT.バーナーズ・リー、「ハイパーテキストはHTTP/1.1にプロトコルを移し」RFC2068。
5. Phillip M. Hallam-Baker. Notification for Proxy Caches. W3C
Working Draft WD-proxy-960221, World Wide Web Consortium,
February, 1996. http://www.w3.org/pub/WWW/TR/WD-proxy.html.
5. フィリップ・M.ハラム-ベイカー。 プロキシキャッシュのための通知。 W3C概要版WDプロキシ960221、ワールドワイドウェブコンソーシアム、2月、1996 http://www.w3.org/pub/WWW/TR/WD-proxy.html 。
6. Holtman, K., and A. Mutz, "Transparent Content Negotiation in
HTTP", Work in Progress.
6. K.、およびA.Mutz、「HTTPにおけるわかりやすい満足している交渉」というHoltmanは進行中で働いています。
7. Mogul, J., "Forcing HTTP/1.1 proxies to revalidate responses",
Work in Progress.
7. J. ムガール人、Progressの「HTTP/1.1のプロキシをrevalidate応答に強制すること」でのWork。
8. Thomas P. Novak and Donna L. Hoffman. New Metrics for New Media:
Toward the Development of Web Measurement Standards. This is a
draft paper, currently available at http://
www2000.ogsm.vanderbilt.edu/novak/web.standards/webstand.html.
Cited by permission of the author; do not quote or cite without
permission.
8. トーマス・P.ノヴァクとドナ・L.ホフマン。 ニューメディアのための新しい測定基準: ウェブ測定標準の開発に向かって。 これは現在http://www2000.ogsm.vanderbilt.edu/novak/web.standards/webstand.htmlで利用可能な草稿紙です。 作者の許可で、引用されます。 許可なしで引用しないでください、または引用しないでください。
9. James Pitkow. In search of reliable usage data on the WWW.
Proc. Sixth International World Wide Web Conference, Santa Clara,
CA, April, 1997.
9. ジェームスPitkow。 WWW. Procに関する信頼できる用法データを求めて。 サンタクララ(カリフォルニア)1997年4月の第6国際WWWコンファレンス。
Mogul & Leach Standards Track [Page 35] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[35ページ]RFC2227
10. Joseph Reagle, Rohit Khare, Dan Connolly, and Tim Berners-Lee.
Privacy and Demographics Overview.
http://www.w3.org/pub/WWW/Demographics/.
10. ジョゼフReagle、Rohit Khare、ダン・コノリー、およびティム・バーナーズ・リー。 プライバシーと人口統計概観 http://www.w3.org/pub/WWW/Demographics/ 。
11. Linda Tauscher and Saul Greenberg. Revisitation Patterns in
World Wide Web Navigation. Research Report 96/587/07, Department
of Computer Science, University of Calgary, March, 1996.
http://www.cpsc.ucalgary.ca/projects/grouplab/
papers/96WebReuse/TechReport96.html.
11. リンダ・トーシャーとソール・グリーンバーグ。 再訪はWWWナビゲーションで型に基づいて作ります。 レポート96/587/07、コンピュータサイエンス学部、カルガリー大学、3月、1996 http://www.cpsc.ucalgary.ca/projects/grouplab/ 書類/96WebReuse/TechReport96.htmlについて研究してください。
12. Wessels, D., and K. Claffy "Internet Cache Protocol (ICP),
version 2", RFC 2186, September 1997.
12. ウェセルズ、D.、およびK.Claffy、「インターネットCacheプロトコル(ICP)、バージョン2インチ、RFC2186、1997年9月。」
13 Authors' Addresses
13人の作者のアドレス
Jeffrey C. Mogul Western Research Laboratory Digital Equipment Corporation 250 University Avenue Palo Alto, California, 94305, U.S.A.
Avenueパロアルト、ジェフリー・C.の要人の西洋の研究所DEC250大学カリフォルニア 94305、米国
EMail: mogul@wrl.dec.com Phone: 1 415 617 3304 (email preferred)
メール: mogul@wrl.dec.com 電話: 1 415 617 3304 (好まれたメール)
Paul J. Leach Microsoft 1 Microsoft Way Redmond, Washington, 98052, U.S.A.
ポールJ.リーチマイクロソフト1マイクロソフト道、レッドモンド、ワシントン、98052、米国
EMail: paulle@microsoft.com
メール: paulle@microsoft.com
Mogul & Leach Standards Track [Page 36] RFC 2227 Hit-Metering and Usage-Limiting October 1997
ヒットを計量していて1997年10月に用法を制限するムガール人とリーチ標準化過程[36ページ]RFC2227
14 Full Copyright Statement
14 完全な著作権宣言文
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 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 implmentation may be prepared, copied, published andand 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.
それに関するこのドキュメントと翻訳をコピーして、他のものに提供するかもしれません、そして、そうでなければ、implmentationを批評するか、それについて説明するか、または補助する派生している作品は全体か一部分配された、準備されて、コピーされて、発行されたandandであるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Mogul & Leach Standards Track [Page 37]
ムガール人とリーチ標準化過程[37ページ]
一覧
スポンサーリンク
