RFC 3143 - Known HTTP Proxy/Caching Problems 日本語訳

URL : https://tools.ietf.org/html/rfc3143
タイトル : RFC 3143 - 既知の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

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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（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

1. Introduction

1. はじめに

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キャッシングにおける既知の問題の完全な知識を持っていない、と編集者は、この文書への貢献に感謝しています。

1.1 Problem Template

1.1問題のテンプレート

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

名前：短い、わかりやすい問題の名前（3-5ワード）分類：問題を分類：パフォーマンス、セキュリティ、などの説明：問題の大きさは、それが含意存在する環境：上の問題の影響問題簡潔意義を説明しますシステムやネットワーク関連項目：関連する既知の問題の兆候を参照するには、この問題の存在を検出する方法を述べています

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

溶液（S）：任意の回避策場合は、この問題への解決策（複数可）について説明します。問題の参考のための実用的な回避策を：問題や解決策の連絡先に関する情報：このセクションのための連絡先の名前とメールアドレス

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.

また、オプションを参照してください。この1に関連する他の既知の問題のリスト。

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.

適応症は、どのような問題の存在を検出することができます。これは、問題を示す一つ以上の実証の文書への参照を含むことができます。これは、それを再現することができるように、問題につながったネットワーク構成を含める必要があります。再現性がない問題は、このメモには表示されません。

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）などが知られている場合は恒久的に、問題を解決するソリューション。例えば、ソフトウェアのバージョンは、問題は発生しませんか？溶液はコミュニティによって受け入れられるかどうかを示す、いくつかの解決策の一つは、契約を保留、または実験ソリューションとおそらくオープン。

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?

技術的な出版物やウェブ上の関連情報への参照を参照。どこより学ぶことに興味を持って誰かがこの問題、その解決策、または回避策についての詳細を調べるために行くことができますか？

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.

連絡先の名前と、このセクションの情報を提供した人のメールアドレスにお問い合わせください。編集者は、匿名の提出のための連絡先として記載されています。

2. Known Problems

2.既知の問題

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.

問題の完全なリストは、目次に使用可能です。

2.1 Known Specification Problems

仕様の既知の問題2.1

2.1.1 Vary header is underspecified and/or misleading

2.1.1ヘッダが不足の及び/又は紛らわしいヴァリ

Name The "Vary" header is underspecified and/or misleading

「ヴァリ」ヘッダが不足の及び/又は紛らわしいされる名前

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デルタエンコーディング仕様の設計中に[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.

注：これは、他のシナリオは、デルタエンコーディングを参照することなく、考案することができ、「ヴァリ」と同じ基本的な問題を示す可能性があります。これは、単に問題を説明するための具体的なシナリオです。

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.「インスタンス操作」の概念が導入されています。いくつかの点で、これはコンテンツコーディングに似ていますが、違いがあります。インスタンスの操作名の一例は、「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.応答は、「IMが使用される」（提案）226ステータスコードを使用して送信されます。

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.

リクエストURIは、サーバの代わりにステータス200応答のデルタ符号化を使用して修飾のコンパクト符号を送信することができる改変された場合、IMヘッダを運ぶ条件要求に応答して6。符号化された応答は、デルタ符号化をサポートしていない実装によって理解することができません。

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-なし - 一致した場合： "ABC"-IM：vcdiff

and the origin server returns, via P, this response:

そして、オリジンサーバに戻り、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日夜06時46分13秒GMT IM：vcdiffののCache-Control：最大エージング-60は変更される場合：-IMを、場合-なしマッチ

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

GET 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で変化するヘッダの仕様によれば、

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の場合 - なし - マッチ： "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-Matchヘッダに仮止めした後、新しい要求を転送する、です。

If the origin server's Etag for the current instance is still "def", it would naturally respond:

現在のインスタンスのオリジンサーバのにEtagはまだ「DEF」であれば、それは自然に反応するだろう：

HTTP/1.1 304 Not Modified Etag: "def" Date: Wed, 19 Apr 2000 18:46:14 GMT

"DEF" 日時：水曜日、2000年4月19日午後06時46分14秒GMT HTTP / 1.1 304のEtagを変更していません

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が最初の場所での状態-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以外のステータスコード]と、受信した応答は、後続の要求に対する応答で返されてはいけません。例えば、これらは、以下を含む：Expiresヘッダ（セクション14.21）を、 "MAXAGE"、 "S-MAXAGE"、 "MUST-再検証"、 "プロキシ再検証"、 "パブリック" または "プライベート" キャッシュ制御ディレクティブ（セクション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.

