[要約] 要約：RFC 3143は、HTTPプロキシ/キャッシュの既知の問題についての情報を提供するものである。 目的：このRFCの目的は、HTTPプロキシ/キャッシュの問題を理解し、それらを回避するためのガイドラインを提供することである。
Network Working Group I. Cooper
Request for Comments: 3143 Equinix, Inc.
Category: Informational J. Dilley
Akamai Technologies, Inc.
June 2001
Known HTTP Proxy/Caching Problems
既知のHTTPプロキシ/キャッシングの問題
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This document catalogs a number of known problems with World Wide Web (WWW) (caching) proxies and cache servers. The goal of the document is to provide a discussion of the problems and proposed workarounds, and ultimately to improve conditions by illustrating problems. The construction of this document is a joint effort of the Web caching community.
このドキュメントは、World Wide Web（www）（キャッシュ）プロキシとキャッシュサーバーに関する多くの既知の問題をカタログ化します。このドキュメントの目標は、問題と提案された回避策の議論を提供し、最終的に問題を説明することで条件を改善することです。このドキュメントの構築は、Webキャッシングコミュニティの共同の努力です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Problem Template . . . . . . . . . . . . . . . . . . . . . . 2
2. Known Problems . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Known Specification Problems . . . . . . . . . . . . . . . . 5
2.1.1 Vary header is underspecified and/or misleading . . . . . . 5
2.1.2 Client Chaining Loses Valuable Length Meta-Data . . . . . . 9
2.2 Known Architectural Problems . . . . . . . . . . . . . . . . 10
2.2.1 Interception proxies break client cache directives . . . . . 10
2.2.2 Interception proxies prevent introduction of new HTTP
methods . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Interception proxies break IP address-based authentication . 12
2.2.4 Caching proxy peer selection in heterogeneous networks . . . 13
2.2.5 ICP Performance . . . . . . . . . . . . . . . . . . . . . . 15
2.2.6 Caching proxy meshes can break HTTP serialization of content 16
2.3 Known Implementation Problems . . . . . . . . . . . . . . . 17
2.3.1 User agent/proxy failover . . . . . . . . . . . . . . . . . 17
2.3.2 Some servers send bad Content-Length headers for files that
contain CR . . . . . . . . . . . . . . . . . . . . . . . 18
3. Security Considerations . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
A. Archived Known Problems . . . . . . . . . . . . . . . . . . 21
A.1 Architectural . . . . . . . . . . . . . . . . . . . . . . . 21
A.1.1 Cannot specify multiple URIs for replicated resources . . . 21
A.1.2 Replica distance is unknown . . . . . . . . . . . . . . . . 22
A.1.3 Proxy resource location . . . . . . . . . . . . . . . . . . 23
A.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . 23
A.2.1 Use of Cache-Control headers . . . . . . . . . . . . . . . . 23
A.2.2 Lack of HTTP/1.1 compliance for caching proxies . . . . . . 24
A.2.3 ETag support . . . . . . . . . . . . . . . . . . . . . . . . 25
A.2.4 Servers and content should be optimized for caching . . . . 26
A.3 Administration . . . . . . . . . . . . . . . . . . . . . . . 27
A.3.1 Lack of fine-grained, standardized hierarchy controls . . . 27
A.3.2 Proxy/Server exhaustive log format standard for analysis . . 27
A.3.3 Trace log timestamps . . . . . . . . . . . . . . . . . . . . 28
A.3.4 Exchange format for log summaries . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . . 32
This memo discusses problems with proxies - which act as application-level intermediaries for Web requests - and more specifically with caching proxies, which retain copies of previously requested resources in the hope of improving overall quality of service by serving the content locally. Commonly used terminology in this memo can be found in the "Internet Web Replication and Caching Taxonomy"[2].
このメモは、Webリクエストのアプリケーションレベルの仲介業者として機能するプロキシと、より具体的にはキャッシュプロキシを使用して問題について説明します。このメモで一般的に使用される用語は、「インターネットWebレプリケーションとキャッシュ分類法」に記載されています[2]。
No individual or organization has complete knowledge of the known problems in Web caching, and the editors are grateful to the contributors to this document.
Webキャッシングの既知の問題に関する完全な知識はありません。編集者は、このドキュメントへの貢献者に感謝しています。
A common problem template is used within the following sections. We gratefully acknowledge RFC2525 [1] which helped define an initial format for this known problems list. The template format is summarized in the following table and described in more detail below.
一般的な問題テンプレートは、次のセクション内で使用されます。この既知の問題リストの初期形式を定義するのに役立つRFC2525 [1]に感謝します。テンプレート形式を次の表にまとめ、以下に詳細に説明します。
Name: short, descriptive name of the problem (3-5 words)
Classification: classifies the problem: performance, security, etc
Description: describes the problem succinctly
Significance: magnitude of problem, environments where it exists
Implications: the impact of the problem on systems and networks
See Also: a reference to a related known problem
Indications: states how to detect the presence of this problem
Solution(s): describe the solution(s) to this problem, if any
Workaround: practical workaround for the problem
References: information about the problem or solution
Contact: contact name and email address for this section
Name A short, descriptive, name (3-5 words) name associated with the problem.
問題に関連付けられた短い、説明的な名前（3〜5語）の名前を付けます。
Classification Problems are grouped into categories of similar problems for ease of reading of this memo. Choose the category that best describes the problem. The suggested categories include three general categories and several more specific categories.
分類の問題は、このメモを読みやすくするために、同様の問題のカテゴリにグループ化されます。問題を最もよく説明するカテゴリを選択してください。推奨されるカテゴリには、3つの一般的なカテゴリといくつかのより具体的なカテゴリが含まれます。
* Architecture: the fundamental design is incomplete, or incorrect
* アーキテクチャ：基本的なデザインは不完全であるか、間違っています
* Specification: the spec is ambiguous, incomplete, or incorrect.
* 仕様：スペックはあいまい、不完全、または間違っています。
* Implementation: the implementation of the spec is incorrect.
* 実装：仕様の実装が正しくありません。
* Performance: perceived page response at the client is excessive; network bandwidth consumption is excessive; demand on origin or proxy servers exceed reasonable bounds.
* パフォーマンス：クライアントでの知覚ページ応答は過剰です。ネットワーク帯域幅の消費は過剰です。起源またはプロキシサーバーの需要は、合理的な範囲を超えています。
* Administration: care and feeding of caches is, or causes, a problem.
* 投与：キャッシュのケアと摂食は、または原因で問題です。
* Security: privacy, integrity, or authentication concerns.
* セキュリティ：プライバシー、整合性、または認証の懸念。
Description A definition of the problem, succinct but including necessary background information.
説明問題の定義、簡潔ですが、必要な背景情報を含む。
Significance (High, Medium, Low) May include a brief summary of the environments for which the problem is significant.
重要性（高、中、低）には、問題が重要な環境の簡単な要約が含まれる場合があります。
Implications Why the problem is viewed as a problem. What inappropriate behavior results from it? This section should substantiate the magnitude of any problem indicated with High significance.
問題が問題と見なされる理由。それからどのような不適切な行動が生じますか？このセクションでは、有意性が高い問題の大きさを実証する必要があります。
See Also Optional. List of other known problems that are related to this one.
オプションも参照してください。これに関連する他の既知の問題のリスト。
Indications How to detect the presence of the problem. This may include references to one or more substantiating documents that demonstrate the problem. This should include the network configuration that led to the problem such that it can be reproduced. Problems that are not reproducible will not appear in this memo.
問題の存在を検出する方法を示します。これには、問題を示す1つ以上の実証文書への参照が含まれる場合があります。これには、再現できるように問題につながったネットワーク構成を含める必要があります。再現できない問題は、このメモには表示されません。
Solution(s) Solutions that permanently fix the problem, if such are known. For example, what version of the software does not exhibit the problem? Indicate if the solution is accepted by the community, one of several solutions pending agreement, or open possibly with experimental solutions.
そのようなことがわかっている場合、問題を永久に修正するソリューション（S）ソリューション。たとえば、どのバージョンのソフトウェアが問題を示していませんか？ソリューションがコミュニティによって受け入れられているかどうかを示します。これは、契約が保留されているいくつかのソリューションの1つ、または実験的なソリューションで開かれている可能性があります。
Workaround Practical workaround if no solution is available or usable. The workaround should have sufficient detail for someone experiencing the problem to get around it.
ソリューションが利用できない、または使用可能な場合は、回避策実用的な回避策。回避策は、問題を経験している人がそれを回避するのに十分な詳細を持っている必要があります。
References References to related information in technical publications or on the web. Where can someone interested in learning more go to find out more about this problem, its solution, or workarounds?
参照技術出版物またはWebで関連情報への参照。もっと学ぶことに興味がある人は、この問題、その解決策、または回避策についてもっと知るためにどこに行くことができますか？
Contact Contact name and email address of the person who supplied the information for this section. The editors are listed as contacts for anonymous submissions.
このセクションに情報を提供した人の連絡先名とメールアドレスをお問い合わせください。編集者は、匿名提出の連絡先としてリストされています。
The remaining sections of this document present the currently documented known problems. The problems are ordered by classification and significance. Issues with protocol specification or architecture are first, followed by implementation issues. Issues of high significance are first, followed by lower significance.
このドキュメントの残りのセクションは、現在文書化されている既知の問題を示しています。問題は、分類と重要性によって順序付けられます。プロトコルの仕様またはアーキテクチャの問題が最初に行われ、その後に実装の問題が続きます。重要な問題が最初に行われ、その後に重要性が低下します。
Some of the problems initially identified in the previous versions of this document have been moved to Appendix A since they discuss issues where resolution primarily involves education rather than protocol work.
このドキュメントの以前のバージョンで最初に特定された問題のいくつかは、解決が主にプロトコル作業ではなく教育が関与する問題について議論しているため、付録Aに移動されました。
A full list of the problems is available in the table of contents.
問題の完全なリストは、目次で入手できます。
Name The "Vary" header is underspecified and/or misleading
「Vary」ヘッダーに名前を付けるには、想定されていない、および/または誤解を招く
Classification Specification
分類仕様
Description The Vary header in HTTP/1.1 was designed to allow a caching proxy to safely cache responses even if the server's choice of variants is not entirely understood. As RFC 2616 says:
説明HTTP/1.1のVaryヘッダーは、サーバーのバリアントの選択が完全に理解されていなくても、キャッシュプロキシが応答を安全にキャッシュできるように設計されています。RFC 2616が言うように：
The Vary header field can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
さまざまなヘッダーフィールドを使用して、サーバーが使用するパラメーターを表現して、サーバー駆動型のネゴシエーションの対象となる表現を選択できます。
One might expect that this mechanism is useful in general for extensions that change the response message based on some aspects of the request. However, that is not true.
このメカニズムは、要求のいくつかの側面に基づいて応答メッセージを変更する拡張機能に一般的に役立つと予想されるかもしれません。しかし、それは真実ではありません。
During the design of the HTTP delta encoding specification[9] it was realized that an HTTP/1.1 proxy that does not understand delta encoding might cache a delta-encoded response and then later deliver it to a non-delta-capable client, unless the extension included some mechanism to prevent this. Initially, it was thought that Vary would suffice, but the following scenario proves this wrong.
http deltaエンコード仕様[9]の設計中、デルタエンコードを理解していないHTTP/1.1プロキシは、デルタにエンコードされた応答をキャッシュし、後で非デルタ対応クライアントに配信する可能性があることがわかりました。拡張には、これを防ぐためのいくつかのメカニズムが含まれていました。当初、さまざまで十分であると考えられていましたが、次のシナリオではこれが間違っていることがわかります。
NOTE: It is likely that other scenarios exhibiting the same basic problem with "Vary" could be devised, without reference to delta encoding. This is simply a concrete scenario used to explain the problem.
注：「Vary」と同じ基本的な問題を示す他のシナリオが、デルタエンコーディングを参照せずに考案できる可能性があります。これは、問題を説明するために使用される具体的なシナリオです。
A complete description of the IM and A-IM headers may be found in the "Delta encoding in HTTP" specification. For the purpose of this problem description, the relevant details are:
IMおよびA-IMヘッダーの完全な説明は、「HTTPでのデルタエンコード」仕様に記載されています。この問題の説明の目的のために、関連する詳細は次のとおりです。
1. The concept of an "instance manipulation" is introduced. In some ways, this is similar to a content-coding, but there are differences. One example of an instance manipulation name is "vcdiff".
1. 「インスタンス操作」の概念が導入されています。いくつかの点で、これはコンテンツコーディングに似ていますが、違いがあります。インスタンス操作名の1つの例は「vcdiff」です。
2. A client signals its willingness to accept one or more instance-manipulations using the A-IM header.
2. クライアントは、A-IMヘッダーを使用して1つまたは複数のインスタンスマニピュレーションを受け入れる意欲を示しています。
3. A server indicates which instance-manipulations are used to encode the body of a response using the IM header.
3. サーバーは、IMヘッダーを使用して応答の本文をエンコードするために使用されるインスタンスマニピュレーションを示します。
4. Existing implementations will ignore the A-IM and IM headers, following the usual HTTP rules for handling unknown headers.
4. 既存の実装では、不明なヘッダーを処理するための通常のHTTPルールに従って、A-IMおよびIMヘッダーを無視します。
5. Responses encoded with an instance-manipulation are sent using the (proposed) 226 status code, "IM Used".
5. インスタンス操作でエンコードされた回答は、（提案された）226ステータスコード「IM使用」を使用して送信されます。
6. In response to a conditional request that carries an IM header, if the request-URI has been modified then a server may transmit a compact encoding of the modifications using a delta-encoding instead of a status-200 response. The encoded response cannot be understood by an implementation that does not support delta encodings.
6. IMヘッダーを運ぶ条件付きリクエストに応じて、リクエスト-URIが変更された場合、サーバーは、ステータス-200応答の代わりにデルタエンコードを使用して変更のコンパクトなエンコードを送信できます。エンコードされた応答は、デルタエンコーディングをサポートしていない実装では理解できません。
This summary omits many details.
この要約では、多くの詳細が省略されています。
Suppose client A sends this request via proxy P:
クライアントAがプロキシPを介してこのリクエストを送信するとします。
GET http://example.com/foo.html HTTP/1.1 Host: example.com If-None-Match: "abc" A-IM: vcdiff
get http://example.com/foo.html http/1.1ホスト：example.com if-none-match： "abc" a-im：vcdiff
and the origin server returns, via P, this response:
Origin Serverは、Pを介してこの応答を返します。
HTTP/1.1 226 IM Used Etag: "def" Date: Wed, 19 Apr 2000 18:46:13 GMT IM: vcdiff Cache-Control: max-age-60 Vary: A-IM, If-None-Match
HTTP/1.1 226 IM使用ETAG： "def"日付：水、2000年4月19日18:46:13 GMT IM：vcdiffキャッシュ制御：max-age-60 vary：a-im、if-none-match
the body of which is a delta-encoded response (it encodes the difference between the Etag "abc" instance of foo.html, and the "def" instance). Assume that P stores this response in its cache, and that P does not understand the vcdiff encoding.
ボディはデルタエンコードされた応答です（foo.htmlのETAG「ABC」インスタンスと「def」インスタンスの違いをエンコードします）。Pがこの応答をキャッシュに保存し、PがVCDIFFエンコーディングを理解していないと仮定します。
Later, client B, also ignorant of delta-encoding, sends this request via P:
その後、クライアントBは、デルタエンコードについても無知であり、このリクエストをPで送信します。
GET http://example.com/foo.html HTTP/1.1 Host: example.com
http://example.com/foo.html http/1.1ホスト：example.comを入手してください
What can P do now? According to the specification for the Vary header in RFC2616,
Pは今何ができますか？RFC2616のVaryヘッダーの仕様によると、
The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation.
変化するフィールド値は、応答が新鮮である一方で、応答を使用して再確認なしで後続の要求に応答することが許可されているかどうかに完全に決定するリクエストヘッダーフィールドのセットを示します。
Implicitly, however, the cache would be allowed to use the stored response in response to client B WITH "revalidation". This is the potential bug.
ただし、暗黙的に、キャッシュは、「再検証」を伴うクライアントBに応答して、保存された応答を使用することが許可されます。これが潜在的なバグです。
An obvious implementation of the proxy would send this request to test whether its cache entry is fresh (i.e., to revalidate the entry):
プロキシの明らかな実装は、この要求を送信して、キャッシュエントリが新鮮かどうかをテストします（つまり、エントリを再検証するため）：
GET /foo.html HTTP/1.1 Host: example.com If-None-Match: "def"
get /foo.html http /1.1ホスト：example.com if-none-match： "def"
That is, the proxy simply forwards the new request, after doing the usual transformation on the URL and tacking on the "obvious" If-None-Match header.
つまり、プロキシは、URLで通常の変換を行い、「明らかな」IF-Noneマッチヘッダーにタックした後、単に新しいリクエストを転送します。
If the origin server's Etag for the current instance is still "def", it would naturally respond:
現在のインスタンスのOrigin ServerのETAGがまだ「def」である場合、自然に応答します。
HTTP/1.1 304 Not Modified Etag: "def" Date: Wed, 19 Apr 2000 18:46:14 GMT
HTTP/1.1 304変更されていないETAG： "def"日付：水、2000年4月19日18:46:14 GMT
thus telling the proxy P that it can use its stored response. But this cache response actually involves a delta-encoding that would not be sensible to client B, signaled by a header field that would be ignored by B, and so the client displays garbage.
したがって、プロキシPに、保存された応答を使用できることを伝えます。しかし、このキャッシュ応答には、実際にはクライアントBに賢明ではないデルタエンコードが含まれ、Bが無視するヘッダーフィールドによってシグナルがあるため、クライアントはゴミを表示します。
The problem here is that the original request (from client A) generated a response that is not sensible to client B, not merely one that is not "the appropriate representation" (as the result of server-driven negotiation).
ここでの問題は、（クライアントAから）元の要求が、単に「適切な表現」ではないものではなく、クライアントBに対して賢明ではない応答を生成したことです（サーバー駆動型の交渉の結果として）。
One might argue that the proxy P shouldn't be storing status-226 responses in the first place. True in theory, perhaps, but unfortunately RFC2616, section 13.4, says:
プロキシPは、そもそもStatus-226応答を保存するべきではないと主張するかもしれません。理論的には、おそらくそうですが、残念ながらRFC2616、セクション13.4は次のように述べています。
A response received with any [status code other than 200, 203, 206, 300, 301 or 410] MUST NOT be returned in a reply to a subsequent request unless there are cache-control directives or another header(s) that explicitly allow it. For example, these include the following: an Expires header (section 14.21); a "max-age", "s-maxage", "must-revalidate", "proxy-revalidate", "public" or "private" cache-control directive (section 14.9).
[200、203、206、300、301、または410以外のステータスコード]で受信した回答は、明示的に許可するキャッシュコントロールディレクティブまたは別のヘッダーがない限り、後続のリクエストへの返信に返信してはなりません。。たとえば、これらには次のものが含まれます。「最大時代」、「S-Maxage」、「必須の再バリデート」、「プロキシ - 再バリデート」、「パブリック」または「プライベート」キャッシュコントロールディレクティブ（セクション14.9）。
In other words, the specification allows caching of responses with yet-to-be-defined status codes if the response carries a plausible Cache-Control directive. So unless we ban servers implementing this kind of extension from using these Cache-Control directives at all, the Vary header just won't work.
言い換えれば、この仕様により、応答がもっともらしいキャッシュコントロールディレクティブを搭載している場合、まだ定義されていないステータスコードを使用して応答をキャッシュできます。したがって、この種の拡張機能を実装するサーバーを禁止しない限り、これらのキャッシュコントロールディレクティブをまったく使用することをまったく使用しないでください。さまざまなヘッダーは機能しません。
Significance Medium
有意性媒体
Implications Certain plausible extensions to the HTTP/1.1 protocol might not interoperate correctly with older HTTP/1.1 caches, if the extensions depend on an interpretation of Vary that is not the same as is used by the cache implementer.
http/1.1プロトコルに対する特定のもっともらしい拡張は、拡張がキャッシュ実装者が使用するものと同じではない変化の解釈に依存する場合、古いHTTP/1.1キャッシュと正しく相互運用しない可能性があります。
This would have the effect either of causing hard-to-debug cache transparency failures, or of discouraging the deployment of such extensions, or of encouraging the implementers of such extensions to disable caching entirely.
これは、非難が困難なキャッシュの透明性の障害を引き起こすこと、またはそのような拡張の展開を思いとどまらせるか、そのような拡張機能の実装者にキャッシュを完全に無効にするよう促す効果があります。
Indications The problem is visible when hand-simulating plausible message exchanges, especially when using the proposed delta encoding extension. It probably has not been visible in practice yet.
適応症問題は、特に提案されているデルタエンコード拡張を使用する場合、手作業のもっともるいメッセージ交換の場合に表示されます。おそらく実際にはまだ見えていません。
Solution(s)
解決策
1. Section 13.4 of the HTTP/1.1 specification should probably be changed to prohibit caching of responses with status codes that the cache doesn't understand, whether or not they include Expires headers and the like. (It might require some care to define what "understands" means, leaving room for future extensions with new status codes.) The behavior in this case needs to be defined as equivalent to "Cache-Control: no-store" rather than "no-cache", since the latter allows revalidation.
1. HTTP/1.1のセクション13.4は、おそらく、キャッシュが理解していないステータスコードを使用して、ヘッダーの有効期限などを含むかどうかにかかわらず、キャッシュが理解していないステータスコードのキャッシュを禁止するために変更する必要があります。（「理解」の意味を定義するためにある程度の注意が必要な場合があり、新しいステータスコードを備えた将来の拡張の余地を残します。）この場合の動作は、「キャッシュコントロール：ノーストア」に相当するものとして定義する必要があります。-cache "、後者は再検証を可能にするため。
Possibly the specification of Vary should require that it be treated as "Cache-Control: no-store" whenever the status code is unknown - that should solve the problem in the scenario given here.
おそらく、さまざまな仕様では、ステータスコードが不明な場合はいつでも「キャッシュコントロール：ストアなし」として扱われる必要があります。
2. Designers of HTTP/1.1 extensions should consider using mechanisms other than Vary to prevent false caching.
2. HTTP/1.1拡張機能の設計者は、誤検出を防ぐために変化する以外のメカニズムの使用を検討する必要があります。
It is not clear whether the Vary mechanism is widely implemented in caches; if not, this favors solution #1.
さまざまなメカニズムがキャッシュで広く実装されているかどうかは明らかではありません。そうでない場合、これはソリューション＃1を好みます。
Workaround A cache could treat the presence of a Vary header in a response as an implicit "Cache-control: no-store", except for "known" status codes, even though this is not required by RFC 2616. This would avoid any transparency failures. "Known status codes" for basic HTTP/1.1 caches probably include: 200, 203, 206, 300, 301, 410 (although this list should be re-evaluated in light of the problem discussed here).
回避策キャッシュは、「既知の」ステータスコードを除いて、これはRFC 2616では必要ではないにもかかわらず、「既知の」ステータスコードを除き、暗黙の「キャッシュコントロール：ストアなし」として異なるヘッダーの存在を処理できます。これは透明性を回避します。障害。基本的なHTTP/1.1キャッシュの「既知のステータスコード」には、おそらく200、203、206、300、301、410が含まれます（ただし、このリストは、ここで説明した問題に照らして再評価する必要があります）。
References See [9] for the specification of the delta encoding extension, as well as for an example of the use of a Cache-Control extension instead of "Vary."
参考文献[9]は、「Vary」ではなくキャッシュコントロール拡張機能の使用の例と同様に、[9]を参照してください。
Contact Jeff Mogul <mogul@pa.dec.com>
jeff mogul <mogul@pa.dec.com>にお問い合わせください
Name Client Chaining Loses Valuable Length Meta-Data
名前クライアントチェーンは、貴重な長さのメタデータを失います
Classification Performance
分類パフォーマンス
Description HTTP/1.1[3] implementations are prohibited from sending Content-Length headers with any message whose body has been Transfer-Encoded. Because 1.0 clients cannot accept chunked Transfer-Encodings, receiving 1.1 implementations must forward the body to 1.0 clients must do so without the benefit of information that was discarded earlier in the chain.
説明HTTP/1.1 [3]実装は、本文が転送されたメッセージを含むコンテンツ長ヘッダーを送信することを禁止されています。1.0クライアントはチャンクされた転送エンコードを受け入れることができないため、1.1の実装を受信すると、チェーンの早い段階で廃棄された情報の恩恵なしに、1.0クライアントを1.0クライアントに転送する必要があります。
Significance Low
重要性低い
Implications Lacking either a chunked transfer encoding or Content-Length indication creates negative performance implications for how the proxy must forward the message body.
充電された転送エンコードまたはコンテンツレングスの表示のいずれかを欠く意味すると、プロキシがメッセージ本文をどのように転送しなければならないかに否定的なパフォーマンスの意味合いが生じます。
In the case of response bodies, the server may either forward the response while closing the connection to indicate the end of the response or must utilize store and forward semantics to buffer the entire response in order to calculate a Content-Length. The former option defeats the performance benefits of persistent connections in HTTP/1.1 (and their Keep-Alive cousin in HTTP/1.0) as well as creating some ambiguously lengthed responses. The latter store and forward option may not even be feasible given the size of the resource and it will always introduce increased latency.
応答本体の場合、サーバーは、応答を閉じて応答を閉じて応答の終了を示しながら応答を転送するか、コンテンツレングスを計算するためにストアと応答全体をバッファーするためにストアとフォワードのセマンティクスを使用する必要があります。前者のオプションは、HTTP/1.1（およびHTTP/1.0のキープアライブのいとこ）の永続的な接続のパフォーマンスの利点を打ち負かし、曖昧に長さの応答を作成します。リソースのサイズを考えると、後者のストアとフォワードオプションは実行不可能である場合があり、常にレイテンシの増加をもたらします。
Request bodies must undertake the store and forward process as 1.0 request bodies must be delimited by Content-Length headers. As with response bodies this may place unacceptable resource constraints on the proxy and the request may not be able to be satisfied.
1.0リクエストボディはコンテンツレングスヘッダーによって区切られる必要があるため、リクエストボディはストアを引き受けて転送する必要があります。応答団体と同様に、これはプロキシに受け入れられないリソースの制約を置く可能性があり、リクエストが満たすことができない場合があります。
Indications The lack of HTTP/1.0 style persistent connections between 1.0 clients and 1.1 proxies, only when accessing 1.1 servers, is a strong indication of this problem.
1.1サーバーにアクセスする場合にのみ、1.0クライアントと1.1プロキシの間のHTTP/1.0スタイルの永続的な接続の欠如は、この問題を強く示しています。
Solution(s) An HTTP specification clarification that would allow origin known identity document Content-Lengths to be carried end to end would alleviate this issue.
ソリューション（s）既知のアイデンティティドキュメントのコンテンツレングスを端から端まで伝えることを可能にするHTTP仕様の明確化は、この問題を軽減するでしょう。
Workaround None.
回避策なし。
Contact Patrick McManus <mcmanus@AppliedTheory.com>
Patrick McManus <McManus@appliedTheory.com>にお問い合わせください
Name Interception proxies break client cache directives
名前インターセプトプロキシは、クライアントキャッシュディレクティブを破ります
Classification Architecture
分類アーキテクチャ
Description HTTP[3] is designed for the user agent to be aware if it is connected to an origin server or to a proxy. User agents believing they are transacting with an origin server but which are really in a connection with an interception proxy may fail to send critical cache-control information they would have otherwise included in their request.
説明HTTP [3]は、ユーザーエージェントがOrigin ServerまたはProxyに接続されているかどうかを認識できるように設計されています。Origin Serverを使用して取引していると考えているユーザーエージェントは、インターセプトプロキシに実際に関連していると考えています。
Significance High
重要性が高い
Implications Clients may receive data that is not synchronized with the origin even when they request an end to end refresh, because of the lack of inclusion of either a "Cache-control: no-cache" or "must-revalidate" header. These headers have no impact on origin server behavior so may not be included by the browser if it believes it is connected to that resource. Other related data implications are possible as well. For instance, data security may be compromised by the lack of inclusion of "private" or "no-store" clauses of the Cache-control header under similar conditions.
意味クライアントは、「キャッシュコントロール：ノーキャッシュ」または「必見」ヘッダーのいずれかが含まれていないため、エンドツーエンドの更新を要求した場合でも、オリジンと同期しないデータを受信する場合があります。これらのヘッダーは、Origin Serverの動作に影響を与えないため、そのリソースに接続されていると考えられている場合、ブラウザに含まれない場合があります。他の関連データへの影響も可能です。たとえば、データセキュリティは、同様の条件下でのキャッシュコントロールヘッダーの「プライベート」または「ストアなし」の条項が含まれていないために損なわれる可能性があります。
Indications Easily detected by placing fresh (un-expired) content on a caching proxy while changing the authoritative copy, then requesting an end-to-end reload of the data through a proxy in both interception and explicit modes.
権威あるコピーを変更しながら、キャッシュプロキシに新鮮な（expired）コンテンツを配置することで簡単に検出され、インターセプトモードと明示的モードの両方でプロキシを介してデータのエンドツーエンドのリロードを要求します。
Solution(s) Eliminate the need for interception proxies and IP spoofing, which will return correct context awareness to the client.
解決策は、インターセプトプロキシとIPスプーフィングの必要性を排除し、クライアントに正しいコンテキスト認識を返します。
Workaround Include relevant Cache-Control directives in every request at the cost of increased bandwidth and CPU requirements.
回避策には、帯域幅の増加とCPU要件のコストで、すべての要求に関連するキャッシュ制御指令が含まれます。
Contact Patrick McManus <mcmanus@AppliedTheory.com>
Patrick McManus <McManus@appliedTheory.com>にお問い合わせください
Name Interception proxies prevent introduction of new HTTP methods
名前傍受プロキシは、新しいHTTPメソッドの導入を防ぎます
Classification Architecture
分類アーキテクチャ
Description A proxy that receives a request with a method unknown to it is required to generate an HTTP 501 Error as a response. HTTP methods are designed to be extensible so there may be applications deployed with initial support just for the user agent and origin server. An interception proxy that hijacks requests which include new methods destined for servers that have implemented those methods creates a de-facto firewall where none may be intended.
説明は、応答としてHTTP 501エラーを生成するために必要なメソッドを使用してリクエストを受信するプロキシ。HTTPメソッドは拡張可能になるように設計されているため、ユーザーエージェントとOrigin Server専用の最初のサポートでアプリケーションが展開される可能性があります。これらのメソッドを実装したサーバー向けの新しいメソッドを含むリクエストをハイジャックするインターセプトプロキシは、何も意図していないファクトルファイアウォールを作成します。
Significance Medium within interception proxy environments.
インターセプトプロキシ環境内の重要な媒体。
Implications Renders new compliant applications useless unless modifications are made to proxy software. Because new methods are not required to be globally standardized it is impossible to keep up to date in the general case.
影響は、プロキシソフトウェアに変更が加えられない限り、新しい準拠アプリケーションを役に立たないものにします。新しい方法はグローバルに標準化される必要がないため、一般的なケースで最新の状態を維持することは不可能です。
Solution(s) Eliminate the need for interception proxies. A client receiving a 501 in a traditional HTTP environment may either choose to repeat the request to the origin server directly, or perhaps be configured to use a different proxy.
解決策は、傍受プロキシの必要性を排除します。従来のHTTP環境で501を受信しているクライアントは、RequessをOrigin Serverに直接繰り返すことを選択するか、別のプロキシを使用するように構成されている場合があります。
Workaround Level 5 switches (sometimes called Level 7 or application layer switches) can be used to keep HTTP traffic with unknown methods out of the proxy. However, these devices have heavy buffering responsibilities, still require TCP sequence number spoofing, and do not interact well with persistent connections.
回避策レベル5スイッチ（レベル7またはアプリケーションレイヤースイッチと呼ばれることもあります）を使用して、不明な方法でHTTPトラフィックをプロキシから締め出すことができます。ただし、これらのデバイスには強いバッファリングの責任があり、TCPシーケンス数のスプーフィングが必要であり、永続的な接続とうまく相互作用しません。
The HTTP/1.1 specification allows a proxy to switch over to tunnel mode when it receives a request with a method or HTTP version it does not understand how to handle.
HTTP/1.1仕様により、メソッドまたはHTTPバージョンでリクエストを受信したときにプロキシがトンネルモードに切り替えることができます。
Contact
Patrick McManus <mcmanus@AppliedTheory.com>
Henrik Nordstrom <hno@hem.passagen.se> (HTTP/1.1 clarification)
Name Interception proxies break IP address-based authentication
名前インターセプトプロキシは、IPアドレスベースの認証を破壊します
Classification Architecture
分類アーキテクチャ
Description Some web servers are not open for public access, but restrict themselves to accept only requests from certain IP address ranges for security reasons. Interception proxies alter the source (client) IP addresses to that of the proxy itself, without the knowledge of the client/user. This breaks such authentication mechanisms and prohibits otherwise allowed clients access to the servers.
説明一部のWebサーバーはパブリックアクセスのために開かれていませんが、セキュリティ上の理由から特定のIPアドレス範囲からのリクエストのみを受け入れるように制限します。インターセプトプロキシは、クライアント/ユーザーの知識なしに、ソース（クライアント）IPアドレスをプロキシ自体のアドレスに変更します。これにより、このような認証メカニズムが破られ、それ以外の場合はクライアントがサーバーにアクセスできるようになります。
Significance Medium
有意性媒体
Implications Creates end user confusion and frustration.
意味は、エンドユーザーの混乱とフラストレーションを生み出します。
Indications Users may start to see refused connections to servers after interception proxies are deployed.
インターセプトプロキシが展開された後、ユーザーがサーバーへの拒否された接続を確認し始める可能性があります。
Solution(s) Use user-based authentication instead of (IP) address-based authentication.
解決策（IP）アドレスベースの認証の代わりに、ユーザーベースの認証を使用します。
Workaround Using IP filters at the intercepting device (L4 switch) and bypass all requests to such servers concerned.
インターセプトデバイス（L4スイッチ）でIPフィルターを使用した回避策と、関係するサーバーにすべてのリクエストをバイパスします。
Contact Keith K. Chau <keithc@unitechnetworks.com>
Keith K. Chau <keithc@unitechnetworks.com>にお問い合わせください
Name Caching proxy peer selection in heterogeneous networks
異種ネットワークでのキャッシングプロキシピア選択
Classification Architecture
分類アーキテクチャ
Description ICP[4] based caching proxy peer selection in networks with large variance in latency and bandwidth between peers can lead to non-optimal peer selection. For example take Proxy C with two siblings, Sib1 and Sib2, and the following network topology (summarized).
説明ICP [4]ベースのキャッシングプロキシピア選択ネットワークでのピア選択は、ピア間の潜在性と帯域幅が大きく異なります。たとえば、2人の兄弟、SIB1とSIB2、および次のネットワークトポロジ（要約）でプロキシCを取ります。
* Cache C's link to Sib1, 2 Mbit/sec with 300 msec latency
* Cache CのSIB1へのリンク、300ミリ秒のレイテンシ付き2 Mbit/Sec
* Cache C's link to Sib2, 64 Kbit/sec with 10 msec latency.
* Cache CのSIB2へのリンク、10ミリ秒のレイテンシで64 KBIT/SEC。
ICP[4] does not work well in this context. If a user submits a request to Proxy C for page P that results in a miss, C will send an ICP request to Sib1 and Sib2. Assume both siblings have the requested object P. The ICP_HIT reply will always come from Sib2 before Sib1. However, it is clear that the retrieval of large objects will be faster from Sib1, rather than Sib2.
ICP [4]は、この文脈ではうまく機能しません。ユーザーがMISSになるPage PのプロキシCにリクエストを送信すると、CはSIB1とSIB2にICPリクエストを送信します。両方の兄弟が要求されたオブジェクトPを持っていると仮定します。ICP_HIT応答は常にSIB1の前にSIB2から来るでしょう。ただし、大きなオブジェクトの検索がSIB2ではなくSIB1からより速くなることは明らかです。
The problem is more complex because Sib1 and Sib2 can't have a 100% hit ratio. With a hit rate of 10%, it is more efficient to use Sib1 with resources larger than 48K. The best choice depends on at least the hit rate and link characteristics; maybe other parameters as well.
SIB1とSIB2には100％のヒット率がないため、問題はより複雑です。10％のヒット率では、48Kを超えるリソースでSIB1を使用する方が効率的です。最良の選択は、少なくともヒット率とリンクの特性に依存します。たぶん他のパラメーターも同様です。
Significance Medium
有意性媒体
Implications By using the first peer to respond, peer selection algorithms are not optimizing retrieval latency to end users. Furthermore they are causing more work for the high-latency peer since it must respond to such requests but will never be chosen to serve content if the lower latency peer has a copy.
最初のピアを使用して応答することによる意味、ピア選択アルゴリズムは、エンドユーザーへの検索レイテンシを最適化していません。さらに、彼らはそのようなリクエストに応答する必要があるため、高層のピアにより多くの作業を引き起こしていますが、低レイテンシーピアがコピーを持っている場合、コンテンツを提供するために選択されることはありません。
Indications Inherent in design of ICP v1, ICP v2, and any cache mesh protocol that selects peers based upon first response.
ICP V1、ICP V2、および最初の応答に基づいてピアを選択するキャッシュメッシュプロトコルの設計に固有の適応症。
This problem is not exhibited by cache digest or other protocols which (attempt to) maintain knowledge of peer contents and only hit peers that are believed to have a copy of the requested page.
この問題は、ピアコンテンツの知識を維持し、要求されたページのコピーを持っていると考えられているピアのみを攻撃する（試み）（試みます）他のプロトコルによっては示されません。
Solution(s) This problem is architectural with the peer selection protocols.
解決策この問題は、ピア選択プロトコルを備えたアーキテクチャです。
Workaround Cache mesh design when using such a protocol should be done in such a way that there is not a high latency variance among peers. In the example presented in the above description the high latency high bandwidth peer could be used as a parent, but should not be used as a sibling.
このようなプロトコルを使用する場合の回避策メッシュ設計は、ピア間で高いレイテンシの差異がないように行う必要があります。上記の説明に示されている例では、高いレイテンシの高い帯域幅ピアを親として使用できますが、兄弟として使用するべきではありません。
Contact
Ivan Lovric <ivan.lovric@cnet.francetelecom.fr>
John Dilley <jad@akamai.com>
Name ICP performance
ICPパフォーマンスに名前を付けます
Classification Architecture(ICP), Performance
分類アーキテクチャ（ICP）、パフォーマンス
Description ICP[4] exhibits O(n^2) scaling properties, where n is the number of participating peer proxies. This can lead ICP traffic to dominate HTTP traffic within a network.
説明ICP [4]はO（n^2）スケーリングプロパティを示します。ここで、nは参加しているピアプロキシの数です。これにより、ICPトラフィックがネットワーク内のHTTPトラフィックを支配することができます。
Significance Medium
有意性媒体
Implications If a proxy has many ICP peers the bandwidth demand of ICP can be excessive. System managers must carefully regulate ICP peering. ICP also leads proxies to become homogeneous in what they serve; if your proxy does not have a document it is unlikely your peers will have it either. Therefore, ICP traffic requests are largely unable to locate a local copy of an object (see [6]).
プロキシに多くのICPピアがある場合、ICPの帯域幅の需要は過剰になる可能性があります。システムマネージャーは、ICPピアリングを慎重に規制する必要があります。ICPはまた、プロキシが彼らが奉仕するものに均一になるように導きます。あなたのプロキシにドキュメントがない場合、あなたの仲間がそれを持っている可能性は低いです。したがって、ICPトラフィックリクエストは、ほとんどオブジェクトのローカルコピーを見つけることができません（[6]を参照）。
Indications Inherent in design of ICP v1, ICP v2.
ICP V1、ICP V2の設計に固有の適応症。
Solution(s) This problem is architectural - protocol redesign or replacement is required to solve it if ICP is to continue to be used.
ソリューションこの問題は、ICPを使用し続ける場合に解決するために、Architectural -Architectural -Protocolの再設計または交換が必要です。
Workaround Implementation workarounds exist, for example to turn off use of ICP, to carefully regulate peering, or to use another mechanism if available, such as cache digests. A cache digest protocol shares a summary of cache contents using a Bloom Filter technique. This allows a cache to estimate whether a peer has a document. Filters are updated regularly but are not always up-to-date so cannot help when a spike in popularity occurs. They also increase traffic but not as much as ICP.
回避策の実装の回避策は、たとえばICPの使用をオフにしたり、ピアリングを慎重に調節したり、キャッシュダイジェストなどの利用可能な場合は別のメカニズムを使用したりします。キャッシュダイジェストプロトコルは、ブルームフィルター技術を使用してキャッシュコンテンツの要約を共有しています。これにより、キャッシュはピアがドキュメントを持っているかどうかを推定できます。フィルターは定期的に更新されますが、常に最新であるとは限らないため、人気のスパイクが発生した場合は役に立ちません。また、トラフィックを増やしますが、ICPほどではありません。
Proxy clustering protocols organize proxies into a mesh provide another alternative solution. There is ongoing research on this topic.
プロキシクラスタリングプロトコルは、プロキシをメッシュに整理し、別の代替ソリューションを提供します。このトピックに関する継続的な研究があります。
Contact John Dilley <jad@akamai.com>
John Dilley <jad@akamai.com>にお問い合わせください
Name Caching proxy meshes can break HTTP serialization of content
名前キャッシュプロキシメッシュは、コンテンツのHTTPシリアル化を破ることができます
Classification Architecture (HTTP protocol)
分類アーキテクチャ（HTTPプロトコル）
Description A caching proxy mesh where a request may travel different paths, depending on the state of the mesh and associated caches, can break HTTP content serialization, possibly causing the end user to receive older content than seen on an earlier request, where the request traversed another path in the mesh.
説明要求がメッシュの状態と関連するキャッシュの状態に応じて異なるパスを移動する可能性のあるキャッシュプロキシメッシュは、HTTPコンテンツのシリアル化を破ることができ、おそらくエンドユーザーが以前の要求で見られるよりも古いコンテンツを受信する可能性があります。メッシュの別のパス。
Significance Medium
有意性媒体
Implications Can cause end user confusion. May in some situations (sibling cache hit, object has changed state from cacheable to uncacheable) be close to impossible to get the caches properly updated with the new content.
意味はエンドユーザーの混乱を引き起こす可能性があります。状況によっては（兄弟キャッシュがヒットし、オブジェクトがキャッシュ可能から不可能な状態に状態が変更された場合）、新しいコンテンツでキャッシュを適切に更新することができます。
Indications Older content is unexpectedly returned from a caching proxy mesh after some time.
適応症の古いコンテンツは、しばらくするとキャッシュプロキシメッシュから予想外に返されます。
Solutions(s) Work with caching proxy vendors and researchers to find a suitable protocol for maintaining proxy relations and object state in a mesh.
ソリューションは、プロキシベンダーと研究者のキャッシュと連携して、メッシュ内のプロキシ関係とオブジェクト状態を維持するための適切なプロトコルを見つけます。
Workaround When designing a hierarchy/mesh, make sure that for each end-user/URL combination there is only one single path in the mesh during normal operation.
回避策階層/メッシュを設計するときは、各エンドユーザー/URLの組み合わせに対して、通常の動作中にメッシュに1つのパスしかないことを確認してください。
Contact Henrik Nordstrom <hno@hem.passagen.se>
Henrik Nordstrom <hno@hem.passagen.se>にお問い合わせください
Name User agent/proxy failover
名前ユーザーエージェント/プロキシフェールオーバー
Classification Implementation
分類の実装
Description Failover between proxies at the user agent (using a proxy.pac[8] file) is erratic and no standard behavior is defined. Additionally, behavior is hard-coded into the browser, so that proxy administrators cannot use failover at the user agent effectively.
説明ユーザーエージェントのプロキシ間のフェールオーバー（proxy.pac [8]ファイルを使用）は不安定であり、標準動作は定義されていません。さらに、動作はブラウザにハードコーディングされるため、プロキシ管理者はユーザーエージェントでフェールオーバーを効果的に使用できません。
Significance Medium
有意性媒体
Implications Architects are forced to implement failover at the proxy itself, when it may be more appropriate and economical to do it within the user agent.
影響アーキテクトは、ユーザーエージェント内でそれを行う方が適切かつ経済的な場合、プロキシ自体にフェイルオーバーを実装することを余儀なくされます。
Indications If a browser detects that its primary proxy is down, it will wait n minutes before trying the next one it is configured to use. It will then wait y minutes before asking the user if they'd like to try the original proxy again. This is very confusing for end users.
適応ブラウザがその主要なプロキシがダウンしていることを検出した場合、使用するように構成されている次のプロキシを試す前に、n分が待機します。その後、ユーザーに元のプロキシをもう一度試したいかどうかを尋ねる前に、Y分待ちます。これはエンドユーザーにとって非常に混乱しています。
Solution(s) Work with browser vendors to establish standard extensions to JavaScript proxy.pac libraries that will allow configuration of these timeouts.
ソリューションブラウザーベンダーと連携して、これらのタイムアウトの構成を可能にするJavaScript Proxy.PACライブラリへの標準拡張機能を確立します。
Workaround User education; redundancy at the proxy level.
回避策ユーザー教育。プロキシレベルでの冗長性。
Contact Mark Nottingham <mnot@mnot.net>
マークノッティンガム<mnot@mnot.net>にお問い合わせください
Name Some servers send bad Content-Length headers for files that contain CR
いくつかのサーバーに名前を付けて、CRを含むファイルに悪いコンテンツレングスヘッダーを送信します
Classification Implementation
分類の実装
Description Certain web servers send a Content-length value that is larger than number of bytes in the HTTP message body. This happens when the server strips off CR characters from text files with lines terminated with CRLF as the file is written to the client. The server probably uses the stat() system call to get the file size for the Content-Length header. Servers that exhibit this behavior include the GN Web server (version 2.14 at least).
説明特定のWebサーバーは、HTTPメッセージ本文のバイト数よりも大きいコンテンツレングス値を送信します。これは、ファイルがクライアントに書き込まれると、CRLFで終了した行を持つテキストファイルからサーバーがCR文字を取り除いたときに起こります。サーバーはおそらくSTAT（）システムコールを使用して、コンテンツ長ヘッダーのファイルサイズを取得します。この動作を示すサーバーには、GN Webサーバー（少なくともバージョン2.14）が含まれます。
Significance Low. Surveys indicate only a small number of sites run faulty servers.
重要性低い。調査では、故障したサーバーを実行するサイトの数のみが示されています。
Implications In this case, an HTTP client (e.g., user agent or proxy) may believe it received a partial response. HTTP/1.1 [3] advises that caches MAY store partial responses.
この場合、HTTPクライアント（ユーザーエージェントやプロキシなど）は、部分的な応答を受け取ったと思われる場合があります。HTTP/1.1 [3]は、キャッシュが部分的な応答を保存する可能性があることをアドバイスしています。
Indications Count the number of bytes in the message body and compare to the Content-length value. If they differ the server exhibits this problem.
適応症は、メッセージ本文のバイト数をカウントし、コンテンツレングスの値と比較します。それらが異なる場合、サーバーはこの問題を示します。
Solutions Upgrade or replace the buggy server.
ソリューションのアップグレードまたはバギーサーバーを交換します。
Workaround Some browsers and proxies use one TCP connection per object and ignore the Content-Length. The document end of file is identified by the close of the TCP socket.
一部のブラウザとプロキシは、オブジェクトごとに1つのTCP接続を使用し、コンテンツレングスを無視します。ファイルのドキュメントエンドは、TCPソケットの終了によって識別されます。
Contact Duane Wessels <wessels@measurement-factory.com>
Duane Wessels <wessels@measurementfactory.com>にお問い合わせください
This memo does not raise security considerations in itself. See the individual submissions for details of security concerns and issues.
このメモは、それ自体がセキュリティ上の考慮事項を提起するものではありません。セキュリティの懸念と問題の詳細については、個々の提出物を参照してください。
References
参考文献
[1] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J. and B. Volz, "Known TCP Implementation Problems", RFC 2525, March 1999.
[1] Paxson、V.、Allman、M.、Dawson、S.、Fenner、W.、Griner、J.、Heavens、I.、Lahey、K.、Semke、J.、およびB. Volz、「既知のTCP実装の問題」、RFC 2525、1999年3月。
[2] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.
[2] Cooper、I.、Melve、I。およびG. Tomlinson、「インターネットWebレプリケーションとキャッシュ分類法」、RFC 3040、2001年1月。
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[3] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[4] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), Version 2", RFC 2186, September 1997.
[4] Wessels、D。およびK. Claffy、「インターネットキャッシュプロトコル（ICP）、バージョン2」、RFC 2186、1997年9月。
[5] Davison, B., "Web Traffic Logs: An Imperfect Resource for Evaluation", in Proceedings of the Ninth Annual Conference of the Internet Society (INET'99), July 1999.
[5] Davison、B。、「Web Traffic Logs：An An Implefect Resource for Alluation」、1999年7月、インターネット協会の第9回年次会議（INET'99）の議事録。
[6] Melve, I., "Relation Analysis, Cache Meshes", in Proceedings of the 3rd International WWW Caching Workshop, June 1998, <http://wwwcache.ja.net/events/workshop/29/magicnumber.html>.
[6] Melve、I。、「関係分析、キャッシュメッシュ」、第3回国際WWWキャッシュワークショップの議事録、1998年6月、<http://wwwcache.ja.net/events/workshop/29/magicnumber.html>。
[7] Krishnamurthy, B. and M. Arlett, "PRO-COW: Protocol Compliance on the Web", AT&T Labs Technical Report #990803-05-TM, August 1999, <http://www.research.att.com/~bala/papers/procow-1.ps.gz>.
[7] Krishnamurthy、B。and M. Arlett、「Pro-Cow：Protocol Conpliance on the Web」、AT＆T Labsテクニカルレポート＃990803-05-TM、1999年8月、<http://www.research.att.com/~bala/papers/procow-1.ps.gz>。
[8] Netscape, Inc., "Navigator Proxy Auto-Config File Format", March 1996, http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html
[8] Netscape、Inc。、「Navigator Proxy Auto-Config File Format」、1996年3月、http：//home.netscape.com/eng/2.0/relnotes/demo/proxy-live.html
[9] Mogul, J., Krishnamurthy, B., Douglis, F., Feldmann, A., Goland, Y., van Hoff, A. and D. Hellerstein, "HTTP Delta in HTTP", Work in Progress.
[9] Mogul、J.、Krishnamurthy、B.、Douglis、F.、Feldmann、A.、Goland、Y.、Van Hoff、A。、およびD. Hellerstein、「HTTP Delta in HTTP」、進行中の作業。
Authors' Addresses
著者のアドレス
Ian Cooper Equinix, Inc. 2450 Bayshore Parkway Mountain View, CA 94043 USA
Ian Cooper Equinix、Inc。2450 Bayshore Parkway Mountain View、CA 94043 USA
Phone: +1 650 316 6065
EMail: icooper@equinix.com
John Dilley Akamai Technologies, Inc. 1400 Fashion Island Blvd Suite 703 San Mateo, CA 94404 USA
John Dilley Akamai Technologies、Inc。1400 Fashion Island Blvd Suite 703 San Mateo、CA 94404 USA
Phone: +1 650 627 5244
EMail: jad@akamai.com
The following sub-sections are an archive of problems identified in the initial production of this memo. These are typically problems requiring further work/research, or user education. They are included here for reference purposes only.
次のサブセクションは、このメモの初期生産で特定された問題のアーカイブです。これらは通常、さらなる仕事/研究、またはユーザー教育を必要とする問題です。参照目的でのみここに含まれています。
Name Cannot specify multiple URIs for replicated resources
名前は複製されたリソースに複数のURIを指定できません
Classification Architecture
分類アーキテクチャ
Description There is no way to specify that multiple URIs may be used for a single resource, one for each replica of the resource. Similarly, there is no way to say that some set of proxies (each identified by a URI) may be used to resolve a URI.
説明複数のURIを単一のリソースに使用することができることを指定する方法はありません。同様に、URIの解決に使用される可能性があるプロキシのセット（それぞれがURIによって識別される）を言う方法はありません。
Significance Medium
有意性媒体
Implications Forces users to understand the replication model and mechanism. Makes it difficult to create a replication framework without protocol support for replication and naming.
その意味では、ユーザーは複製モデルとメカニズムを理解する必要があります。複製と命名のプロトコルサポートなしで、複製フレームワークを作成することを困難にします。
Indications Inherent in HTTP/1.0, HTTP/1.1.
HTTP/1.0、HTTP/1.1に固有の適応症。
Solution(s) Architectural - protocol design is necessary.
ソリューションアーキテクチャ - プロトコル設計が必要です。
Workaround Replication mechanisms force users to locate a replica or mirror site for replicated content.
回避策レプリケーションメカニズムにより、ユーザーは複製されたコンテンツのレプリカまたはミラーサイトを見つけることができます。
Contact Daniel LaLiberte <liberte@w3.org>
Daniel Laliberte <liberte@w3.org>にお問い合わせください
Name Replica distance is unknown
名前のレプリカ距離は不明です
Classification Architecture
分類アーキテクチャ
Description There is no recommended way to find out which of several servers or proxies is closer either to the requesting client or to another machine, either geographically or in the network topology.
説明いくつかのサーバーまたはプロキシのどれがリクエストクライアントまたは地理的またはネットワークトポロジのいずれかのいずれかに近いかを見つけることを推奨する方法はありません。
Significance Medium
有意性媒体
Implications Clients must guess which replica is closer to them when requesting a copy of a document that may be served from multiple locations. Users must know the set of servers that can serve a particular object. This in general is hard to determine and maintain. Users must understand network topology in order to choose the closest copy. Note that the closest copy is not always the one that will result in quickest service. A nearby but heavily loaded server may be slower than a more distant but lightly loaded server.
意味クライアントは、複数の場所から提供される可能性のあるドキュメントのコピーをリクエストするときに、どのレプリカがそれらに近いかを推測する必要があります。ユーザーは、特定のオブジェクトを提供できるサーバーのセットを知る必要があります。これは一般に、決定と維持をするのは困難です。ユーザーは、最も近いコピーを選択するためにネットワークトポロジを理解する必要があります。最も近いコピーは、常に最も速いサービスをもたらすものではないことに注意してください。近くではあるが重度のロードされたサーバーは、より遠いが軽いサーバーよりも遅くなる可能性があります。
Indications Inherent in HTTP/1.0, HTTP/1.1.
HTTP/1.0、HTTP/1.1に固有の適応症。
Solution(s) Architectural - protocol work is necessary. This is a specific instance of a general problem in widely distributed systems. A general solution is unlikely, however a specific solution in the web context is possible.
ソリューション（S）アーキテクチャ - プロトコル作業が必要です。これは、広く分散されたシステムにおける一般的な問題の特定のインスタンスです。一般的なソリューションはありそうにありませんが、Webコンテキストの特定のソリューションが可能です。
Workaround Servers can (many do) provide location hints in a replica selection web page. Users choose one based upon their location. Users can learn which replica server gives them best performance. Note that the closest replica geographically is not necessarily the closest in terms of network topology. Expecting users to understand network topology is unreasonable.
回避策サーバーは、レプリカ選択Webページの場所のヒントを提供できます（多くのこと）。ユーザーは自分の場所に基づいて1つを選択します。ユーザーは、どのレプリカサーバーが最高のパフォーマンスを提供するかを学ぶことができます。地理的に最も近いレプリカは、ネットワークトポロジの点で必ずしも最も近いものではないことに注意してください。ユーザーがネットワークトポロジを理解することを期待することは不合理です。
Contact Daniel LaLiberte <liberte@w3.org>
Daniel Laliberte <liberte@w3.org>にお問い合わせください
Name Proxy resource location
名前プロキシリソースの場所
Classification Architecture
分類アーキテクチャ
Description There is no way for a client or server (including another proxy) to inform a proxy of an alternate address (perhaps including the proxy to use to reach that address) to use to fetch a resource. If the client does not trust where the redirected resource came from, it may need to validate it or validate where it came from.
説明クライアントまたはサーバー（別のプロキシを含む）が代替アドレス（おそらくそのアドレスに到達するために使用するプロキシを含む）のプロキシにリソースを取得するために使用する方法はありません。クライアントがリダイレクトされたリソースがどこから来たのかを信頼していない場合、それを検証するか、それがどこから来たのかを検証する必要があるかもしれません。
Significance Medium
有意性媒体
Implications Proxies have no systematic way to locate resources within other proxies or origin servers. This makes it more difficult to share information among proxies. Information sharing would improve global efficiency.
意味プロキシには、他のプロキシまたはオリジンサーバー内のリソースを見つける体系的な方法はありません。これにより、プロキシ間で情報を共有することがより困難になります。情報共有は、グローバルな効率を改善します。
Indications Inherent in HTTP/1.0, HTTP/1.1.
HTTP/1.0、HTTP/1.1に固有の適応症。
Solution(s) Architectural - protocol design is necessary.
ソリューションアーキテクチャ - プロトコル設計が必要です。
Workaround Certain proxies share location hints in the form of summary digests of their contents (e.g., Squid). Certain proxy protocols enable a proxy query another for its contents (e.g., ICP). (See however "ICP Performance" issue (Section 2.2.5).)
回避策特定のプロキシは、その内容の要約ダイジェストの形で位置ヒントを共有します（例：Squid）。特定のプロキシプロトコルにより、プロキシクエリのコンテンツ（ICPなど）が別のクエリを使用できます。（ただし、「ICPパフォーマンス」の問題（セクション2.2.5）を参照してください。）
Contact Daniel LaLiberte <liberte@w3.org>
Daniel Laliberte <liberte@w3.org>にお問い合わせください
Name Use of Cache-Control headers
キャッシュコントロールヘッダーの名前の使用
Classification Implementation
分類の実装
Description Many (if not most) implementations incorrectly interpret Cache-Control response headers.
説明キャッシュコントロール応答ヘッダーを誤って解釈する多くの（ほとんどではないにしても）実装。
Significance High
重要性が高い
Implications Cache-Control headers will be spurned by end users if there are conflicting or non-standard implementations.
意味キャッシュ制御ヘッダーは、矛盾するまたは標準以外の実装がある場合、エンドユーザーによって促進されます。
Indications -
適応 -
Solution(s) Work with vendors and others to assure proper application
ソリューションベンダーなどと連携して、適切な適用を保証する
Workaround None.
回避策なし。
Contact Mark Nottingham <mnot@mnot.net>
マークノッティンガム<mnot@mnot.net>にお問い合わせください
Name Lack of HTTP/1.1 compliance for caching proxies
名前の不足HTTP/1.1キャッシュプロキシのコンプライアンス
Classification Implementation
分類の実装
Description Although performance benchmarking of caches is starting to be explored, protocol compliance is just as important.
説明キャッシュのパフォーマンスベンチマークの検討が開始されていますが、プロトコルコンプライアンスも同様に重要です。
Significance High
重要性が高い
Implications Caching proxy vendors implement their interpretation of the specification; because the specification is very large, sometimes vague and ambiguous, this can lead to inconsistent behavior between caching proxies.
意味キャッシュプロキシベンダーは、仕様の解釈を実装します。仕様は非常に大きく、時にはあいまいで曖昧なため、プロキシのキャッシュ間の一貫性のない動作につながる可能性があります。
Caching proxies need to comply to the specification (or the specification needs to change).
キャッシュプロキシは、仕様に従う必要があります（または仕様を変更する必要があります）。
Indications There is no currently known compliance test being used.
適応症現在既知のコンプライアンステストは使用されていません。
There is work underway to quantify how closely servers comply with the current specification. A joint technical report between AT&T and HP Labs [7] describes the compliance testing. This report examines how well each of a set of top traffic-producing sites support certain HTTP/1.1 features.
サーバーが現在の仕様にどのように密接に準拠しているかを定量化するための作業が進行中です。AT＆TとHP Labs [7]の共同技術レポートは、コンプライアンステストについて説明しています。このレポートでは、トップトラフィックを生成する各セットが特定のHTTP/1.1機能をどの程度サポートしているかを調べます。
The Measurement Factory (formerly IRCache) is working to develop protocol compliance testing software. Running such a conformance test suite against caching proxy products would measure compliance and ultimately would help assure they comply to the specification.
測定工場（以前のIrcache）は、プロトコルコンプライアンステストソフトウェアの開発に取り組んでいます。キャッシュプロキシ製品に対してこのような適合テストスイートを実行すると、コンプライアンスが測定され、最終的には仕様に準拠することを保証するのに役立ちます。
Solution(s) Testing should commence and be reported in an open industry forum. Proxy implementations should conform to the specification.
ソリューションテストは、オープン業界のフォーラムで開始し、報告する必要があります。プロキシの実装は、仕様に準拠する必要があります。
Workaround There is no workaround for non-compliance.
回避策は、コンプライアンス違反の回避策はありません。
Contact
Mark Nottingham <mnot@mnot.net>
Duane Wessels <wessels@measurement-factory.com>
Name ETag support
名前ETAGサポート
Classification Implementation
分類の実装
Description Available caching proxies appear not to support ETag (strong) validation.
説明利用可能なキャッシングプロキシは、ETAG（強い）検証をサポートしていないようです。
Significance Medium
有意性媒体
Implications Last-Modified/If-Modified-Since validation is inappropriate for many requirements, both because of its weakness and its use of dates. Lack of a usable, strong coherency protocol leads developers and end users not to trust caches.
意味の衰弱と日付の使用の両方で、ラスト修飾/イクな検証は多くの要件には不適切です。使用可能で強力なコヒーレンシープロトコルの欠如により、開発者とエンドユーザーがキャッシュを信頼しないようになります。
Indications -
適応 -
Solution(s) Work with vendors to implement ETags; work for better validation protocols.
ソリューションベンダーと連携してETAGを実装します。より良い検証プロトコルのために機能します。
Workaround Use Last-Modified/If-Modified-Since validation.
回避策は、ラスト修正/if修正済みの検証を使用します。
Contact Mark Nottingham <mnot@mnot.net>
マークノッティンガム<mnot@mnot.net>にお問い合わせください
Name Servers and content should be optimized for caching
名前サーバーとコンテンツは、キャッシュ用に最適化する必要があります
Classification Implementation (Performance)
分類実装（パフォーマンス）
Description Many web servers and much web content could be implemented to be more conducive to caching, reducing bandwidth demand and page load delay.
説明キャッシング、帯域幅の需要、ページの負荷遅延を減らすためにより多くのWebサーバーと多くのWebコンテンツを実装できます。
Significance Medium
有意性媒体
Implications By making poor use of caches, origin servers encourage longer load times, greater load on caching proxies, and increased network demand.
キャッシュの使用が不十分なことによる意味、Origin Serverは、より長い負荷時間、キャッシュプロキシのより大きな負荷、およびネットワーク需要の増加を促進します。
Indications The problem is most apparent for pages that have low or zero expires time, yet do not change.
適応症問題は、時間が低いまたはゼロのページで最も明白であるが、時間が切れているが、変更されない。
Solution(s) -
解決策 -
Workaround Servers could start using unique object identifiers for write-only content: if an object changes it gets a new name, otherwise it is considered to be immutable and therefore have an infinite expire age. Certain hosting providers do this already.
ワークアウンドサーバーは、書き込み専用コンテンツに一意のオブジェクト識別子の使用を開始できます。オブジェクトが変更された場合、新しい名前を取得すると、不変であると見なされ、したがって無限の期限が切れます。特定のホスティングプロバイダーはすでにこれを行っています。
Contact Peter Danzig
Peter Danzigに連絡してください
Name Lack of fine-grained, standardized hierarchy controls
名前の微調整された標準化された階層コントロールの欠如
Classification Administration
分類管理
Description There is no standard for instructing a proxy as to how it should resolve the parent to fetch a given object from. Implementations therefore vary greatly, and it can be difficult to make them interoperate correctly in a complex environment.
説明親が特定のオブジェクトを取得するためにどのように解決するかについてプロキシを指示する標準はありません。したがって、実装は大きく異なり、複雑な環境でそれらを正しく相互運用させることは困難です。
Significance Medium
有意性媒体
Implications Complications in deployment of caches in a complex network (especially corporate networks)
複雑なネットワーク（特に企業ネットワーク）でのキャッシュの展開における意味の合併症
Indications Inability of some proxies to be configured to direct traffic based on domain name, reverse lookup IP address, raw IP address, in normal operation and in failover mode. Inability in some proxies to set a preferred parent / backup parent configuration.
一部のプロキシがドメイン名、逆ルックアップIPアドレス、生のIPアドレス、通常の動作およびフェールオーバーモードに基づいてトラフィックを向けるように構成できないことを示しています。一部のプロキシでは、優先親 /バックアップの親構成を設定できません。
Solution(s) -
解決策 -
Workaround Work with vendors to establish an acceptable configuration within the limits of their product; standardize on one product.
ベンダーとの回避策は、製品の制限内で許容可能な構成を確立します。1つの製品を標準化します。
Contact Mark Nottingham <mnot@mnot.net>
マークノッティンガム<mnot@mnot.net>にお問い合わせください
Name Proxy/Server exhaustive log format standard for analysis
分析のための名前プロキシ/サーバー徹底的なログ形式標準
Classification Administration
分類管理
Description Most proxy or origin server logs used for characterization or evaluation do not provide sufficient detail to determine cacheability of responses.
説明特性評価または評価に使用されるほとんどのプロキシまたはオリジンサーバーログは、応答のカキービリティを決定するのに十分な詳細を提供しません。
Significance Low (for operationality; high significance for research efforts)
重要性低い（操作性の場合;研究努力にとって高い重要性）
Implications Characterizations and simulations are based on non-representative workloads.
意味の特性とシミュレーションは、非代表的なワークロードに基づいています。
See Also W3C Web Characterization Activity, since they are also concerned with collecting high quality logs and building characterizations from them.
W3C Webの特性評価アクティビティも参照してください。高品質のログの収集とそれらからの構築特性も関心があるためです。
Indications -
適応 -
Solution(s) To properly clean and to accurately determine cacheability of responses, a complete log is required (including all request headers as well as all response headers such as "User-agent" [for removal of spiders] and "Expires", "max-age", "Set-cookie", "no-cache", etc.)
解決策を適切にクリーニングし、応答のカキアビリティを正確に判断するために、完全なログが必要です（すべての要求ヘッダーと、[ユーザーエージェント] [スパイダーの除去のため]および「期限切れ」などのすべての応答ヘッダーを含みます。Max-Age "、" set-cookie "、" no-cache "など）
Workaround -
回避策 -
References See "Web Traffic Logs: An Imperfect Resource for Evaluation"[5] for some discussion of this.
参照「Web Trafficログ：評価のための不完全なリソース」[5]を参照してください。
Contact
Brian D. Davison <davison@acm.org>
Terence Kelly <tpkelly@eecs.umich.edu>
Name Trace log timestamps
名前トレースログタイムスタンプ
Classification Administration
分類管理
Description Some proxies/servers log requests without sufficient timing detail. Millisecond resolution is often too small to preserve request ordering and either the servers should record request reception time in addition to completion time, or elapsed time plus either one.
説明いくつかのプロキシ/サーバーは、十分なタイミングの詳細なしで要求を記録します。ミリ秒の解像度は、リクエストの注文を保持するには小さすぎることがよくあり、サーバーは完了時間、または経過時間といずれかの時間に加えてリクエストの受信時間を記録する必要があります。
Significance Low (for operationality; medium significance for research efforts)
重要性低い（操作性の場合;研究努力にとって中程度の重要性）
Implications Characterization and simulation fidelity is improved with accurate timing and ordering information. Since logs are generally written in order of request completion, these logs cannot be re-played without knowing request generation times and reordering accordingly.
意味の特性評価とシミュレーションの忠実度は、正確なタイミングと順序情報で改善されます。通常、ログはリクエストの完了の順に記述されるため、これらのログは、リクエストの生成時間を知らずにそれに応じて再注文することなく再表示することはできません。
See Also -
参照 -
Indications Timestamps can be identical for multiple entries (when only millisecond resolution is used). Request orderings can be jumbled when clients open additional connections for embedded objects while still receiving the container object.
適応的なタイムスタンプは、複数のエントリで同じである可能性があります（ミリ秒の解像度のみが使用されている場合）。クライアントがコンテナオブジェクトを受信しながら、埋め込まれたオブジェクトの追加の接続を開くと、リクエストの注文がごちゃごちゃになる可能性があります。
Solution(s) Since request completion time is common (e.g., Squid), recommend continuing to use it (with microsecond resolution if possible) plus recording elapsed time since request reception.
解決策の完了時間は一般的であるため（例：Squid）、（可能であれば、マイクロ秒解像度で）使用し続けることをお勧めします。
Workaround -
回避策 -
References See "Web Traffic Logs: An Imperfect Resource for Evaluation"[5] for some discussion of this.
参照「Web Trafficログ：評価のための不完全なリソース」[5]を参照してください。
Contact Brian D. Davison <davison@acm.org>
Brian D. Davison <davison@acm.org>にお問い合わせください
Name Exchange format for log summaries
ログの概要の名前交換形式
Classification Administration/Analysis?
分類管理/分析？
Description Although we have (more or less) a standard log file format for proxies (plain vanilla Common Logfile and Squid), there isn't a commonly accepted format for summaries of those log files. Summaries could be generated by the cache itself, or by post-processing existing log file formats such as Squid's.
説明プロキシの標準ログファイル形式（プレーンバニラ共通ログファイルとイカ）がありますが、これらのログファイルの要約については一般的に受け入れられる形式はありません。要約は、キャッシュ自体によって、またはSquidなどの既存のログファイル形式を後処理することによって生成される可能性があります。
Significance High, since it means that each log file summarizing/analysis tool is essentially reinventing the wheel (un-necessary repetition of code), and the cost of processing a large number of large log files through a variety of analysis tools is (again for no good reason) excessive.
各ログファイルの要約/分析ツールが本質的にホイールを再発明していることを意味するため（コードの不要な繰り返し）、さまざまな分析ツールを介して多数の大きなログファイルを処理するコストは（繰り返しますが）正当な理由はありません）過剰。
Implications In order to perform a meaningful analysis (e.g., to measure performance in relation to loading/configuration over time) the access logs from multiple busy caches, it's often necessary to run first one tool then another, each against the entire log file (or a significantly large subset of the log). With log files running into hundreds of MB even after compression (for a cache dealing with millions of transactions per day) this is a non-trivial task.
意味のある分析を実行するために（例：時間の経過に伴う読み込み/構成に関連するパフォーマンスを測定するため）、複数のビジーキャッシュからのアクセスログを実行するために、最初の1つのツールを実行することがしばしば必要です。ログの大幅に大きなサブセット）。圧縮後でも（1日あたり数百万のトランザクションを扱うキャッシュの場合）ログファイルが数百MBにぶつかっている場合、これは自明ではありません。
See Also IP packet/header sniffing - it may be that individual transactions are at a level of granularity which simply isn't sensible to be attempting on extremely busy caches. There may also be legal implications in some countries, e.g., if this analysis identifies individuals.
IPパケット/ヘッダースニッフィングも参照してください - 個々のトランザクションは、非常に忙しいキャッシュを試してみるのに賢明ではない粒度のレベルにあるかもしれません。また、一部の国でも法的意味がある場合があります。たとえば、この分析が個人を特定した場合。
Indications Disks/memory full(!) Stats (using multiple programs) take too long to run. Stats crunching must be distributed out to multiple machines because of its high computational cost.
表示ディスク/メモリフル（！）統計（複数のプログラムを使用）は、実行するのに時間がかかりすぎます。統計のクランチは、計算コストが高いため、複数のマシンに配布する必要があります。
Solution(s) Have the proxy produce a standardized summary of its activity either automatically or via an external (e.g., third party) tool, in a commonly agreed format. The format could be something like XML or the Extended Common Logfile, but the format and contents are subjects for discussion. Ideally this approach would permit individual cache server products to supply subsets of the possible summary info, since it may not be feasible for all servers to provide all of the information which people would like to see.
解決策は、一般的に合意された形式で、プロキシにそのアクティビティの標準化された要約を自動的に、または外部（サードパーティ）ツールを介して標準化された要約を作成します。この形式は、XMLまたは拡張された一般的なログファイルのようなものである可能性がありますが、形式とコンテンツは議論の対象です。理想的には、このアプローチでは、個々のキャッシュサーバー製品が可能な要約情報のサブセットを提供することができます。これは、すべてのサーバーが人々が見たいすべての情報を提供することができない可能性があるためです。
Workaround Devise a private summary format for your own personal use - but this complicates or even precludes the exchange of summary info with other interested parties.
回避策は、あなた自身の個人的な使用のためのプライベート要約形式を考案しますが、これは他の利害関係者との要約情報の交換を複雑にするか、さらに排除することさえあります。
References See the web pages for the commonly used cache stats analysis programs, e.g., Calamaris, squidtimes, squidclients, etc.
参考文献一般的に使用されるキャッシュ統計分析プログラムのWebページを参照してください。
Contact Martin Hamilton <martin@wwwcache.ja.net>
Martin Hamilton <martin@wwwcache.ja.net>にお問い合わせください
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。