RFC3143 日本語訳
3143 Known HTTP Proxy/Caching Problems. I. Cooper, J. Dilley. June 2001. (Format: TXT=57117 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group I. Cooper
Request for Comments: 3143 Equinix, Inc.
Category: Informational J. Dilley
Akamai Technologies, Inc.
June 2001
コメントを求めるワーキンググループI.桶屋要求をネットワークでつないでください: 3143年のEquinix Inc.カテゴリ: 情報のJ.Dilleyアカマイ・テクノロジーズInc.2001年6月
Known HTTP Proxy/Caching Problems
知られているHTTPプロキシ/キャッシュ問題
Status of this Memo
この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)インターネット協会(2001)。 All rights reserved。
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.
このドキュメントはWWW(WWW)(キャッシュする)プロキシとキャッシュサーバの多くの既知の問題をカタログに載せます。 ドキュメントの目標は、問題と提案された次善策の議論を提供して、問題を例証することによって結局状態を改良することです。このドキュメントの構造は共同体をキャッシュするウェブの共同努力です。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 1.1問題テンプレート. . . . . . . . . . . . . . . . . . . . . . 2 2。 知られているProblems. . . . . . . . . . . . . . . . . . . . . . . 4 2.1Known Specification Problems. . . . . . . . . . . . . . . . 5 2.1.1Varyヘッダーは、underspecifiedされる、そして/または、.52.1の.2のClient Chaining Loses Valuable Length Meta-データをミスリードしています…; .92.2知られているArchitectural Problems. . . . . . . . . . . . . . . . 10 2.2.1のInterceptionプロキシがクライアントキャッシュ指示を壊す、.102.2、.2のInterceptionプロキシ、新しいHTTP方法の導入を防いでください…; . . . 11 2.2.3 .152.2個の.6Cachingプロキシメッシュが.172.3の.2Someサーバが悪いContent-長さのヘッダーに送る満足している16 2.3Known Implementation Problems. . . . . . . . . . . . . . . 17 2.3.1Userエージェント/プロキシフェイルオーバーのHTTP連載を壊すことができる異機種ネットワーク. . . 13 2.2.5ICPパフォーマンスにおけるIPのアドレスベースの認証. 12 2.2.4Cachingプロキシ同輩選択がそれをファイルする妨害プロキシ休み中はCRを含んでいます… . . . . . . . . . . . . . . . . . . 18
Cooper & Dilley Informational [Page 1] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[1ページ]のRFC3143
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
3. セキュリティ問題. . . . . . . . . . . . . . . . . . 18参照. . . . . . . . . . . . . . . . . . . . . . . . . 19作者のアドレス. . . . . . . . . . . . . . . . . . . . . 20A.は既知の問題. . . . . . . . . . . . . . . . . . 21Aを格納しました; 建築.21A.1.1 Cannotは模写されたリソース. . . 21に複数のURIを指定します。1 A.1.2 Replica距離は未知の.22A.1.3 Proxyリソース位置です…; .23 .26にきめ細かに粒状の、そして、標準化された階級制御. . . 27A.3.2 ProxのA.3政権.27A.3.1 Lackをキャッシュするプロキシ. . . . . . 24A.2.3 ETagサポート. . . . . . . . . . . . . . . . . . . . . . . . 25A.2.4 ServersをキャッシュするためのHTTP/1.1コンプライアンスと内容の.23A.2.2 Lackが最適化されるべきであるCache-コントロールヘッダーのA.2実現.23A.2.1 Useログ概要. . . . . . . . . . . . . 29Full Copyright Statement. . . . . . . . . . . . . . . . . . 32のための.27の分析A.3.3 Traceログタイムスタンプ. . . . . . . . . . . . . . . . . . . . 28A.3.4 Exchange形式のy/サーバの徹底的なログ形式規格
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].
このメモは、局所的に内容に役立つことによって、プロキシと、より明確にプロキシをキャッシュするのに総合的なサービスの質と問題について議論します。(プロキシはウェブ要求のためのアプリケーションレベル仲介者として務めます)。プロキシは向上を希望して以前に要求されたリソースのコピーを保有します。 「インターネットウェブ模写とキャッシュ分類学」[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.
どんな個人も組織も、ウェブキャッシュにおける既知の問題に関する完全な知識がありません、そして、エディタはこのドキュメントへの寄稿者に感謝しています。
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 単語)分類の短くて、描写的である名前: 問題を分類します: 性能、セキュリティ、など記述: 簡潔に問題について説明する、Significance: 問題の大きさ、それが存在する環境、Implications: システムとネットワークSee Alsoの上の問題の影響: 関連する既知の問題Indicationsの参照: この問題の存在を検出する方法を述べます。
Cooper & Dilley Informational [Page 2] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[2ページ]のRFC3143
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): あらゆるWorkaroundであるならこの問題の解決について説明してください: 問題Referencesのための実用的な次善策: 問題の情報か解決策Contact: このセクションに名前とEメールアドレスに連絡してください。
Name
A short, descriptive, name (3-5 words) name associated with the
problem.
問題に関連している短くて、描写的である名前(3-5 単語)名とAを命名してください。
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.
分類Problemsはこのメモを読む容易さのために同様の問題のカテゴリに分類されます。 問題について最もよく説明するカテゴリを選んでください。 提案されたカテゴリは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.
* 政権: キャッシュの注意と摂食はそうであるか原因、aが問題です。
* Security: privacy, integrity, or authentication concerns.
* セキュリティ: プライバシー、保全、または認証関心。
Description
A definition of the problem, succinct but including necessary
background information.
問題の記述A定義、簡潔な、しかし、包含必要な基礎的な情報。
Significance (High, Medium, Low)
May include a brief summary of the environments for which the
problem is significant.
意味(高値、Medium、Low)は問題が重要である環境の簡潔な概要を含むかもしれません。
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.
問題が問題として見なされるという含意Why。 どんな不適当行動がそれから生じますか? このセクションはHigh意味で示されたどんな問題の大きさも実体化するべきです。
See Also
Optional. List of other known problems that are related to this
one.
また、任意の状態で、見てください。 これに関連する他の既知の問題のリスト。
Cooper & Dilley Informational [Page 3] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[3ページ]のRFC3143
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.
問題の存在を検出する指摘How。 これは、問題を示すドキュメントを実体化しながら、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.
そのようなものが知られているなら永久に問題を修正するソリューションソリューション。 例えば、ソフトウェアのどんなバージョンが問題を示しませんか? 解決策が共同体か、協定までいくつかの解決策、またはことによると実験解決策がある戸外の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.
次善策Practical次善策は、解決策でないなら利用可能であるか、または使用可能です。 次善策には、問題を経験するだれかへのそれを動くことができるくらいの詳細があるべきです。
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?
技術的な刊行物かウェブの関連する情報への参照References。 この問題、解決策、または次善策がさらに見つけられにもう少し学ぶのに関心があるだれかがどこに行くことができますか?
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.
このセクションのための情報を提供した人のContact名とEメールアドレスに連絡してください。 エディタは匿名の差出に関する接触として記載されています。
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.
このドキュメントの残っているセクションは現在記録された既知の問題を提示します。問題は分類と意味によって注文されます。 プロトコル仕様か構造の問題は導入問題がいうことになった1番目です。 高い意味の問題は低い意味がいうことになった1番目です。
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.
彼らが決議が主としてプロトコル仕事よりむしろ教育にかかわる問題について議論するので、初めはこのドキュメントの旧バージョンで特定される問題のいくつかがAppendix Aに動かされました。
A full list of the problems is available in the table of contents.
問題の完全リストは目次で利用可能です。
Cooper & Dilley Informational [Page 4] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[4ページ]のRFC3143
2.1 Known Specification Problems
2.1 知られている仕様問題
2.1.1 Vary header is underspecified and/or misleading
2.1.1 underspecifiedされる、そして/または、ミスリードして、ヘッダーを変えてください。
Name
The "Vary" header is underspecified and/or misleading
「異なってください」というヘッダーがunderspecifiedされる、そして/または、ミスリードしている名前
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ヘッダーが設計された記述で、異形のサーバの選択が完全にさえ理解されていないなら、キャッシュしているプロキシは安全に応答をキャッシュできます。 RFC2616が言うように:
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.
サーバがサーバ駆動の交渉を受けることがある表現を選択するのに使用するパラメタを言い表すのにVaryヘッダーフィールドを使用できます。
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.
仕様[9]をコード化するHTTPデルタのデザインの間、それがするHTTP/1.1プロキシが、デルタコード化がデルタでコード化された応答をキャッシュして、次に、後でできる非デルタクライアントにそれを届けるかもしれないのを理解していないと実感されました、拡大がこれを防ぐために何らかのメカニズムを含んでいなかったなら。 初めは、Varyが十分であると思われましたが、以下のシナリオは、これが間違っていると立証します。
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. 「例の操作」の概念は紹介されます。 ある点では、これは内容コード化と同様ですが、違いがあります。 例の操作名に関する1つの例が"vcdiff"です。
2. A client signals its willingness to accept one or more
instance-manipulations using the A-IM header.
2. クライアントはA-IMヘッダーを使用することで1つ以上の例操作を受け入れる意欲に合図します。
Cooper & Dilley Informational [Page 5] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[5ページ]のRFC3143
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ステータスコードを使用させます。
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応答の代わりにデルタコード化を使用することで変更のコンパクトなコード化を伝えるかもしれません。 デルタencodingsを支持しない実現にコード化された応答を解釈できません。
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
http://example.com/foo.html HTTP/1.1ホストを手に入れてください: なにも合わせないexample.com If: "abc"、-、不-、: 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は不-Etagを使用しました: 「クールな」日付: グリニッジ標準時2000年4月19日水曜日18時46分13秒、不-、: vcdiff Cache-コントロール: 60最大歳Vary: -、不-、なにも合っていません。
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"例と、「クールな」例の違いをコード化する)です。 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ヘッダーへの仕様通りに
Cooper & Dilley Informational [Page 6] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[6ページ]のRFC3143
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.
Vary分野価値はそれが完全に決定する要求ヘッダーフィールドのセットを示します、応答が新鮮ですが、キャッシュが再合法化なしでその後の要求に答えるのに応答を使用することが許可されているか否かに関係なく。
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 WITH"再合法化"に対応して格納された応答を使用できるでしょう。 これは潜在的バグです。
An obvious implementation of the proxy would send this request to
test whether its cache entry is fresh (i.e., to revalidate the
entry):
プロキシの明白な実現はキャッシュエントリーが新鮮であるか否かに関係なく、テストするというこの要求(すなわち、revalidateへのエントリー)を送るでしょう:
GET /foo.html HTTP/1.1
Host: example.com
If-None-Match: "def"
foo.html HTTP/1.1が接待する/を手に入れてください: なにも合わせないexample.com If: 「クールです」。
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ヘッダーを付加した後に。
If the origin server's Etag for the current instance is still
"def", it would naturally respond:
現在の例のための起源サーバのEtagがまだ「クールである」なら、自然に応じるでしょう:
HTTP/1.1 304 Not Modified
Etag: "def"
Date: Wed, 19 Apr 2000 18:46:14 GMT
HTTP/1.1 304はEtagを変更しませんでした: 「クールな」日付: グリニッジ標準時2000年4月19日水曜日18時46分14秒
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:
1つは、プロキシ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
キャッシュ制御指示か明らかにそれを許容する別のヘッダーがない場合、回答でいずれ[200、203、206、300、301または410以外のステータスコード]でも受けられた応答をその後の要求に返してはいけません。 例えば、これら
Cooper & Dilley Informational [Page 7] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[7ページ]のRFC3143
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).
以下を含めてください: Expiresヘッダー(セクション14.21)。 「最大時代」、"s-maxage"「必須revalidateである」か、「プロキシrevalidateである」か、「公共」の、または、「個人的な」キャッシュ制御指示(セクション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-コントロール指示を運びます。 それで、私たちが、この種類の拡大を実行するサーバが全くこれらのCache-コントロール指示を使用するのを禁止しないと、Varyヘッダーはただ働かないでしょう。
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へのもっともらしい拡大が議定書の中で述べる含意Certainは、より古いHTTP/1.1のキャッシュで正しく共同利用しないかもしれません、拡大がキャッシュimplementerによって使用される同じくらいではなく、そうするVaryの解釈によるなら。
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.
これには、デバッグしにくいキャッシュ透明失敗を引き起こすか、そのような拡大の展開に水をさしているか、またはそのような拡大のimplementersがキャッシュを完全に無能にするよう奨励するという効果があるでしょう。
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)
ソリューション(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を変えるべきです、それらがExpiresヘッダーと同様のものを含んでいるか否かに関係なく。 (今後の拡大の余地を新しいステータスコードに預けて、何が手段を「理解しているか」を定義するのが何らかの注意を必要とするかもしれません。) 振舞いは、この場合「以下をキャッシュで制御する」ために同じくらい同等な状態で定義される必要があります。 後者以来の「キャッシュがありません」よりむしろ「店がありません」は再合法化を許します。
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.
ことによるとVaryの仕様は、「以下をキャッシュで制御する」ときそれが扱われるのを必要とするべきです。 ステータスコードは未知です--それがここで与えられたシナリオの問題を解決するべきであるときはいつも、「格納しません」。
Cooper & Dilley Informational [Page 8] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[8ページ]のRFC3143
2. Designers of HTTP/1.1 extensions should consider using
mechanisms other than Vary to prevent false caching.
2. HTTP/1.1の拡大のデザイナーは、誤ったキャッシュを防ぐのにVary以外のメカニズムを使用すると考えるべきです。
It is not clear whether the Vary mechanism is widely
implemented in caches; if not, this favors solution #1.
Varyメカニズムがキャッシュで広く実行されるかどうかは、明確ではありません。 そうでなければ、これは解決策#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).
次善策Aキャッシュがa応答における、Varyヘッダーの存在を扱うかもしれない、暗黙、「キャッシュ制御:」 これはRFC2616によって必要とされませんが、「知られている」ステータスコード以外に、「格納しません」。 これはどんな透明失敗も避けるでしょう。 たぶん基本的な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."
拡大をコード化するデルタの仕様、および「異なってください」の代わりにCache-コントロール拡張子の使用に関する例のための参照See[9]。
Contact
Jeff Mogul <mogul@pa.dec.com>
ジェフ Mogul <mogul@pa.dec.com に連絡してください、gt。
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]実現は身体がコード化されたTransferであるどんなメッセージでもContent長さのヘッダーを送るのが禁止されています。 1.0人のクライアントがchunked Transfer- Encodingsを受け入れることができないので、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.
プロキシがどうメッセージ本体を進めなければならないようにchunked転送コード化かContent-長さの指示が否定的性能含意を作成するかという含意Lacking。
Cooper & Dilley Informational [Page 9] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[9ページ]のRFC3143
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.
応答本体の場合では、サーバは、応答の終わりを示すために接続を終えている間、応答を進めなければならないかもしれないか、またはContent-長さについて計算して、全体の応答をバッファリングするのに店と急進的な意味論を利用しなければなりません。 前のオプションはいくつかのあいまいにlengthedされた応答を作成することと同様にHTTP/1.1(そして、HTTP/1.0における彼らの生きているKeepいとこ)における、パーシステントコネクションの性能利益を破ります。 リソースのサイズを考えて、後者の店と前進のオプションは可能でさえないかもしれません、そして、それはいつも増加する潜在を導入するでしょう。
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-長さのヘッダーがボディーを区切らなければならないよう要求するときボディーが店と前進の過程を引き受けなければならないよう要求してください。 これが応答本体を置いているかもしれないなら、プロキシと要求の容認できないリソース規制は満足することができないかもしれません。
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.
運ばれるべき起源知られているアイデンティティドキュメントのContent-長さの終わりがそうするHTTP仕様明確化で終わらせることができるソリューションはこの問題を軽減するでしょう。
Workaround
None.
次善策、なし。
Contact
Patrick McManus <mcmanus@AppliedTheory.com>
パトリック McManus <mcmanus@AppliedTheory.com に連絡してください、gt。
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
名前Interceptionプロキシはクライアントキャッシュ指示を壊します。
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
それが起源サーバ、または、プロキシに接されるなら、記述HTTP[3]は、ユーザエージェントが意識しているように設計されます。 彼らが起源サーバで商取引していると信じているそうするユーザエージェント
Cooper & Dilley Informational [Page 10] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[10ページ]のRFC3143
really in a connection with an interception proxy may fail to send
critical cache-control information they would have otherwise
included in their request.
本当に、妨害プロキシとの接続では、そうでなければそれらが彼らの要求に含んだ批判的なキャッシュ制御情報を送らないかもしれません。
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.
含意Clientsは終わらせる終わりがリフレッシュするよう要求する場合、起源に連動してさえいません、aの包含の不足による、「キャッシュで制御してください」ということであるデータを受け取るかもしれません。 「いいえキャッシュ」か「必須revalidate」ヘッダー。 これらのヘッダーが起源サーバの振舞いに変化も与えないので、そのリソースに関連づけられると信じているなら、ブラウザによって入れられないかもしれません。 また、他の関連するデータ含意は可能です。 例えば、データ機密保護は、「個人的」の包含の不足で妥協するか、またはCache-コントロールヘッダーの節を類縁疾患の下に「格納しないかもしれません」。
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.
正式のコピーを変えている間、新鮮な(満期になっていない)内容をキャッシュしているプロキシに置いて、次に、妨害と明白なモードの両方のプロキシを通して終わりから終わりへのデータの再ロードを要求することによって検出された指摘Easily。
Solution(s)
Eliminate the need for interception proxies and IP spoofing, which
will return correct context awareness to the client.
ソリューションは妨害プロキシとIPスプーフィングの必要性を排除します。(IPスプーフィングは正しい文脈認識をクライアントに返すでしょう)。
Workaround
Include relevant Cache-Control directives in every request at the
cost of increased bandwidth and CPU requirements.
増加する帯域幅とCPU要件の費用におけるあらゆる要求における次善策のIncludeの関連Cache-コントロール指示。
Contact
Patrick McManus <mcmanus@AppliedTheory.com>
パトリック McManus <mcmanus@AppliedTheory.com に連絡してください、gt。
2.2.2 Interception proxies prevent introduction of new HTTP methods
2.2.2 妨害プロキシは新しいHTTP方法の導入を防ぎます。
Name
Interception proxies prevent introduction of new HTTP methods
名前Interceptionプロキシは新しい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
それにおける、未知の方法で要求を受け取る記述Aプロキシは応答としてHTTP501Errorを発生させなければなりません。 HTTP方法が広げることができるように設計されているので、まさしくユーザエージェントと起源の初期のサポートで配備された利用があるかもしれません。
Cooper & Dilley Informational [Page 11] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[11ページ]のRFC3143
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.
サーバそれらの方法を実行したサーバのために運命づけられた新しい方法を含んでいる要求をハイジャックする妨害プロキシはなにも意図しないかもしれないデファクトファイアウォールを作成します。
Significance
Medium within interception proxy environments.
妨害プロキシ環境の中の意味Medium。
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.
含意Renders新しい対応するアプリケーション、役に立たなさ、変更をプロキシソフトウェアにしない場合。 新しいメソッドはグローバルに標準化されるのに必要でないので、それは一般的な場合で時代について行かせるのが不可能です。
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を受け取るクライアントは、直接発生源サーバに要求を繰り返すのを選ぶか、または異なったプロキシを使用するために恐らく構成されるかもしれません。
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.
未知のメソッドがあるHTTPトラフィックをプロキシに入れないようにするのに、Level5が切り換える(Level7か応用層を時々スイッチと呼びます)回避策を使用できます。 しかしながら、これらのデバイスは、重いバッファリング責任を持って、まだ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バージョンで要求を受け取るとき、HTTP/1.1仕様で、転換するプロキシはモードにトンネルを堀ることができます。
Contact
Patrick McManus <mcmanus@AppliedTheory.com>
Henrik Nordstrom <hno@hem.passagen.se> (HTTP/1.1 clarification)
パトリック McManus <mcmanus@AppliedTheory.com に連絡してください、gt;、Henrik Nordstrom <hno@hem.passagen.se 、gt。(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
名前Interceptionプロキシは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
パブリックアクセスにおいて、記述Someウェブサーバーは開いていませんが、自分たちを制限して、ある一定のIPアドレスの範囲から要求だけを安全保障上の理由で受け入れてください。 妨害プロキシはソース(クライアント)IPアドレスをプロキシ自体のものに変更します。
Cooper & Dilley Informational [Page 12] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[12ページ]のRFC3143
knowledge of the client/user. This breaks such authentication
mechanisms and prohibits otherwise allowed clients access to the
servers.
クライアント/ユーザに関する知識。 そのような認証機構を壊します。そうでなければ、これは、サーバへの許容クライアントアクセスを禁止します。
Significance
Medium
意味媒体
Implications
Creates end user confusion and frustration.
含意Createsエンドユーザ混乱とフラストレーション。
Indications
Users may start to see refused connections to servers after
interception proxies are deployed.
指摘Usersは、妨害プロキシが配布された後に拒否された接続にサーバに会い始めるかもしれません。
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は切り替わる)と迂回の回避策Using IPフィルタ。
Contact
Keith K. Chau <keithc@unitechnetworks.com>
キースK. Chau <keithc@unitechnetworks.com に連絡してください、gt。
2.2.4 Caching proxy peer selection in heterogeneous networks
2.2.4 異機種ネットワークでプロキシ同輩選択をキャッシュすること。
Name
Caching proxy peer selection in heterogeneous networks
異機種ネットワークにおける名前Cachingプロキシ同輩選択
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、および以下のネットワーク形態(まとめられる)でProxyにCを取ってください。
* Cache C's link to Sib1, 2 Mbit/sec with 300 msec latency
* Sib1へのキャッシュCのリンク、300msec潜在がある2メガビット/秒
* Cache C's link to Sib2, 64 Kbit/sec with 10 msec latency.
* 10msec潜在でSib2へのCのリンク、64キロビット/秒をキャッシュしてください。
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
ICP[4]はこのような関係においてはうまくいきません。 ユーザがミスをもたらすページPのためにProxy Cに要求を提出すると、CはICP要求をSib1とSib2に送るでしょう。 両方の兄弟が持っていると仮定してください。
Cooper & Dilley Informational [Page 13] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[13ページ]のRFC3143
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.
要求されたオブジェクトP.はSib1の前でSib2からいつも来るでしょうICP_HITが、返答する。 しかしながら、大きいオブジェクトの検索が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.
含意Byが応じる最初の同輩を使用して、同輩選択アルゴリズムはエンドユーザへの検索潜在を最適化しないことです。 その上、それらは、そのような要求に応じなければならないので高潜在同輩のために、より多くの仕事を引き起こしていますが、下側の潜在同輩にコピーがあると、内容に役立つように決して選ばれないでしょう。
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、およびどんなキャッシュのデザインにおける指摘Inherentも最初に、応答に基づく同輩を選ぶプロトコルを網の目にかけます。
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.
そのようなプロトコルを使用するとき、同輩の中に高い潜在変化がないような方法で回避策Cacheメッシュデザインをするべきです。 上の記述で提示された例では、高い潜在高帯域同輩は親として使用できましたが、兄弟として使用するべきではありません。
Contact
Ivan Lovric <ivan.lovric@cnet.francetelecom.fr>
John Dilley <jad@akamai.com>
イワン Lovric <ivan.lovric@cnet.francetelecom.fr に連絡してください、gt;、ジョンDilley<jad@akamai.com>。
Cooper & Dilley Informational [Page 14] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[14ページ]のRFC3143
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]は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同輩のためにあるという含意Ifは過度である場合があります。 システム・マネージャは慎重にICPのじっと見ることを規制しなければなりません。 また、ICPは、プロキシが彼らが役立つことで均質になるように導きます。 あなたのプロキシにドキュメントがないなら、あなたの同輩にはそれがあるのは、ありそうもないです。 したがって、ICPトラフィック要求は主にオブジェクトの地方のコピーの場所を見つけることができません。([6])を見てください。
Indications
Inherent in design of ICP v1, ICP v2.
ICP v1、ICP v2のデザインにおける指摘Inherent。
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.
回避策Implementation回避策は存在していて、利用可能であるなら、例えばICPの使用をオフにするか、慎重にじっと見ることを規制するか、または別のメカニズムを使用するために、キャッシュとしてのそのようなものは読みこなされます。 キャッシュダイジェストプロトコルは、ブルームFilterのテクニックを使用することでキャッシュコンテンツの概要を共有します。 これは、同輩にドキュメントがあるか否かに関係なく、見積もるためにキャッシュを許容します。 フィルタが定期的にアップデートしますが、いつも最新であるというわけではないので、人気の急上昇は起こらざるを得ません。 それらは、また、トラフィックを増強しますが、ICP増強するというわけではありません。
Proxy clustering protocols organize proxies into a mesh provide
another alternative solution. There is ongoing research on this
topic.
プロキシクラスタリングプロトコルはメッシュが別の代替の解決法を提供するaにプロキシを組織化します。 この話題の継続中の研究があります。
Contact
John Dilley <jad@akamai.com>
ジョン Dilley <jad@akamai.com に連絡してください、gt。
Cooper & Dilley Informational [Page 15] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[15ページ]のRFC3143
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
名前Cachingプロキシメッシュは内容の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.
メッシュと関連キャッシュの状態によって、要求が異なった経路を旅行するかもしれないプロキシメッシュをキャッシュする記述Aは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.
含意Canはエンドユーザに混乱を引き起こします。 新しい内容でキャッシュを適切にアップデートさせるのが不可能な状態で状況(兄弟キャッシュヒット、オブジェクトは状態を「キャッシュ-可能」から「非-キャッシュ-可能」に変えた)の近くあるいくつかでそうするかもしれません。
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.
回避策Whenが階層構造/メッシュを設計して、そこでのそれぞれの終わりのユーザ/URL組み合わせのためのそれが通常の操作の間のメッシュの1つのただ一つの経路にすぎないことを確実にしてください。
Contact
Henrik Nordstrom <hno@hem.passagen.se>
Henrik Nordstrom <hno@hem.passagen.se に連絡してください、gt。
Cooper & Dilley Informational [Page 16] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[16ページ]のRFC3143
2.3 Known Implementation Problems
2.3 知られている実装問題
2.3.1 User agent/proxy failover
2.3.1 ユーザエージェント/プロキシフェイルオーバー
Name
User agent/proxy failover
名前Userエージェント/プロキシフェイルオーバー
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.
含意Architectsはプロキシ自体でやむを得ずフェイルオーバーを実装します、ユーザエージェントの中でそれをするのが、より適切であって、経済的であるときに。
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.
プライマリプロキシが下がっているというブラウザが検出する指摘If、それは使用するのが構成されている次のものを試みる数分前の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.
回避策User教育。 プロキシレベルにおける冗長。
Contact
Mark Nottingham <mnot@mnot.net>
マーク Nottingham <mnot@mnot.net に連絡してください、gt。
Cooper & Dilley Informational [Page 17] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[17ページ]のRFC3143
2.3.2 Some servers send bad Content-Length headers for files that
contain CR
2.3.2 いくつかのサーバがCRを入れてあるファイルのために悪いContent-長さのヘッダーを送ります。
Name
Some servers send bad Content-Length headers for files that
contain CR
名前SomeサーバはCRを入れてあるファイルのために悪いContent-長さのヘッダーを送ります。
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).
記述CertainウェブサーバーはHTTPメッセージ本体では、バイト数より大きいContent-長さの値を送ります。 サーバがファイルが書かれているときCRLFと共に終えられた系列があるテキストファイルからクライアントまでCRキャラクタを全部はぎ取るとき、これは起こります。 サーバは、Content-長さのヘッダーにファイルサイズを届けるのにたぶんstat()システムコールを使用します。 この振舞いを示すサーバがGNウェブサーバ(少なくともバージョン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.
含意は部分応答を受けましたIn本件、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.
メッセージのバイト数がContent-長さの値と具体化して、比較する指摘Count。 彼らが異なるなら、サーバはこの問題を示します。
Solutions
Upgrade or replace the buggy server.
または、ソリューションUpgrade、バギーのサーバを取り替えてください。
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.
回避策Someブラウザとプロキシは、1オブジェクトあたり1つのTCP接続を使用して、Content-長さを無視します。 ファイルの終りを記録してください。TCPソケットの閉鎖で、特定されます。
Contact
Duane Wessels <wessels@measurement-factory.com>
ドウェイン Wessels <wessels@measurement-factory.com に連絡してください、gt。
3. Security Considerations
3. セキュリティ問題
This memo does not raise security considerations in itself. See the individual submissions for details of security concerns and issues.
このメモは本来セキュリティ問題を提起しません。 安全上の配慮と問題の詳細のための個々の差出を見てください。
Cooper & Dilley Informational [Page 18] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[18ページ]のRFC3143
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実装問題」、RFC2525、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.トムリンスン、「インターネットウェブ模写、分類学をキャッシュする」、RFC3040、1月2001日
[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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[4] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
Version 2", RFC 2186, September 1997.
[4] ウェセルズとD.とK.Claffy、「インターネットキャッシュプロトコル(ICP)、バージョン2インチ、RFC2186、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.、「ウェブ・トラフィックは以下を登録します」。 1999'年7月のインターネット協会(INET'99)の第9年次大会の議事における「評価のための不完全なリソース。」
[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.、ワークショップ、1998年6月、<http://wwwcache.ja.net/イベント/ワークショップ/29/magicnumber.html>をキャッシュする第3国際WWWの議事における「関係分析、キャッシュメッシュ。」
[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、「親牛:」 「ウェブにおけるプロトコルコンプライアンス」、AT&T研究室技術報告書#990803-05-TM、1999年8月、<http://www.research.att.com/~bala/書類/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.、「ナビゲータプロキシ自動コンフィグファイル形式」、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.、ホフとA.とD.Hellerstein、「HTTPにおけるHTTPデルタ」をGoland(Y.)はバンに積みます、ProgressのWork。
Cooper & Dilley Informational [Page 19] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[19ページ]のRFC3143
Authors' Addresses
作者のアドレス
Ian Cooper Equinix, Inc. 2450 Bayshore Parkway Mountain View, CA 94043 USA
イアン桶屋Equinix Inc.2450Bayshore Parkwayカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650 316 6065 EMail: icooper@equinix.com
以下に電話をしてください。 +1 6065年の650 316メール: icooper@equinix.com
John Dilley Akamai Technologies, Inc. 1400 Fashion Island Blvd Suite 703 San Mateo, CA 94404 USA
ジョンDilleyアカマイ・テクノロジーズInc.1400ファッション島のBlvd Suite703カリフォルニア94404サン・マテオ(米国)
Phone: +1 650 627 5244 EMail: jad@akamai.com
以下に電話をしてください。 +1 5244年の650 627メール: jad@akamai.com
Cooper & Dilley Informational [Page 20] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[20ページ]のRFC3143
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
名前Cannotは模写されたリソースに複数の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.
記述Thereは複数の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.
模写を理解するユーザがモデル化するという含意Forcesとメカニズム。 模写と命名のプロトコルサポートなしで模写フレームワークを作成するのを難しくします。
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.
回避策Replicationメカニズムによって、ユーザはやむを得ず模写された内容のためのレプリカかミラーサイトの場所を見つけます。
Contact
Daniel LaLiberte <liberte@w3.org>
ダニエル LaLiberte <liberte@w3.org に連絡してください、gt。
Cooper & Dilley Informational [Page 21] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[21ページ]のRFC3143
A.1.2 Replica distance is unknown
A.1.2レプリカ距離は未知です。
Name
Replica distance is unknown
名前Replica距離は未知です。
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.
記述Thereは見つけるいくつかのサーバかプロキシには要求しているクライアントか別のマシンの、より近く、地理的またはネットワーク形態にあるお勧めの方法ではありません。
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.
含意Clientsは、複数の所在地から役立たれるかもしれないドキュメントのコピーを要求するとき、どのレプリカが彼らの、より近くにあるかを推測しなければなりません。 ユーザは特定のオブジェクトに役立つことができるサーバのセットを知らなければなりません。 決定して、一般に、これは維持しにくいです。 ユーザは、最も近いコピーを選ぶためにネットワーク形態を理解しなければなりません。 最も近いコピーがいつも最も迅速なサービスをもたらすものであるというわけではないことに注意してください。 近くに、しかし、大いにロードされたサーバは、より遠方の、しかし、軽くロードされたサーバより遅いかもしれません。
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.
ソリューション建築する、--プロトコル仕事が必要です。 これは中の一般的問題の特定のインスタンスです。広く、分散システム一般解がありそうもない、しかしながら、ウェブ文脈の特定のソリューションは可能です。
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.
回避策Serversはレプリカ選択ウェブページに位置のヒントを提供できます(多くはそうします)。 ユーザは彼らの位置に基づくものを選びます。 ユーザは、どのレプリカサーバが最も良い性能を彼らに与えるかを学ぶことができます。 ネットワーク形態に関して最も近いレプリカが必ず最も近くに地理的にないことに注意してください。 ユーザがネットワーク形態を理解していると予想するのは無理です。
Contact
Daniel LaLiberte <liberte@w3.org>
ダニエル LaLiberte <liberte@w3.org に連絡してください、gt。
Cooper & Dilley Informational [Page 22] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[22ページ]のRFC3143
A.1.3 Proxy resource location
A.1.3プロキシリソース位置
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.
記述Thereはクライアントかサーバ(別のプロキシを含んでいる)がリソースをとって来るのに使用する代替アドレス(恐らく、そのアドレスに達するのに使用するプロキシを含んでいる)についてプロキシに知らせる方法ではありません。 クライアントが、向け直すことでありリソースが来たそれがそれを有効にするか、またはどこを有効にする必要があるかもしれないところで来たと信じないなら。
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.
含意Proxiesには、他のプロキシか発生源サーバの中でリソースの場所を見つける系統立った方法が全くありません。 これで、プロキシの中で情報を共有するのは、より難しくなります。 情報共有はグローバルな効率を高めるでしょう。
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).)
回避策Certainプロキシはそれらのコンテンツ(例えば、Squid)の概要ダイジェストの形で位置のヒントを共有します。 あるプロキシプロトコルはコンテンツ(例えば、ICP)における、別プロキシ質問を可能にします。 (しかしながら、「ICPパフォーマンス」という問題(セクション2.2.5)を見てください。)
Contact
Daniel LaLiberte <liberte@w3.org>
ダニエル LaLiberte <liberte@w3.org に連絡してください、gt。
A.2 Implementation
A.2実装
A.2.1 Use of Cache-Control headers
Cache-コントロールヘッダーのA.2.1使用
Name
Use of Cache-Control headers
Cache-コントロールヘッダーの名前Use
Classification
Implementation
分類実装
Cooper & Dilley Informational [Page 23] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[23ページ]のRFC3143
Description
Many (if not most) implementations incorrectly interpret Cache-
Control response headers.
記述Many最も)実装は不当にCacheコントロール応答ヘッダを解釈します。
Significance
High
意味高値
Implications
Cache-Control headers will be spurned by end users if there are
conflicting or non-standard implementations.
そこであるならCache-コントロールヘッダーがエンドユーザによって拒まれるという含意は、闘争か標準的でない実装です。
Indications
-
指摘、-
Solution(s)
Work with vendors and others to assure proper application
ソリューションは、正当な適用を保証するためにベンダーと他のものと共に働いています。
Workaround
None.
回避策、なし。
Contact
Mark Nottingham <mnot@mnot.net>
マーク Nottingham <mnot@mnot.net に連絡してください、gt。
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コンプライアンスの名前Lack
Classification
Implementation
分類実装
Description
Although performance benchmarking of caches is starting to be
explored, protocol compliance is just as important.
キャッシュの記述Although性能ベンチマーキングは探検され始めていて、プロトコルコンプライアンスはちょうど同じくらい重要です。
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プロキシベンダーは彼らの仕様の解釈を実装します。 仕様が非常に大きく、時々あいまいであいまいであるので、これはプロキシをキャッシュすることの間の無節操な振舞いに通じることができます。
Caching proxies need to comply to the specification (or the
specification needs to change).
仕様(仕様は、変化する必要がある)に応じるプロキシの必要性をキャッシュします。
Cooper & Dilley Informational [Page 24] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[24ページ]のRFC3143
Indications
There is no currently known compliance test being used.
指摘Thereは適合テストが使用されません現在知られている。
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]の間の共同技術報告書は承諾テストについて説明します。 このレポートは、それぞれの1セットの先頭のトラフィックを生産するサイトが、ある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.
Measurement Factory(以前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.
回避策Thereは不承諾のための回避策ではありません。
Contact
Mark Nottingham <mnot@mnot.net>
Duane Wessels <wessels@measurement-factory.com>
マーク Nottingham <mnot@mnot.net に連絡してください、gt;、ドウェインウェセルズ<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.
プロキシをキャッシュする記述Availableは、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.
以来変更されるなら、含意は/をLast変更しました。多くの要件に、合法化は日付の弱点とその使用のために不適当です。 使用可能で、強い一貫性プロトコルの不足は、開発者とエンドユーザがキャッシュを信じないように導きます。
Indications
-
指摘、-
Cooper & Dilley Informational [Page 25] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[25ページ]のRFC3143
Solution(s)
Work with vendors to implement ETags; work for better validation
protocols.
ソリューションはETagsを実装するためにベンダーと共に働いています。 より良い合法化プロトコルには、働いてください。
Workaround
Use Last-Modified/If-Modified-Since validation.
以来変更されるなら、回避策Useは/をLast変更しました。合法化。
Contact
Mark Nottingham <mnot@mnot.net>
マーク Nottingham <mnot@mnot.net に連絡してください、gt。
A.2.4 Servers and content should be optimized for caching
A.2.4サーバと内容はキャッシュのために最適化されるべきです。
Name
Servers and content should be optimized for caching
名前Serversと内容はキャッシュのために最適化されるべきです。
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.
キャッシュにより役に立つと記述Manyウェブサーバーと多くのウェブ内容を実装することができました、帯域幅需要とページ負荷遅れを抑えて。
Significance
Medium
意味媒体
Implications
By making poor use of caches, origin servers encourage longer load
times, greater load on caching proxies, and increased network
demand.
By作成の貧乏人が使用するキャッシュの含意、発生源サーバは、より長い負荷回、プロキシをキャッシュするときの、よりすばらしい負荷、および増強されたネットワーク需要を奨励します。
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.
回避策Serversが、ユニークなオブジェクト識別子を使用し始めるかもしれない、書く、-単に、内容: オブジェクトが変化するなら、それは新しい名前を得ます。さもなければ、不変であり、したがって、無限に時代を吐き出させるのは、考えられます。 ある接待プロバイダーは既にこれをします。
Contact
Peter Danzig
ピーター・ダンツィグに連絡してください。
Cooper & Dilley Informational [Page 26] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[26ページ]のRFC3143
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
きめ細かに粒状の、そして、標準化された階級制御の名前Lack
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.
記述Thereはそれがどう与えられたオブジェクトをとって来る親を決議するべきであるかに関してプロキシを命令する規格ではありません。 したがって、実装は大いに異なります、そして、彼らに複雑な環境で正しく共同利用させるのは、難しい場合があります。
Significance
Medium
意味媒体
Implications
Complications in deployment of caches in a complex network
(especially corporate networks)
複雑なネットワークにおける、キャッシュの展開における含意Complications(特に法人のネットワーク)
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.
何人かの交通整理するために構成されるべきプロキシの指摘Inabilityがドメイン名に基づいて、通常の操作とフェイルオーバーモードでルックアップIPアドレス、生のIPアドレスを逆にしてください。 都合のよい親/バックアップ親構成を設定できない何人かのプロキシのこと。
Solution(s)
-
ソリューション、-
Workaround
Work with vendors to establish an acceptable configuration within
the limits of their product; standardize on one product.
それらの製品の限界の中で許容構成を確立するベンダーがある回避策Work。 1個の製品の上に標準化します。
Contact
Mark Nottingham <mnot@mnot.net>
マーク Nottingham <mnot@mnot.net に連絡してください、gt。
A.3.2 Proxy/Server exhaustive log format standard for analysis
分析のA.3.2プロキシ/サーバの徹底的なログ形式規格
Name
Proxy/Server exhaustive log format standard for analysis
分析の名前Proxy/サーバの徹底的なログ形式規格
Classification
Administration
分類機関
Cooper & Dilley Informational [Page 27] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[27ページ]のRFC3143
Description
Most proxy or origin server logs used for characterization or
evaluation do not provide sufficient detail to determine
cacheability of responses.
特殊化か評価に使用される記述Mostプロキシか起源サーバログが応答のcacheabilityを決定できるくらいの詳細を明らかにしません。
Significance
Low (for operationality; high significance for research efforts)
意味安値(操作性のために;、研究の努力のための高い意味)
Implications
Characterizations and simulations are based on non-representative
workloads.
含意Characterizationsとシミュレーションは非代表ワークロードに基づいています。
See Also
W3C Web Characterization Activity, since they are also concerned
with collecting high quality logs and building characterizations
from them.
Also W3CウェブCharacterization Activityを見てください、また、それらは高品質のログを集めて、それらから特殊化を組み込むのに関係があるので。
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.)
適切に掃除して、正確に応答のcacheabilityを決定するソリューションであり、完全なログが必要です。(「ユーザエージェント」[クモの取り外しのための]や「期限が切れる」「最大時代」、「セットクッキー」、「いいえキャッシュ」などのすべての応答ヘッダと同様にすべての要求ヘッダーを含んでいます)
Workaround
-
次善策、-
References
See "Web Traffic Logs: An Imperfect Resource for Evaluation"[5]
for some discussion of this.
参照は、「ウェブ・トラフィックは以下を登録します。」がわかります。 EvaluationのためのImperfect Resource、「この何らかの議論のための[5]。」
Contact
Brian D. Davison <davison@acm.org>
Terence Kelly <tpkelly@eecs.umich.edu>
ブライアンD. Davison <davison@acm.org に連絡してください、gt;、テレンス Kelly <tpkelly@eecs.umich.edu 、gt。
A.3.3 Trace log timestamps
A.3.3跡のログタイムスタンプ
Name
Trace log timestamps
名前Traceログタイムスタンプ
Classification
Administration
分類機関
Cooper & Dilley Informational [Page 28] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[28ページ]のRFC3143
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.
記述Someプロキシ/サーバは十分なタイミングの詳細なしで要求を登録します。 ミリセカンド解決はしばしば要求注文を保存できないくらい小さいです、そして、サーバは完成時間か、経過時間とどちらかに加えて要求レセプション時間を記録するべきです。
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.
含意Characterizationとシミュレーション信義は正確なタイミングと注文情報で改良されます。 ログが要求完成の順に一般に書かれているので、要求世代回数を知って、それに従って、再命令しないで、これらのログを再演できません。
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.
多回入国に、指摘Timestampsは同じである場合があります(ミリセカンド解決だけが使用されているとき)。 クライアントがまだ容器物を受けている間、埋め込みオブジェクトのための追加接続を開くと受注業務を乱雑にすることができるよう要求してください。
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.
参照は、「ウェブ・トラフィックは以下を登録します。」がわかります。 EvaluationのためのImperfect Resource、「この何らかの議論のための[5]。」
Contact
Brian D. Davison <davison@acm.org>
ブライアンD. Davison <davison@acm.org に連絡してください、gt。
A.3.4 Exchange format for log summaries
ログ概要のためのA.3.4交換形式
Name
Exchange format for log summaries
ログ概要のための名前Exchange形式
Classification
Administration/Analysis?
分類政権/分析?
Cooper & Dilley Informational [Page 29] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[29ページ]のRFC3143
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.
記述Although、私たちには、プロキシ(簡素なCommon LogfileとSquid)のための標準のログファイル形式があって(多少)、それらのログファイルの概要のための一般的に受け入れられた形式がありません。 キャッシュ自体、または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.
意味High、それぞれのログファイル要約/分析ツールが本質的にはわざわざ一からやり直していることを意味するので、(コードの不要な反復)、およびさまざまな解析ツールを通した大きいログファイルの処理多くの費用はこと(再び、これといった理由もなく)です。過度である。
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.
別のもの、重要な分析を実行する含意In命令が(ローディング/構成と関連した時間がたつにつれての測定性能) 例えば、倍数からのアクセスログと最初の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.
Also 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.
指摘Disks/メモリの完全な(!) また、統計(複数のプログラムを使用する)に、走るために時間がかかります。 高いコンピュータの費用のために複数のマシンへの外で統計のかむことを分配しなければなりません。
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かExtended Common Logfileに似るかもしれませんが、形式とコンテンツは議論のための対象です。 理想的に、このアプローチは、個々のキャッシュサーバ製品が可能な概要インフォメーションの部分集合を供給することを許可するでしょう、すべてのサーバがどの人々が見たがっているかという情報のすべてを提供するのが、可能でないかもしれないので。
Cooper & Dilley Informational [Page 30] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[30ページ]のRFC3143
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.
あなた自身の個人的な使用のための次善策のDeviseのa個人的な概要形式--これだけが、他の利害関係者との概要インフォメーションの交換を複雑にするか、または排除さえします。
References
See the web pages for the commonly used cache stats analysis
programs, e.g., Calamaris, squidtimes, squidclients, etc.
一般的に使用されたキャッシュ統計分析のためのウェブページがプログラムする参照See、例えば、Calamaris、squidtimes、squidclientsなど
Contact
Martin Hamilton <martin@wwwcache.ja.net>
マーチン Hamilton <martin@wwwcache.ja.net に連絡してください、gt。
Cooper & Dilley Informational [Page 31] RFC 3143 Known HTTP Proxy/Caching Problems June 2001
HTTPプロキシ/キャッシュ問題2001年6月に知られていたクーパーとDilleyの情報[31ページ]のRFC3143
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Cooper & Dilley Informational [Page 32]
クーパーとDilley情報です。[32ページ]
一覧
スポンサーリンク