応答が妥当キャッシュ制御指令を運ぶ言い換えれば、仕様はまだツー定義されるステータスコードと応答のキャッシングを可能にします。我々は、すべてこれらのCache-Controlディレクティブを使用してから、延長のこの種を実装したサーバを禁止しない限り、そう、インクルードだけでは動作しませんヘッダーを変更します。

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)

溶液（A）

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.

HTTPの1節13.4 / 1.1仕様では、おそらく彼らは、ヘッダなどを含むExpiresかどうかに関係なく、キャッシュは理解していないステータスコードとレスポンスのキャッシュを禁止するように変更する必要があります。ノー」ではなく、「無店舗をのCache-Control」（。それは、新しいステータスコードと将来の拡張の余地を残して、手段を「理解」かを定義するためにいくつかの注意が必要になる場合があります）、この場合の動作はと同等と定義する必要はありません-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.

ここでは特定のシナリオで問題を解決する必要があります - ステータスコードが不明であるときは常に：おそらくの仕様は、それが「無店舗のCache-Control」として扱われることを要求すべきであるヴァリ。

2. Designers of HTTP/1.1 extensions should consider using mechanisms other than Vary to prevent false caching.

HTTP / 1.1の拡張機能の2設計者は、偽のキャッシュを防ぐために変化以外のメカニズムを使用して検討すべきです。

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でこれが必要とされていないにもかかわらず、「既知」のステータスコードを除いて、：キャッシュは暗黙の「無店舗のCache-Control」として応じて変化ヘッダーの存在を扱うことができ回避策失敗。基本的な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]はデルタ符号化拡張の仕様、並びにキャッシュ制御拡張の使用例については代わりに「変更します。」を参照してください。

Contact Jeff Mogul <mogul@pa.dec.com>

問い合わせジェフ・モーグル<mogul@pa.dec.com>

2.1.2 Client Chaining Loses Valuable Length Meta-Data

2.1.2クライアントの連鎖は、貴重な長メタデータが失われます

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]の実装は、その本体転送符号化された任意のメッセージとのContent-Lengthヘッダを送信することを禁止されています。 1.0クライアントはチャンクされた転送エンコーディングを受け入れることができないので、1.1の実装を受信することは、以前のチェーンで廃棄された情報の恩恵なしにそれを行う必要があります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.

チャンク転送エンコードまたはのContent-Length表示はプロキシがメッセージ本体を転送する必要がありますどのように負のパフォーマンスへの影響を作成するのいずれかを欠く意味合い。

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でのキープアライブいとこ）に持続的接続のパフォーマンス上の利点を倒すだけでなく、いくつかのあいまいlengthed応答を作成します。後者のストアアンドフォワードオプションでも、リソースのサイズ与えられた実現可能ではないかもしれない、それは常に増加し、待ち時間をご紹介します。

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リクエストボディがのContent-Lengthヘッダで区切られなければならないよう要求体はストアアンドフォワードプロセスを行う必要があります。レスポンスボディを持つように、これは、プロキシ上で容認できない資源制約を置くことができ、要求を満足させることができない場合があります。

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）の原点知られている身分証明書のContent-長さは、この問題を軽減するだろう端から端まで運ばれることを可能にするHTTP仕様の明確化。

Workaround None.

回避策なし。

Contact Patrick McManus <mcmanus@AppliedTheory.com>

連絡先パトリック・マクマナス<mcmanus@AppliedTheory.com>

2.2 Known Architectural Problems

2.2既知の建築の問題

2.2.1 Interception proxies break client cache directives

