[要約] RFC 2227は、HTTPのシンプルなヒットメータリングと使用制限に関する仕様です。このRFCの目的は、ウェブサーバーのトラフィックを制御し、使用制限を実装するための方法を提供することです。
Network Working Group J. Mogul
Request for Comments: 2227 DECWRL
Category: Standards Track P. Leach
Microsoft
October 1997
Simple Hit-Metering and Usage-Limiting for HTTP
HTTPの単純なヒットメータリングと使用制限
Status of this 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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
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.1目標、非目標、および制限3 1.2設計の概要4 1.3用語5 2概要5 2.1考察7 3設計の概念8 3.1「メータリングサブツリー」の実装8 3.2メータヘッダーのフォーマット10 3.3ヒットメータリングと使用制限の交渉10 3.4使用レポートの送信14 3.5使用レポートを送信するタイミング15 3.6使用制限の細分化16
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分析17 4.1ユーザーをカウントするための近似精度18 4.2「ネットワークコンピュータ」はどうですか？ 19 4.3クリティカルパス遅延の分析19 5仕様20 5.1メーターヘッダーとディレクティブの仕様20 5.2メーターディレクティブの略語23 5.3カウントルール24 5.3.1ヒットメーターのカウントルール24 5.3.2使用制限のカウントルール25 5.3 .3同等のアルゴリズムが許可されます26 5.4カウントルール：範囲要求との相互作用27 5.5非キャッシュプロキシによる実装27 5.6キャッシュの連携による実装28 6例28 6.1完全な交換の例28 6.2 HTTP / 1.0プロキシからの保護30 6.3より複雑な例30 7コンテンツネゴシエーションとの相互作用31 7.1 Varyヘッダーを含む応答の処理31 7.2透過的コンテンツネゴシエーションとの相互作用32 8リフェラルのキャプチャに関する注意32 9代替提案33 10セキュリティに関する考慮事項34 11謝辞35 12参考文献35 13著者'アドレス36 14完全な著作権表示37
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 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回は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]。この証拠の一部は、プロキシトレースの調査から推測されます。一部は、Webサーバーのオペレーターの意図の明示的なステートメントに基づいています。この方法で収集された情報は、収集した人々にとって実際に役立つ場合とそうでない場合があります。実際、彼らはそれを収集したい、またはすでに収集しているのです。
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.
- プロキシ経由で行われたリクエストに関する広範な情報を効率的に取得するという問題全体を解決します。
- 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.
これらの潜在的な制限は、実際には問題にならない場合があります。
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.)
この設計の目標は、リソースのユーザー数をカウントする目的でのみ、オリジンサーバーが「キャッシュ無効化」手法を使用する必要をなくすことです。 （キャッシュ無効化には、即時の有効期限の設定、各応答での「キャッシュ制御：プライベート」の送信などの手法が含まれます。）
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に追加されます。ヘッダーは常に「接続」ヘッダーによって保護されるため、常にホップバイホップです。このメカニズムにより、起点サーバーをルートとする接続されたプロキシのサブツリーである「メータリングサブツリー」を構築できます。リソースのメータリングサブツリーに明示的に参加するように自発的に参加するプロキシのみがヒットメータリングに参加しますが、自発的に実行するプロキシは正確なカウントを提供するために最善を尽くす必要があります。ヒットメータリングされた応答がメータリングサブツリーの外に転送されると、転送プロキシは「Cache-control：s-maxage = 0」を追加します。これにより、他のプロキシ（メータリングサブツリーの外）はすべての要求を強制的にサーバーに転送します。計測サブツリー。
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」キャッシュ制御ディレクティブを定義していません。 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ヘッダーは、キャッシュ制御ヘッダーがディレクティブを運ぶのと同様に、0個以上のディレクティブを運びます。プロキシは、特定の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.
完全な仕様には、応答の「使用」（たとえば、非条件付きGET）および「再利用」（条件付きGET）をカウントするための完全なルールが含まれています。これらのルールは、システムまたはネットワークに障害が発生した場合を除いて、すべてのケースで結果が完全に一貫していることを保証します。
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」、「MUST NOT」、「REQUIRED」、「SHOULD」、SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC 2119 [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.
- 使用制限：オリジンサーバーで再検証する前に、キャッシュされた応答がプロキシキャッシュまたはプロキシキャッシュの階層によって使用される回数をオリジンサーバーが制御できるようにします。
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.
ヒットメータリングと使用制限の主な目的は、オリジンサーバーが「Cache-control：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.
この設計では、HTTP要求メッセージとHTTP応答メッセージの両方で使用される1つの新しい「メーター」ヘッダーが導入されています。 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（変更なし）応答。このキャッシュエントリによって満たされます。
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ディレクティブとレポートは相互に作用し、人口統計データの収集においてプロキシキャッシュとサーバーが連携できるようにします。目標は、保証された正確な数ではなく、実際の使用および/または再利用の数のベストエフォートの概算です。
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の実装に対して非常に小さな変更になる可能性があります。一部の実装では、まったく変更を必要としない場合があります。
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ごとに1回、条件付きGETごとに1回インクリメントして、エントリのコピーを送信してクライアントの無効を更新します。キャッシュされたコピー。 304（Not Modified）となる条件付きGETは、新しいユーザーがページを表示するのではなく、以前にそれを表示したことのあるユーザーによるリピートビューを意味するため、use-countには含まれません。ただし、304の応答が再利用カウントにカウントされます。 HEADはカウントされません。応答にはエンティティ本体が含まれないためです。
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の結果として自動的にカウントされるためです。その後の条件付きGETでは、新しいユーザーにページが表示されません。
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.
ここで指定するメカニズムはGETをカウントします。他の方法では、ユーザーがページを読み取れないか、キャッシュされないか、「ライトスルー」されるため、配信元サーバーで直接カウントできます。 （将来、「キャッシュ可能なPOST」が発生し、POSTリクエストのエンティティ本体がキャッシュされた応答を選択するために使用された場合、そのようなPOSTはGETと同じように扱われる必要があります。）将来的に定義される可能性のある新しい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.
パスに沿って複数のキャッシュがある場合、プロキシキャッシュは、別のキャッシュからのリクエストで使用数または再利用数を受け取ると、明らかな合計を行います。
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.
プロトコルリビジョンを必要とせずにヒットメータリングと使用制限の導入を可能にし、正確なカウントのかなり近い概算を保証するために、メータリングと使用制限のネゴシエーションはエンドバイホップではなくホップバイホップで行われます最後まで。特定の応答を受信、保存、転送するプロキシの「ツリー」を考えると、この設計の目的は、オリジンサーバーをルートとする一部の（おそらくnull）「メータリングサブツリー」内で、すべてのプロキシがヒットを使用していることです。オリジンサーバーから要求されたメータリングや使用制限。
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.
このサブツリーのリーフにあるプロキシは、「Cache-control：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にあります。次の説明では、わかりやすくするために非公式なアプローチを使用しています。
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:
"メータリングサブツリー"アプローチは、新しい "メーター"ヘッダーをすべての要求または応答で常に接続ヘッダーによって保護する必要があるヘッダーとして定義することにより、シンプルで簡単な方法で実装されます。つまり、MeterヘッダーがHTTPメッセージに存在する場合、そのメッセージは次のようになります。
1. MUST contain "Connection: meter", and MUST be handled according to the HTTP/1.1 specification of the Connection header.
1. 「接続：メーター」を含む必要があり、接続ヘッダーの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未満のクライアントからの要求に応答して送信してはなりません（MUST NOT）。
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はこの動作を特に必要としませんが、暗黙のようです。さもなければ、保護されたオプションが「さらなる接続を介してプロキシによって伝達されてはならない」という規定のプロパティ（セクション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.
プロキシがヒットメータリングされた応答または使用制限された応答をメータリングサブツリーにないクライアント（プロキシまたはエンドクライアント）に転送する場合、メータヘッダーを省略し、「Cache-control：s-maxage = 0 "応答へ。
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ヘッダーは、0個以上のディレクティブを運ぶために使用されます。 HTTPメッセージでは複数のMeterヘッダーが発生する可能性がありますが、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
may be expressed as
次のように表すことができます
Meter: max-uses=3, max-reuses=10, do-report
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).
すべてのリクエストにプロキシキャッシュをバイパスさせるだけで、リソースのヒットカウントを収集するオリジンサーバーは、「Cache-control：s-maxage = 0」でリソースのリクエストに応答します。 （HTTP / 1.0プロキシが応答を不適切にキャッシュしないようにするオリジンサーバーは、「Expires：<now>」を送信してこのようなキャッシュを防止し、「Cache-control：max-age = 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ヘッダーの目的は、メータリングサブツリー内で「Cache-control：s-maxage = 0」が不要になるようにすることです。したがって、どのプロキシも、ヒットメータリングの使用やネクストホップサーバーとの使用制限のネゴシエーションを行う場合があります。このサーバーがオリジンサーバーである場合、または（オリジンサーバーをルートとする）メータリングサブツリーの一部である場合、ネゴシエーションを完了し、メータリングサブツリーを拡張して新しいプロキシを含めることができます。
To start the negotiation, a proxy sends its request with one of the following Meter directives:
ネゴシエーションを開始するには、プロキシは次のいずれかのMeterディレクティブを使用してリクエストを送信します。
will-report-and-limit indicates that the proxy is willing and able to return usage reports and will obey any usage-limits.
will-report-and-limitは、プロキシが使用状況レポートを返す意志があり、それを返すことができることを示し、すべての使用制限に従います。
wont-report indicates that the proxy will obey usage-limits but will not send usage reports.
wont-reportは、プロキシが使用制限に従いますが、使用レポートを送信しないことを示します。
wont-limit indicates that the proxy will not obey usage-limits but will send usage reports.
wont-limitは、プロキシが使用制限に従わないが、使用状況レポートを送信することを示します。
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
「Meter：will-report-and-limit」と同等です。したがって、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
接続：メーターメーター：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.
do-reportは、プロキシが使用状況レポートをサーバーに送信する必要があることを指定します。
dont-report specifies that the proxy SHOULD NOT send usage reports to the server.
dont-reportは、プロキシが使用状況レポートをサーバーに送信してはならない（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".
timeout = NNNは、ヒット数の報告のために、この応答が発信されたときからNNN分の計測タイムアウトを設定します。タイムアウトの期限が切れたときに、プロキシがこの応答のゼロ以外のヒットカウントを持っている場合、プロキシはその時刻以前にサーバーにレポートを送信する必要があります。 「do-report」を意味します。
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.
定義により、応答内の空のMeterヘッダー、または「dont-report」を含まないMeterヘッダーは、「Meter：do-report」を意味します。これにより、一般的なケースがより効率的になります。
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 * T（最悪の場合）までの期間のアクティビティを反映します（Nは最大値）。計測サブツリーの深さ。
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.
max-uses = NNNは、次のサブツリー内のすべてのプロキシをまとめて、要求のエンドクライアントへの即時転送をカウントせずに、応答のNNN「使用」の上限を設定します。
max-reuses=NNN sets an upper limit of NNN "reuses" of the response for all proxies in the following subtree taken together.
max-reuses = 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.)
プロキシがキャッシュエントリの「使用」または「再利用」の割り当てを使い果たした場合、応答で返す前に、キャッシュエントリを（条件付き要求を使用して）再検証する必要があります。 （プロキシは、要求があり、それを送信する時がきた場合、この再検証メッセージを使用して使用状況レポートを送信する必要があります。セクション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.
max-usesディレクティブによって設定された「使用」の制限には、サーバーへのプロキシの要求の原因となったエンドクライアント要求を満たすための応答の使用は含まれないことに注意してください。このカウントルールは、キャッシュによって開始されるプリフェッチの概念をサポートします。キャッシュは、プリフェッチ要求を発行し、max-uses = 0応答を受信し、その応答を格納し、クライアントが実際の要求を行ったときにその応答を（再検証なしで）返します。リソース用。ただし、そのような各応答はこの方法で最大1回使用される可能性があるため、元のサーバーは実際の使用回数を正確に制御します。
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ヘッダーを送信してはならない（MUST NOT）。 Meter応答ディレクティブを受け取ったプロキシは、プロキシに対して、ボランティアではないことを行うように要求し、そのディレクティブを無視する必要があります。
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ヘッダーに従わないことを選択した場合、応答に「Cache-control：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ヘッダーを暗黙的なリクエストとして解釈して、「Cache-control：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リクエストヘッダーが受信されず、ネクストホップサーバーからの応答が何らかの形式のメータリングまたは制限を要求する場合、プロキシは「Cache-control：s-maxageその要求に対して転送するすべての応答に対して= 0。 （プロキシは、Expiresヘッダーまたはmax-ageキャッシュ制御ディレクティブを追加または変更しないでください。）
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のキャッシュされた応答にメーターディレクティブが含まれていない場合、プロキシ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が以前にオリジンサーバーに「Meter：wont-limit」（will-reportを暗示する）を通知し、キャッシュされた応答に「Meter：do-report」が含まれ、プロキシBのリクエストに「Meter：wont-report」が含まれている場合、その後、プロキシBのオファーは、オリジンサーバーに対するプロキシAの義務と一致しません。したがって、この場合、プロキシAは、キャッシュされた応答をプロキシBに返すときに「Cache-control：s-maxage = 0」を追加する必要があり、この応答に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.
wont-askは、プロキシーがこのサーバーにMeterディレクティブを送信してはならないことを推奨します。
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".)
プロキシはこの事実を最大24時間記憶する必要があります（SHOULD）。これにより、Meterヘッダーの使用やサポートを望まないサーバーにとって、実質的にすべての不要なオーバーヘッドが回避されます。 （このディレクティブは、「dont-report」も意味します。）
To transmit a usage report, a proxy sends the following Meter header in a request on the appropriate resource:
使用状況レポートを送信するために、プロキシは適切なリソースのリクエストで次のMeterヘッダーを送信します。
Meter: count=NNN/MMM
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ディレクティブのないリクエストでの「count」ディレクティブの送信は、一般的なケースを最適化するために、「will-report-and-limit」ディレクティブの暗黙的な送信としても定義されます。 （使用制限を守ろうとしないプロキシは、そのレポートに対して「Meter：count = NNN / MMM、wont-limit」を送信します。）
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.
これは有用な情報を伝えないため、プロキシは「メーター：count = 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.
条件付きヘッダー（例：If-Modified-SinceまたはIf-None-Match）の情報はオリジンサーバーが要求するため、使用状況レポートは常に条件付きリクエスト（GETやHEADなど）の一部として送信する必要があります。カウントされているリソースのインスタンスを確認します。使用状況レポートをメータリングサブツリーに転送するプロキシは、条件付きヘッダーの内容を変更してはなりません。変更しないと、正しくカウントされません。
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-None-MatchまたはIf-Matchヘッダーに複数のエンティティタグを含む転送要求の一部として送信してはなりません（MUST NOT）。
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.
注：ヒットメータリング（レポートの使用）を実行する意欲を提供するプロキシは、使用と再利用の両方をカウントする必要があります。一方の報告について交渉することはできませんが、もう一方については交渉できません。
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. クライアントの1つに代わってリソースインスタンスで条件付きGETを転送するとき（GETが最大で1つのエンティティタグで条件付きの場合）。
2. When it forwards a conditional HEAD on the resource instance on behalf of one of its clients.
2. クライアントの1つに代わってリソースインスタンスで条件付きHEADを転送するとき。
3. When it must generate a conditional GET to satisfy a client request because the max-uses limit has been exceeded.
3. max-uses制限を超えたため、クライアント要求を満たすために条件付き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).
- プロキシはリソースごとに複数の応答を保存することができず、クライアントに代わって転送された要求が新しい応答（異なるエンティティタグまたは最終変更時刻を持つ応答）の受信をもたらしました。
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リクエストの一部としてレポートを送信する必要があります。
- 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リクエストが失敗した場合に再試行する必要はありません（これはベストエフォート型の設計です）。ただし、精度を向上させるために、リソースの制約に従い、プロキシは失敗したHEADリクエストを再試行する必要があります（SHOULD）。
- 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.
「count」ディレクティブも運ぶ到着リクエストが原因で使用カウントが送信された場合、プロキシは自身の（場合によってはゼロ）使用カウントと再利用カウントを到着カウントと組み合わせてから、リクエストの転送を試行する必要があります。
However, the proxy is not required to forward an arriving request with a "count" directive, provided that:
ただし、次の条件が満たされていれば、プロキシは「count」ディレクティブで到着リクエストを転送する必要はありません。
- 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.)
到着するリクエストが「count」ディレクティブを運び、プロキシがリソースのキャッシュエントリをもう持たない場合、プロキシは「count」ディレクティブを転送する必要があります。 （これは、いずれにしても、適切なキャッシュエントリのないプロキシが受信する有効なリクエストに対して通常行うことです。）
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があり、それぞれがオリジンサーバーSに到達する方法としてプロキシP3を使用している状況を考えてみます。SがP3に次の応答を送信するとします。
Meter: max-uses=10
メーター：max-uses = 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.
プロキシはその応答を使用して、現在要求しているエンドクライアントを満たします。この例のmax-usesディレクティブを使用すると、P1、P2、およびP3を組み合わせて、リソースの10の追加のエンドクライアント使用（無条件GET）を満たすことができます。
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はそれ自体のすべてのmax-use割り当てを保持できます。その場合、応答をP1またはP2、あるいはその両方に転送します。
Meter: max-uses=0
メーター：max-uses = 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
メーター：max-uses = 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.
max-uses値を選択するこの自由度は、配信元サーバーにも適用されることに注意してください。オリジンサーバーがすべてのキャッシュに同じmax-uses値を送信する必要はありません。たとえば、最初にキャッシュから聞いたときに「max-uses = 2」を送信し、次にそのキャッシュから「use-count」を取得するたびに値を2倍にする（最大制限まで） 。キャッシュがmax-use割り当てを使い切る速度が速いほど、キャッシュエントリを削除する前に使用カウント値を報告する可能性が高くなるという考えです。また、使用回数が多く頻繁であることは、キャッシングを許可することによる、対応する高効率の利点を意味します。
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. ネットワークコンピュータなどのブラウザにキャッシュが含まれていないユーザーをカウントする問題（セクション4.2）。
3. delays imposed on "critical paths" for HTTP operations (section 4.3).
3. HTTP操作の「クリティカルパス」に課される遅延（セクション4.3）。
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.
ほとんどすべてのWebユーザーがローカルキャッシュを維持するクライアントソフトウェアを使用しており、最新のローカルキャッシュテクノロジは非常に効果的です。 （セクション4.2では、エンドクライアントキャッシュが小さいか存在しない場合について説明します。）したがって、効果的で永続的なエンドクライアントキャッシュを想定して、エンティティを取得する個々のユーザーは、1つずつGETリクエストを実行し、結果として200または203になります。応答、またはエンティティの最初のバイトを含む206応答。プロキシキャッシュがそのような取得の正確な使用数を維持および報告する場合、報告された使用数は、エンティティを取得した個別のユーザーの数とほぼ同じになります。
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]。この結果は普遍的には適用されない可能性がありますが、ほとんどすべての再利用がエンドクライアントキャッシュでヒットし、プロキシキャッシュによる無条件GETと見なされないことを意味します。
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
個別のユーザーをカウントするための既存の（HTTP / 1.0）「キャッシュ無効化」メカニズムは、プロキシの背後にあるユーザー数を確実に過大評価します。これは、ユーザーの最初のリクエストと条件付きである可能性のある後続の繰り返しリクエストを区別する信頼できる方法がないためです。 GETは、キャッシュ無効化が採用されていませんでした。の
"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.1の「キャッシュ制御：s-maxage = 0」機能では、HTTP / 1.0プロキシキャッシュが介入しない限り、使用回数と再利用回数を分離できます。
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].
特定のリソースセットのヒットメータリングの結果の妥当性に疑問がある場合、サーバーはキャッシュバースト手法を短期間使用して、ヒットメータリングの結果を検証するためのベースラインを確立できます。この問題に対するさまざまなアプローチは、James Pitkowによる論文[9]で説明されています。
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の分析では、「ほぼすべてのWebユーザー」がクライアントキャッシュを持っていると想定しています。ただし、ネットワークコンピューター（NC）モデルが一般的になると、この仮定は誤りになる可能性があります。ほとんどの提案されたNCにはディスクストレージがなく、RAMが比較的少ないです。多くの携帯情報端末（PDA）は、ネットワークにアクセスできる場合があり、同様の制約があります。このようなクライアントシステムは、HTTP応答のキャッシングをほとんどまたはまったく行わない場合があります。つまり、1人のユーザーが、プロキシキャッシュから同じ応答を返す無条件GETを多数生成する可能性があります。
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で利用可能なものより劣らない概算を提供することに注意してください。プロキシがオリジンサーバーに返すカウントは、リクエストの数を正確に表します。サーバーが単に「Cache-control：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アドレスを記録し、応答ごとにクライアントアドレスごとに1つのGETのみをカウントする場合があります。これは完璧ではありません。たとえば、NCと他の特定の種類のホストを区別できません。プロキシはまた、条件付きGETを送信しないクライアントのみがこのように扱われるべきであるというヒューリスティックを使用する場合がありますが、NCが条件付きGETを送信しないことはまったく確実ではありません。
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.
この問題の解決策は、NCの実際の動作に基づくヒューリスティック（またはおそらくキャッシュレスクライアントの明確な検出を可能にする新しいHTTPプロトコル機能）を必要とするため、解決策を指定するのは時期尚早のようです。
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 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.
レイテンシが問題となっているシステム（Webなど）では、通常、相互に依存するステップのツリーが存在し、すべての先行バージョンが完了するまで最終結果を達成することができません。ツリー構造は並列処理を許可しているため、プロセス全体のレイテンシを検出するために各ステップのタイミングを合計する必要はありません。ただし、この依存関係ツリーを経由する単一のパスは並列化できません。そのようなパスの中で最長のパスが、全体の長さ（秒単位）によって待ち時間を決定します。これは「クリティカルパス」です。他のパスをどれだけ短くしても、最終結果の全体的なレイテンシを変更することはできないためです。
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.
Webリクエストの最終結果をブラウザでページをレンダリングするか、またはリクエストの結果に基づいて処理する場合、明らかに一部のネットワークラウンドトリップ（たとえば、接続がまだ存在しない場合はTCP SYNパケットの交換） ）はクリティカルパス上にあります。このヒットメータリング設計では、キャッシュエントリが削除されたときにゼロ以外のカウントを報告するための往復が追加されますが、設計上、これらはクリティカルパスから外れています。これらは他の操作と並行して実行され、必要なのは「ベストエフォート」。プロキシは、成功または失敗した他の操作をシリアル化する必要はありません。
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仕様
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 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).
Meterヘッダーは常にConnectionヘッダーで保護する必要があります。 Meterヘッダーを実装しないプロキシは、それを別のシステムにパススルーしてはなりません（非キャッシュプロキシがこの仕様に準拠する方法については、セクション5.5を参照してください）。 HTTP / 1.1より前のバージョンのメッセージでMeterヘッダーが受信された場合は、それを無視する必要があります（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.
HTTP / 1.1より前のバージョンの応答を受け取ったため、Meterヘッダーを実装していないサーバー（または別のプロキシ）からのプロキシは、帯域幅を浪費するだけなので、Meter要求ディレクティブをそのサーバーに送信しないでください。 。この推奨事項は、プロキシが現在サーバーからの応答をヒットメータリングまたは使用制限している場合には適用されません。プロキシがこのようなサーバーからHTTP / 1.1以上の応答を受信した場合、メーターディレクティブの抑制を停止する必要があります。
All proxies sending the Meter header MUST adhere to the "metering subtree" design described in section 3.
Meterヘッダーを送信するすべてのプロキシは、セクション3で説明されている「メータリングサブツリー」の設計に準拠する必要があります。
Meter = "Meter" ":" 0#meter-directive
meter-directive = meter-request-directive | meter-response-directive | meter-report-directive
meter-directive = meter-request-directive | meter-response-directive | meter-report-directive
meter-request-directive = "will-report-and-limit" | "wont-report" | "wont-limit"
meter-request-directive = "will-report-and-limit" | 「不報告」| 「制限なし」
meter-report-directive =
| "count" "=" 1*DIGIT "/" 1*DIGIT
meter-response-directive =
"max-uses" "=" 1*DIGIT
| "max-reuses" "=" 1*DIGIT
| "do-report"
| "dont-report"
| "timeout" "=" 1*DIGIT
| "wont-ask"
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.
meter-request-directiveまたはmeter-report-directiveは、HTTPリクエストメッセージにのみ表示されます。 meter-response-directiveは、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ヘッダーは、「Meter：will-report-and-limit」を意味します。応答の空のMeterヘッダー、または「dont-report」または「wont-ask」ディレクティブのない1つ以上のMeterヘッダーを含むその他の応答は、「Meter：do-report」を意味します。
The meaning of the meter-request-directives are as follows:
meter-request-directivesの意味は次のとおりです。
will-report-and-limit indicates that the proxy is willing and able to return usage reports and will obey any usage-limits.
will-report-and-limitは、プロキシが使用状況レポートを返す意志があり、それを返すことができることを示し、すべての使用制限に従います。
wont-report indicates that the proxy will obey usage-limits but will not send usage reports.
wont-reportは、プロキシが使用制限に従いますが、使用レポートを送信しないことを示します。
wont-limit indicates that the proxy will not obey usage-limits but will send usage reports.
wont-limitは、プロキシが使用制限に従わないが、使用状況レポートを送信することを示します。
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:
meter-report-directivesの意味は次のとおりです。
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.
count "=" 1 * DIGIT "/" 1 * DIGIT両方の数字列が10進整数をエンコードします。最初の整数は、最後のレポート以降のキャッシュエントリの使用回数を示します。 2番目の整数は、エントリの再利用回数を示します。
Section 5.3 specifies the counting rules.
セクション5.3では、カウントルールを指定します。
The meaning of the meter-response-directives are as follows:
meter-response-directivesの意味は次のとおりです。
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.
max-uses "=" 1 * DIGITは、次のサブツリー内のすべてのプロキシをまとめて、応答の "uses"の数に上限を設定し、要求側のエンドクライアントへの即時転送をカウントしません。
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.
max-reuses "=" 1 * DIGITは、次のサブツリー内のすべてのプロキシをまとめて、応答の「再利用」の数に上限を設定します。
do-report specifies that the proxy MUST send usage reports to the server.
do-reportは、プロキシが使用状況レポートをサーバーに送信する必要があることを指定します。
dont-report specifies that the proxy SHOULD NOT send usage reports to the server.
dont-reportは、プロキシが使用状況レポートをサーバーに送信してはならない（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 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".
timeout "=" 1 * DIGITは、（ "Date"ヘッダーで示されるように）この応答の発生後、指定された分数（秒ではなく）の計測タイムアウトを設定します。タイムアウトの期限が切れたときに、プロキシがこの応答のゼロ以外のヒットカウントを持っている場合、プロキシはその時刻以前にサーバーにレポートを送信する必要があります。タイムアウトは、プラスまたはマイナス1分の精度で実装する必要があります。 「do-report」を意味します。
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.
wont-askは、プロキシーがサーバーにMeterヘッダーを送信してはならないことを指定します。プロキシは、24時間以内にこのアドバイスを忘れるはずです。
Section 5.3 specifies the counting rules, and in particular specifies a somewhat non-obvious interpretation of the max-uses value.
セクション5.3は、カウントルールを指定し、特にmax-uses値の多少明白でない解釈を指定します。
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-meter-directive = abb-meter-request-directive | abb-meter-response-directive | abb-meter-report-directive
abb-meter-directive = abb-meter-request-directive | abb-meter-response-directive | abb-meter-report-directive
abb-meter-request-directive = "w" ; "will-report-and-limit" | "x" ; "wont-report" | "y" ; "wont-limit"
abb-meter-request-directive = "w"; 「意志報告と制限」| "バツ" ; 「不報告」| "y"; 「制限なし」
abb-meter-report-directive =
| "c" "=" 1*DIGIT "/" 1*DIGIT ; "count"
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"
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-Meter BNFルールはMeterルールとは別に定義されていますが、同じヘッダー内で省略形と省略形以外のMeterディレクティブを自由に混在させることができます。
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.
注：ヒット数と使用数は、リソースではなく個々の応答に関連付けられていることに注意してください。この意味で、存続期間中に複数の応答を保持するキャッシュエントリも、「応答」ではありません。
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を選択する要求ヘッダー（存在する場合は、HTTP / 1.1仕様[4]のセクション14.43を参照）を選択します。 Rの「使用」は、プロキシが格納されたRのコピーを、次のいずれかのステータスコードを含む応答で返すときに発生すると定義します。200（OK）ステータス。 203（非権威情報）ステータス。または、応答にエンティティのバイト＃0が含まれている場合は206（部分コンテンツ）ステータス（範囲要求の説明については、セクション5.4を参照）。
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.
リクエストがエンティティのバイト＃0を指定しない範囲リクエストでない限り、Rの「再利用」は、プロキシが304（Not Modified）ステータスでRを選択するリクエストに応答するときに発生すると定義します。
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のヒットメータリングに参加しているプロキシは、Rに関連付けられたCUとCRの2つのカウンターを維持します。プロキシが最初にRをキャッシュに保存すると、CUとCRの両方が0（ゼロ）に設定されます。後続のクライアント要求の結果、Rが「使用」されると、プロキシはCUをインクリメントします。後続のクライアント要求の結果、Rが「再利用」されると、プロキシはCRを増分します。 Rを選択する後続のクライアント要求（Vを含む）に「カウント」メーターディレクティブが含まれている場合、プロキシはディレクティブの対応する値を使用して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 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.
プロキシがR（Vを含む）を選択するリクエストをインバウンドサーバーに送信すると、現在のCUおよびCRをパラメーター値として持つ「カウント」メーターディレクティブが含まれます。この要求がクライアントからのプロキシの要求の受信によって引き起こされた場合、サーバーの応答を受信すると、プロキシはCUとCRをそれぞれ、要求の進行中に発生した使用と再利用の数に設定します。 （これらの数値はゼロになる可能性がありますが、確実ではありません。）プロキシーの要求が最終的なHEADベースのレポートである場合、CUおよびCRの値を維持する必要はありませんが、介在する使用の数に設定することもできます。そしてそれらを再利用して保持します。
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がゼロになるのは、その応答の「max-uses」メーターディレクティブを受信したときのみです（最初の受信を含む）。同様に、TRは、その応答に対する "max-reuses" 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の使用制限に参加しているプロキシは、Rに関連付けられた値MUおよび/またはMRも格納します。最大使用値のみを含む応答を受信すると、MUをその値に設定し、MRを無限大に設定します。 max-reuses値のみを含む応答を受信すると、MRをその値に、MUを無限大に設定します。 max-reusesとmax-reusesの両方の値を含む応答を受信すると、MUとMRをそれぞれこれらの値に設定します。 max-reuses値もmax-reuses値も含まない後続の応答を受信すると、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である場合、要求をサーバーに転送する必要があります。 （どちらの場合でも）プロキシが前の要求をサーバーにすでに転送し、応答を待っている場合、応答が到着する（またはタイムアウトする）まで、新しい要求の処理を遅らせる必要があります。異なるサブレンジを選択するRangeリクエストでない限り、同じレスポンスを選択する2つの保留中の再検証リクエストを同時に保留しないでください。
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.
「max-uses」ディレクティブには、このルールの特殊なケースがあります。プロキシが「max-uses = 0」で応答を受信し、それを要求元のクライアントに転送しない場合、プロキシは、関連するフラグPFを設定する必要があります。 R. Rがtrueの場合、要求が到着したときにTU> = MUの場合、PFフラグが設定されていれば、要求をサーバーに転送する必要はありません（これが他のキャッシングルールで要求されていない場合）。ただし、PFフラグは、応答の使用時にクリアする必要があります。
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フラグを実装する必要はありません。
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はゼロ以外であり、サーバーの応答には新しい「max-uses」や「max-reuses」ディレクティブが含まれます（したがって、TUをゼロにします）および/またはTR、ただしCUおよびCRは除く）。
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. プロキシはヒットカウントを報告する条件付きリクエストを発行します（したがって、CUとCRをゼロにしますが、TUまたはTRはゼロにしません）が、サーバーの応答に新しい「max-uses」または「max-reuses」ディレクティブが含まれていません。
To solve the first case, the proxy has several implementation options
最初のケースを解決するために、プロキシにはいくつかの実装オプションがあります
- Always store TU and TR separately from CU and CR.
- TUおよびTRは常にCUおよびCRとは別に保管してください。
- 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).
- 非条件付きリクエストが送信されたとき（または「max-uses = 0」が受信されたとき）にHEADベースの使用状況レポートを生成し、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フラグを削除することも可能ですが、これはお勧めしません。追加のリクエストを送信するよりも、エントリごとに追加のビットを割り当てる方が適切です。
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リクエストのみであるということです。このルールの理論的根拠は、ほとんどすべてのケースで、エンドクライアントはそれが参照するすべてのリソースの先頭を取得し、ほとんどの場合、一度に複数の部分を取得することはありません。したがって、このルールは「ベストエフォート」近似の目標を満たしているように見えます。
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.
メータリングサブツリーに参加する非キャッシュプロキシ（HTTP / 1.1以降）は、適切な接続ヘッダーを使用して、要求と応答の両方でメーターヘッダーを転送する必要があります（SHOULD）。
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ヘッダーを転送する場合、そのような応答は、それを引き出したものを除いて、いかなる要求にも返されてはなりません（MUST NOT）。
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.
何らかの理由で一部の応答のみをキャッシュし、他の応答をキャッシュしないプロキシは、キャッシュする応答のキャッシュプロキシとして、およびキャッシュしない応答の非キャッシュプロキシとして、Meterヘッダーを実装することを選択できます。特定の応答に関する外部の動作は、この仕様と完全に一致しているためです。
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キャッシュ実装、特にHarvest / Squidキャッシュ[2]は、いくつかのキャッシュ間の協調配置を作成します。そのようなキャッシュが、インターネットキャッシュプロトコル（ICP）[12]など、HTTP以外のプロトコルを使用して相互に通信する場合、およびそれらがMeterヘッダーを実装する場合、それらのキャッシュの協力が意図に反しないように行動しなければなりません（MUST）。この仕様。
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つのメンバーがサーバーと合意して特定の応答を測定し、その応答を非HTTPプロトコル経由でグループ内の2番目のキャッシュに渡す場合、キャッシュはサーバーがメータリングを要求したレポートは、2次キャッシュによって行われた使用または結果を適切に説明するレポートを受け取ります。同様に、最初のキャッシュが応答の使用制限に合意した場合、キャッシュのグループによる使用の総数は、合意された数に制限される必要があります。
6 Examples
6例
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
The proxy forwards request to the origin server:
プロキシは、要求をオリジンサーバーに転送します。
GET /bar.html HTTP/1.1 Host: foo.com Connection: Meter
GET /bar.html HTTP / 1.1ホスト：foo.com接続：メーター
thus offering (implicitly) "will-report-and-limit".
したがって、（暗黙的に）「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"
thus (implicitly) requiring "do-report" (but not requiring usage-limiting).
したがって、（暗黙的に）「do-report」が必要です（ただし、使用制限は必要ありません）。
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
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.
プロキシは、クライアントがエンドシステムであるか、メータリングを行わないプロキシであるかを認識していないため、「proxy-mustcheck」ディレクティブを追加します。
Another client soon asks for the resource:
別のクライアントがすぐにリソースを要求します。
GET 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
But now the response's max-age has been exceeded, so the proxy revalidates the response with the origin server:
しかし、今や応答のmax-ageを超えているため、プロキシは元のサーバーで応答を再検証します。
GET /bar.html HTTP/1.1
If-None-Match: "abcde"
Host: foo.com
Connection: Meter
Meter: count=1/0
thus simultaneously fulfilling its duties to validate the response and to report the one "use" that wasn't forwarded.
したがって、応答を検証し、転送されなかった1つの「使用」を報告するという義務を同時に果たします。
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"
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.
したがって、プロキシは元の応答を使用して新しいクライアントに応答できます。プロキシは、その応答に関連付けられている使用回数もゼロにします。
Another client soon asks for the resource:
別のクライアントがすぐにリソースを要求します。
GET 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:
さらに数時間後、プロキシはキャッシュエントリを削除することを決定します。その場合、オリジンサーバーに送信します。
HEAD /bar.html HTTP/1.1
If-None-Match: "abcde"
Host: foo.com
Connection: Meter
Meter: count=1/0
reporting that one more use of the response was satisfied from the cache.
キャッシュからの応答のもう1つの使用が満たされたことを報告します。
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エンドシステムクライアントが過剰なGETを生成することを望んでいる場合（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.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キャッシュはmax-ageディレクティブを参照し、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ヘッダーを監視しますが、一部は使用していない可能性があります。 Expiresヘッダーを使用してHTTP / 1.0プロキシによるキャッシュを防止することは、完全に信頼できるとは限りません。
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
GET /bar.html HTTP / 1.1 Host：foo.com Connection：Meter Meter：wont-limit
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
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
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. 提案された透過的コンテンツネゴシエーションメカニズムを使用する応答の処理（セクション7.2）。
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のVaryヘッダーで名前が付けられたヘッダー（[4]が「selecting request-headers」と呼ぶもの）の組み合わせごとに個別のカウントを保持する必要があります。このルールは、ページのバリアントが複数ある場合、各バリアントのヒットをカウントする効果があります。
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要求の多くの側面について個別の統計を取得できます。
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.
たとえば、リクエストのUser-Agentヘッダーの値に基づいてページが変化した場合、ヒットカウントはブラウザーの異なるフレーバーごとに保持されます。しかし、実際にはそれよりも一般的です。複数のヘッダーの組み合わせが同じバリアントにマッピングできるため、オリジンサーバーは英語でのみ利用可能であっても、ページのスワヒリ語バージョンがリクエストされた回数（たとえば）をカウントすることもできます。
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メカニズムを部分的に実装することが許可されます。
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.
このアプローチは、要求ストリームのほとんどすべての側面をカウントするために機能します。仕様またはプロキシ実装に、カウント可能な側面の特定のリストを埋め込むことはありません。
[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.]
[この設計と提案された透過的コンテンツネゴシエーション（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.
一部の広告主は、「ヒット」ではなく「ニブル」（詳細情報を得るために実際に広告をクリックした人の数）によってコンテンツプロバイダーに支払いたいと主張しています。
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
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
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.
302をキャッシュしないプロキシは、使用ごとにリダイレクトページに1回ヒットしますが、実際のページはキャッシュされます。 302をキャッシュし、キャッシュされた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.
このアプローチには、エンドクライアントがリファラーの使用を無効にしたかどうかに関係なく機能するという利点があります。この設計のその他のヒットメータリングの提案と組み合わせると、このアプローチにより、たとえば、広告主は特定のページから広告への参照が行われた頻度を知ることができます。
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, 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].
統計的サンプリング手法を使用して、適度に正確なデータを収集する可能性があるという推測がいくつかあります。そのような提案の1つは、キャッシュの有効期限を操作して、選択されたリソースが慎重に選択された期間にわたって到達不能になるようにし、サーバーがそれらの期間中のアクセスを正確にカウントできるようにすることです。ここで提案されているヒットメータリングメカニズムは、それらのカウントを収集するコストを削減するために使用できるため、そのアプローチを完全に補完します。 James 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.
Phillip Hallam-Bakerは、ログ交換プロトコル[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].
Web測定標準のトピックに関する一般的な背景については、Thomas P. NovakおよびDonna L. Hoffmanによる議論を参照してください[8]。また、World Wide Web Consortiumによって管理されている「プライバシーと人口統計の概要」ページ[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-Authorizationを使用して自身を認証したとき、および/または承認済みプロキシのリストにある場合に、アウトバウンドプロキシから受信した使用カウントのみをインバウンドサーバーにリレーすることを選択できます。
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.
プライバシーについて：このドキュメントの設計では、「Cache-control：max-age = 0、proxy-revalidate」に対する既存のHTTP / 1.1サポートの実装によってすでに明らかにされているよりも、個々のユーザーに関する情報は明らかにならないようです。または「Cache-control：s-maxage = 0」。実際には、プロキシの送信側の組織構造の特定の側面を隠すのに役立つ場合があります。いずれにせよ、匿名性に関するユーザー要件と人口統計情報に関するオリジンサーバー要件の間の矛盾は、純粋に技術的な手段では解決できません。
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 Baird-Smith、Ted Hardie、Koen Holtman（セクション8で説明されている手法を提案）、Dave Kristol、Ari Luotonen、Patrick R. McManus、Ingrid Melve、James Pitkowから受け取った建設的なコメントに感謝します。
12 References
12参照
1. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
1. Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、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、Peter B. Danzig、Chuck Neerdaels、Michael F. Schwartz、Kurt J. Worrell。階層型インターネットオブジェクトキャッシュ。手続き1996 USENIX Technical Conf。、サンディエゴ、1996年1月、pp。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. Fielding、R.、Gettys、J.、Mogul、J.、Nielsen、H。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」、RFC 2068、1997年1月。
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-proxy-960221、World Wide Web Consortium、1996年2月。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. Holtman、K。、およびA. Mutz、「HTTPでの透過的なコンテンツネゴシエーション」、Work in Progress。
7. Mogul, J., "Forcing HTTP/1.1 proxies to revalidate responses", Work in Progress.
7. Mogul、J。、「HTTP / 1.1プロキシに応答の再検証を強制する」、Work in Progress。
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.ホフマン。新しいメディアの新しい測定基準：Web測定標準の開発に向けて。これはドラフトペーパーであり、現在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. ジェームス・ピットコウ。 WWWで信頼できる使用状況データを検索します。手続き第6回国際ワールドワイドウェブ会議、カリフォルニア州サンタクララ、1997年4月。
10. Joseph Reagle, Rohit Khare, Dan Connolly, and Tim Berners-Lee. Privacy and Demographics Overview. http://www.w3.org/pub/WWW/Demographics/.
10. Joseph Reagle、Rohit Khare、Dan Connolly、Tim Berners-Lee。プライバシーと人口統計の概要。 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. リンダ・トーシャーとソール・グリーンバーグ。 World Wide Web Navigationの再訪パターン。リサーチレポート96/587/07、カルガリー大学コンピュータサイエンス学部、1996年3月。http：//www.cpsc.ucalgary.ca/projects/grouplab/papers/96WebReuse/TechReport96.html。
12. Wessels, D., and K. Claffy "Internet Cache Protocol (ICP), version 2", RFC 2186, September 1997.
12. Wessels、D。、およびK. Claffy「インターネットキャッシュプロトコル（ICP）、バージョン2」、RFC 2186、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.
ジェフリーC.モーグルウエスタンリサーチラボラトリーデジタル機器コーポレーション250ユニバーシティアベニューパロアルト、カリフォルニア、94305、アメリカ
EMail: mogul@wrl.dec.com
Phone: 1 415 617 3304 (email preferred)
Paul J. Leach Microsoft 1 Microsoft Way Redmond, Washington, 98052, U.S.A.
ポールJ.リーチマイクロソフト1マイクロソフトウェイレドモンド、ワシントン、98052、アメリカ
EMail: paulle@microsoft.com
14 Full Copyright Statement
14完全な著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物を作成したり、コピーしたり、公開したり、配布したりすることができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。