2.2.1迎撃プロキシは、クライアント・キャッシュ・ディレクティブを破ります

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]に設計されています。彼らは迎撃プロキシに関連して、実際にされて、オリジンサーバーで取引されますが、信じユーザーエージェントは、彼らがそうでなければ、その要求に含まれていた重要なキャッシュ制御情報を送信するために失敗することがあります。

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.

「：キャッシュなしのCache-Control」または「-再検証しなければならない」ヘッダ含意するクライアントは、リフレッシュをエンドツーエンドを要求しても、理由のいずれかを含めることの不足のため、原点と同期していないデータを受信することができます。これらのヘッダは、オリジンサーバの動作に影響を与えないので、それがそのリソースに接続されていると考えている場合は、ブラウザによって含まれないことがあります。その他の関連データへの影響も同様に可能です。例えば、データ・セキュリティは、同様の条件下で、キャッシュ制御ヘッダの「プライベート」または「無店舗」の句を含めることの欠如によって損なわれる可能性があります。

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.

簡単に正式なコピーを変更しながら傍受および明示モードの両方でプロキシを介してデータのエンドツーエンドのリロードを要求次いで、キャッシングプロキシ上の新鮮な（非期限切れ）コンテンツを配置することにより検出さ適応症。

Solution(s) Eliminate the need for interception proxies and IP spoofing, which will return correct context awareness to the client.

溶液（S）クライアントへの正しいコンテキストアウェアネスを返します傍受プロキシとIPスプーフィングの必要性をなくします。

Workaround Include relevant Cache-Control directives in every request at the cost of increased bandwidth and CPU requirements.

回避策は、高い帯域幅とCPUの要件を犠牲にし、すべての要求で関連のCache-Controlディレクティブを含めます。

Contact Patrick McManus <mcmanus@AppliedTheory.com>

連絡先パトリック・マクマナス<mcmanus@AppliedTheory.com>

2.2.2 Interception proxies prevent introduction of new HTTP methods

2.2.2迎撃プロキシは、新しいHTTPメソッドの導入を防ぎます

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.

それに対して未知の方法で要求を受信する説明Aプロキシは、応答として、HTTP 501エラーを生成する必要があります。 HTTPメソッドは、単にユーザーエージェントとオリジンサーバの初期サポートでデプロイされたアプリケーションがあるかもしれないので、拡張できるように設計されています。これらのメソッドを実装したサーバ宛ての新しいメソッドを含むリクエストをハイジャック傍受プロキシは何も意図していないことも事実上のファイアウォールを作成します。

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.

溶液（S）傍受プロキシの必要性を排除します。伝統的なHTTP環境で501を受信するクライアントは、直接、オリジンサーバに要求を繰り返すことを選択できるか、おそらく別のプロキシを使用するように設定すること。

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.

（時々、レベル7またはアプリケーションレイヤスイッチと呼ばれる）回避策レベル5のスイッチは、プロキシのうち、未知の方法で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)

連絡先パトリック・マクマナス<mcmanus@AppliedTheory.com>ヘンリック・ノードストローム<hno@hem.passagen.se>（HTTP / 1.1の明確化）

2.2.3 Interception proxies break IP address-based authentication

2.2.3迎撃プロキシは、IPアドレスベースの認証を破ります

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>

問い合わせキース・K.チャウ<keithc@unitechnetworks.com>

2.2.4 Caching proxy peer selection in heterogeneous networks

異種ネットワークにおける2.2.4キャッシングプロキシピア選択

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

300ミリ秒のレイテンシを持つ* SIB1にキャッシュCのリンク、2メガビット/秒

* Cache C's link to Sib2, 64 Kbit/sec with 10 msec latency.

SIB2へ*キャッシュCのリンク、10ミリ秒の待ち時間と64Kビット/秒。

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]このコンテキストではうまく動作しません。ユーザーがミスにつながるページP用のプロキシCにリクエストを送信した場合、Cは、SIB1及びSIB2にICP要求を送信します。両方の兄弟は、要求されたオブジェクトP.ザ・ICP_HIT応答が常にSIB1前SIB2から来る持っていると仮定します。しかし、大きなオブジェクトの検索がSIB1から、むしろSIB2よりも速くなることは明らかです。

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.

溶液（S）この問題は、ピア選択プロトコルと建築です。

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>

連絡先イヴァン・ラブリック<ivan.lovric@cnet.francetelecom.fr>ジョン・ディリー<jad@akamai.com>

2.2.5 ICP Performance

2.2.5 ICPパフォーマンス

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]、nは参加ピアプロキシの数であり、O（N ^ 2）スケーリング特性を示します。これは、ネットワーク内のHTTPトラフィックを支配するICPトラフィックを導くことができます。

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.

溶液（S）この問題は、建築である - プロトコルの再設計や交換はICPを使用することを続けるのであればそれを解決するために必要とされます。

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>

連絡先ジョン・ディリー<jad@akamai.com>

2.2.6 Caching proxy meshes can break HTTP serialization of content

2.2.6キャッシュプロキシメッシュは、コンテンツのHTTPの直列化を破ることができます

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.

ソリューション（s）はメッシュでプロキシ関係やオブジェクトの状態を維持するのに適したプロトコルを見つけるために、キャッシング・プロキシー・ベンダーや研究者と協力。

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>

連絡先ヘンリクノードストローム<hno@hem.passagen.se>

2.3 Known Implementation Problems

2.3既知の実装の問題

2.3.1 User agent/proxy failover

2.3.1ユーザー・エージェント/プロキシのフェイルオーバー

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]ファイルを使用して）ユーザエージェントでプロキシ間説明failoverは不安定であり、標準的な動作は定義されていません。プロキシ管理者が効果的にユーザーエージェントでフェイルオーバーを使用することはできませんように、また、動作は、ブラウザの中にハードコーディングされています。

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.

溶液（S）これらのタイムアウトの設定を可能にするJavaScriptはproxy.pacライブラリに標準拡張機能を確立するために、ブラウザのベンダーと協力。

Workaround User education; redundancy at the proxy level.

回避策ユーザー教育;プロキシレベルでの冗長性。

Contact Mark Nottingham <mnot@mnot.net>

コンタクトマーク・ノッティンガム<mnot@mnot.net>

2.3.2 Some servers send bad Content-Length headers for files that contain CR

一部のサーバーは、CRを含むファイルに悪いのContent-Lengthヘッダーを送信2.3.2

Name Some servers send bad Content-Length headers for files that contain CR

CRを含むファイルに悪いのContent-Lengthヘッダーを送信いくつかのサーバに名前を付けます

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文字を取り除き場合に発生します。サーバーはおそらく、Content-Lengthヘッダのファイルサイズを取得するためのstat（）システムコールを使用しています。この挙動を示すサーバーは、（少なくとも、バージョン2.14）GN Webサーバーが含まれています。

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接続を使用してのContent-Lengthを無視します。ファイルの文書の末尾にはTCPソケットの近くで識別されます。

Contact Duane Wessels <wessels@measurement-factory.com>

連絡先デュアン・ウェッセル<wessels@measurement-factory.com>

3. Security Considerations

3.セキュリティの考慮事項

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]パクソン、V.、オールマン、M.、ドーソン、S.、フェナー、W.、Griner、J.、天、I.、レイヒー、K.、Semke、J.およびB.フォルツ、「既知のTCP実装の問題」、RFC 2525、1999年3月。

[2] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.

[2]クーパー、I.、Melve、I.およびG.トムリンソン、 "インターネットの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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。

[4] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), Version 2", RFC 2186, September 1997.

[4]ウェッセル、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]デイヴィソン、B.、「Webトラフィックログ：評価のための不完全な資源」、インターネット協会の第九回全国大会（INET'99）、1999年7月の議事インチ

[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.とM. Arlett、 "PRO-COW：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]ネットスケープ社、「ナビゲータープロキシ自動設定ファイル形式」を、1996年3月、http://home.netscape.com/eng/mozilla/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]モーグル、J.、Krishnamurthy、B.、Douglis、F.、フェルドマン、A.、Goland、Y.、バンホフ、A.及びD. Hellerstein、 "HTTPでHTTPデルタ"、ProgressのWork。

Authors' Addresses

著者のアドレス

Ian Cooper Equinix, Inc. 2450 Bayshore Parkway Mountain View, CA 94043 USA

イアン・クーパーエクイニクス社2450ベイショアパークウェイマウンテンビュー、CA 94043 USA

Phone: +1 650 316 6065 EMail: icooper@equinix.com

電話：+1 650 316 6065 Eメール：icooper@equinix.com

John Dilley Akamai Technologies, Inc. 1400 Fashion Island Blvd Suite 703 San Mateo, CA 94404 USA

ジョン・ディリーアカマイ・テクノロジーズ株式会社1400ファッションアイランドブルバードスイート703サンマテオ、CA 94404 USA

Phone: +1 650 627 5244 EMail: jad@akamai.com

電話：+1 650 627 5244 Eメール：jad@akamai.com

Appendix A. Archived Known Problems

付録A.アーカイブ既知の問題

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.

以下のサブセクションでは、このメモの最初の生産で特定された問題のアーカイブです。これらは、典型的には、さらに仕事/研究、またはユーザー教育を必要とする問題です。これらは、参照のみを目的としてここに含まれています。

A.1 Architectural

建築A.1

A.1.1 Cannot specify multiple URIs for replicated resources

A.1.1は、複製されたリソースに対して複数のURIを指定することはできません

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が単一のリソース、リソースの各複製のための1つのために使用することができることを指定する方法はありません。同様に、（各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.

溶液（S）建築 - プロトコルの設計が必要です。

Workaround Replication mechanisms force users to locate a replica or mirror site for replicated content.

回避策レプリケーションメカニズムは、複製されたコンテンツのためのレプリカやミラーサイトを見つけるためにユーザーを強制します。

Contact Daniel LaLiberte <liberte@w3.org>

連絡先ダニエル・リベルテ<liberte@w3.org>

A.1.2 Replica distance is unknown

A.1.2レプリカ距離は不明です

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.

回避策サーバーが（多くはない）レプリカ選択ウェブページ内の場所のヒントを提供することができます。ユーザーは、自分の場所に基づいて1つを選択してください。ユーザーは彼らに最高のパフォーマンスを与えるレプリカサーバーを学ぶことができます。最も近いレプリカが地理的にネットワークトポロジーの面で必ずしも最も近いではないことに注意してください。ユーザーがネットワークトポロジを理解するために期待することは無理です。

Contact Daniel LaLiberte <liberte@w3.org>

連絡先ダニエル・リベルテ<liberte@w3.org>

A.1.3 Proxy resource location

A.1.3 Proxyリソースの場所

Name Proxy resource location

Proxyリソースの場所に名前を付けます

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.

溶液（S）建築 - プロトコルの設計が必要です。

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).)

その内容（例えば、イカ）の要約ダイジェストの形でこの問題を回避する特定のプロキシ共有の場所のヒント。特定のプロキシプロトコルは、その内容（例えば、ICP）用に別のプロキシクエリを可能にします。（但し、 "ICPパフォーマンス" 問題（セクション2.2.5）を参照してください。）

Contact Daniel LaLiberte <liberte@w3.org>

連絡先ダニエル・リベルテ<liberte@w3.org>

A.2 Implementation

A.2実装

A.2.1 Use of Cache-Control headers

Cache-ControlヘッダのA.2.1使用

Name Use of Cache-Control headers

Cache-Controlヘッダの名前を使用します

Classification Implementation

分類の実装

Description Many (if not most) implementations incorrectly interpret Cache-Control response headers.

説明多くの（そうでない場合は、ほとんど）の実装は間違ってのCache-Controlレスポンスヘッダを解釈します。

Significance High

ハイ意義

Implications Cache-Control headers will be spurned by end users if there are conflicting or non-standard implementations.

競合または非標準実装があるかどうかの示唆のCache-Controlヘッダは、エンドユーザーによってはねつけされます。

Indications -

適応症 -

Solution(s) Work with vendors and others to assure proper application

ソリューション（s）は、適切なアプリケーションを確保するために、ベンダーや他の人と協力

Workaround None.

回避策なし。

Contact Mark Nottingham <mnot@mnot.net>

コンタクトマーク・ノッティンガム<mnot@mnot.net>

A.2.2 Lack of HTTP/1.1 compliance for caching proxies

キャッシングプロキシのHTTP / 1.1準拠のA.2.2欠如

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研究所との共同技術レポートは、[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.

溶液（S）のテストを開始すべきであるとのオープンな業界フォーラムで報告します。プロキシ実装が仕様に準拠している必要があります。

Workaround There is no workaround for non-compliance.

回避策非遵守のための回避策はありません。

Contact Mark Nottingham <mnot@mnot.net> Duane Wessels <wessels@measurement-factory.com>

コンタクトマーク・ノッティンガム<mnot@mnot.net>デュアン・ウェッセル<wessels@measurement-factory.com>

A.2.3 ETag support

A.2.3のETagのサポート

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.

インプリケーション/最終-Modifiedの場合 - 変更-ので検証は、両方とも、その弱さと日付のその使用の多くの要件には不適切です。使用可能な、強力なコヒーレンシ・プロトコルの欠如は、キャッシュを信頼していない開発者やエンドユーザーをリードしています。

Indications -

適応症 -

Solution(s) Work with vendors to implement ETags; work for better validation protocols.

溶液（S）てETagを実装するためにベンダーと協力し、より良いバリデーションプロトコルのために働きます。

Workaround Use Last-Modified/If-Modified-Since validation.

回避策のLast-Modified /場合 - 変更-ので検証。

Contact Mark Nottingham <mnot@mnot.net>

コンタクトマーク・ノッティンガム<mnot@mnot.net>

A.2.4 Servers and content should be optimized for caching

A.2.4サーバーとコンテンツをキャッシュするために最適化されなければなりません

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.

キャッシュの貧しい利用することによって意味合いは、オリジンサーバは、キャッシングプロキシに大きな負荷を長いロード時間を奨励し、ネットワークの需要が増加しました。

Indications The problem is most apparent for pages that have low or zero expires time, yet do not change.

適応症の問題は時間が満了し、低またはゼロを持っているページの最も明白である、まだ変更されません。

Solution(s) -

溶液（A） -

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

連絡先ピーター・ダンツィヒ

A.3 Administration

A.3管理

A.3.1 Lack of fine-grained, standardized hierarchy controls

きめの細かい、標準化された階層コントロールのA.3.1欠如

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) -

溶液（A） -

Workaround Work with vendors to establish an acceptable configuration within the limits of their product; standardize on one product.

彼らの製品の範囲内で許容可能な構成を確立するために、ベンダーと回避策作業。一つの製品を標準化。

Contact Mark Nottingham <mnot@mnot.net>

コンタクトマーク・ノッティンガム<mnot@mnot.net>

A.3.2 Proxy/Server exhaustive log format standard for analysis

分析のためA.3.2プロキシ/サーバ網羅ログフォーマットの標準

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.)

溶液（S）適切にきれいにかつ正確に応答のキャッシュ可能性を決定するために、完全なログが[クモの除去のために全てのリクエストヘッダならびに「ユーザエージェント」としてすべての応答ヘッダを含む（必要とされ、「有効期限」、「最大エージング」、『セットクッキー』、『キャッシュなし』など）

Workaround -

回避策 -

References See "Web Traffic Logs: An Imperfect Resource for Evaluation"[5] for some discussion of this.

[5]このいくつかの議論のために：参照は、「評価のための不完全なリソースのWebトラフィックログ」を参照してください。

Contact Brian D. Davison <davison@acm.org> Terence Kelly <tpkelly@eecs.umich.edu>

問い合わせブライアンD.デイヴィソン<davison@acm.org>テレンス・ケリー<tpkelly@eecs.umich.edu>

A.3.3 Trace log timestamps

A.3.3トレースログのタイムスタンプ

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.

含意特性評価およびシミュレーション忠実度は、正確なタイミングと順序の情報が改善されています。ログは、一般的に要求の完了のために書かれているので、これらのログは、要求発生時刻を知り、それに応じて並べ替えずに再再生することはできません。