RFC3507 日本語訳
3507 Internet Content Adaptation Protocol (ICAP). J. Elson, A. Cerpa. April 2003. (Format: TXT=98772 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Elson
Request for Comments: 3507 A. Cerpa
Category: Informational UCLA
April 2003
コメントを求めるワーキンググループJ.エルソンの要求をネットワークでつないでください: 3507年のA.Cerpaカテゴリ: 情報のUCLA2003年4月
Internet Content Adaptation Protocol (ICAP)
インターネット内容適合プロトコル(ICAP)
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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
IESG Note
IESG注意
The Open Pluggable Services (OPES) working group has been chartered to produce a standards track protocol specification for a protocol intended to perform the same of functions as ICAP. However, since ICAP is already in widespread use the IESG believes it is appropriate to document existing usage by publishing the ICAP specification as an informational document. The IESG also notes that ICAP was developed before the publication of RFC 3238 and therefore does not address the architectural and policy issues described in that document.
オープンPluggable Services(作品)ワーキンググループは、ICAPとして機能の同じくらいを実行することを意図するプロトコルのための標準化過程プロトコル仕様を作り出すためにチャーターされました。 しかしながら、ICAPが普及使用既に中であるので、IESGは、情報のドキュメントとしてICAP仕様を発表することによって既存の用法を記録するのが適切であると信じています。 IESGもICAPがRFC3238の公表の前に開発されたことに注意して、したがって、そのドキュメントで説明された建築するのと方針問題を扱いません。
Abstract
要約
ICAP, the Internet Content Adaption Protocol, is a protocol aimed at
providing simple object-based content vectoring for HTTP services.
ICAP is, in essence, a lightweight protocol for executing a "remote
procedure call" on HTTP messages. It allows ICAP clients to pass
HTTP messages to ICAP servers for some sort of transformation or
other processing ("adaptation"). The server executes its
transformation service on messages and sends back responses to the
client, usually with modified messages. Typically, the adapted
messages are either HTTP requests or HTTP responses.
ICAP(インターネットContent Adaptionプロトコル)はHTTPサービスのための簡単なオブジェクトベースの満足しているベクトル決定を提供するのが目的とされたプロトコルです。 本質では、ICAPは、HTTPメッセージで「遠隔手続き呼び出し」を実行するための軽量のプロトコルです。 それで、ICAPクライアントはある種の変換か他の処理(「適合」)のためのICAPサーバにHTTPメッセージを通過できます。 サーバは、メッセージで変換サービスを実行して、クライアントと、通常変更されたメッセージで応答を返送します。 適合しているメッセージは、通常、HTTP要求かHTTP応答のどちらかです。
Elson & Cerpa Informational [Page 1] RFC 3507 ICAP April 2003
[1ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
Table of Contents
目次
1. Introduction............................................3
2. Terminology.............................................5
3. ICAP Overall Operation..................................8
3.1 Request Modification..............................8
3.2 Response Modification............................10
4. Protocol Semantics.....................................11
4.1 General Operation................................11
4.2 ICAP URIs........................................11
4.3 ICAP Headers.....................................12
4.3.1 Headers Common to Requests and
Responses................................12
4.3.2 Request Headers..........................13
4.3.3 Response Headers.........................14
4.3.4 ICAP-Related Headers in HTTP
Messages.................................15
4.4 ICAP Bodies: Encapsulation of HTTP
Messages.........................................16
4.4.1 Expected Encapsulated Sections...........16
4.4.2 Encapsulated HTTP Headers................18
4.5 Message Preview..................................18
4.6 "204 No Content" Responses outside of
Previews.........................................22
4.7 ISTag Response Header............................22
4.8 Request Modification Mode........................23
4.8.1 Request..................................23
4.8.2 Response.................................24
4.8.3 Examples.................................24
4.9 Response Modification Mode.......................27
4.9.1 Request..................................27
4.9.2 Response.................................27
4.9.3 Examples.................................28
4.10 OPTIONS Method...................................29
4.10.1 OPTIONS request..........................29
4.10.2 OPTIONS response.........................30
4.10.3 OPTIONS examples.........................33
5. Caching................................................33
6. Implementation Notes...................................34
6.1 Vectoring Points.................................34
6.2 Application Level Errors.........................35
6.3 Use of Chunked Transfer-Encoding.................37
6.4 Distinct URIs for Distinct Services..............37
7. Security Considerations................................37
7.1 Authentication...................................37
7.2 Encryption.......................................38
7.3 Service Validation...............................38
8. Motivations and Design Alternatives....................39
1. 序論…3 2. 用語…5 3. ICAPの総合的な操作…8 3.1 変更を要求してください…8 3.2 応答変更…10 4. 意味論について議定書の中で述べてください…11 4.1 一般操作…11 4.2 ICAP URI…11 4.3 ICAPヘッダー…12 4.3 要求と応答に共通の.1個のヘッダー…12 4.3 .2 ヘッダーを要求してください…13 4.3 .3 応答ヘッダー…14 4.3 HTTPメッセージの.4個のICAP関連のヘッダー…15 4.4 ICAPボディー: HTTPメッセージのカプセル化…16 4.4 .1 カプセル化されたセクションは予想しました…16 4.4 .2はHTTPヘッダをカプセル化しました…18 4.5メッセージプレビュー…18 4.6 Previewsの外の「204いいえ内容」Responses…22 4.7 ISTag応答ヘッダ…22 4.8 変更モードを要求してください…23 4.8 .1 要求します。23 4.8 .2応答…24 4.8 .3の例…24 4.9 応答変更モード…27 4.9 .1 要求します。27 4.9 .2応答…27 4.9 .3の例…28 4.10 オプションメソッド…29 4.10.1 OPTIONS要求…29 4.10.2 OPTIONS応答…30 4.10.3 OPTIONSの例…33 5. キャッシュします。33 6. 実装注意…34 6.1ベクトル決定は指します…34 6.2 アプリケーションレベル誤り…35 6.3 Chunked転送コード化の使用…37 異なったサービスのための6.4の異なったURI…37 7. セキュリティ問題…37 7.1認証…37 7.2暗号化…38 7.3 合法化を修理してください…38 8. 動機とデザイン代替手段…39
Elson & Cerpa Informational [Page 2] RFC 3507 ICAP April 2003
[2ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
8.1 To Be HTTP, or Not to Be.........................39
8.2 Mandatory Use of Chunking........................39
8.3 Use of the null-body directive in the
Encapsulated header..............................40
9. References.............................................40
10. Contributors...........................................41
Appendix A BNF Grammar for ICAP Messages..................45
Authors' Addresses..........................................48
Full Copyright Statement....................................49
または、8.1 HTTPになるように少しもそうしません…。39 8.2 分魂化の義務的な使用…39 8.3 Encapsulatedヘッダーにおけるヌルボディー指示の使用…40 9. 参照…40 10. 貢献者…41 ICAPのための付録A BNF文法は通信します…45人の作者のアドレス…48 完全な著作権宣言文…49
1. Introduction
1. 序論
As the Internet grows, so does the need for scalable Internet services. Popular web servers are asked to deliver content to hundreds of millions of users connected at ever-increasing bandwidths. The model of centralized, monolithic servers that are responsible for all aspects of every client's request seems to be reaching the end of its useful life.
インターネットが発展するので、スケーラブルなインターネットのサービスの必要性もそうします。 ポピュラーなウェブサーバーが絶えず増加する帯域幅で接された何億人ものユーザに内容を提供するように頼まれます。 すべてのクライアントの要求の全面に原因となる集結されて、一枚岩的なサーバのモデルは、役に立つ寿命の端に達しているように思えます。
To keep up with the growth in the number of clients, there has been a move towards architectures that scale better through the use of replication, distribution, and caching. On the content provider side, replication and load-balancing techniques allow the burden of client requests to be spread out over a myriad of servers. Content providers have also begun to deploy geographically diverse content distribution networks that bring origin-servers closer to the "edge" of the network where clients are attached. These networks of distributed origin-servers or "surrogates" allow the content provider to distribute their content whilst retaining control over the integrity of that content. The distributed nature of this type of deployment and the proximity of a given surrogate to the end-user enables the content provider to offer additional services to a user which might be based, for example, on geography where this would have been difficult with a single, centralized service.
クライアントの数における成長について行くために、移動は、より一層模写、分配、およびキャッシュの使用でそのスケールにアーキテクチャに向かっています。 コンテンツプロバイダー側、模写、および負荷分散では、テクニックはサーバの無数の上に広げられるというクライアント要求の負担を許します。 また、コンテンツプロバイダーは、さまざまの満足している分配がクライアントが付属しているネットワークの「縁」の、より近くに発生源サーバをもたらすネットワークであると地理的に配布し始めました。 分配された発生源サーバか「代理」のこれらのネットワークで、コンテンツプロバイダーはその内容の保全のコントロールを保有している間、彼らの内容を分配できます。 このタイプの展開の分配された本質とエンドユーザの与えられた代理の近接は、コンテンツプロバイダーがユーザに対する例えばこれが単一の、そして、集結されたサービスによって難しい地理学に基づくかもしれない追加サービスを提供するのを可能にします。
ICAP, the Internet Content Adaption Protocol, is a protocol aimed at
providing simple object-based content vectoring for HTTP services.
ICAP is, in essence, a lightweight protocol for executing a "remote
procedure call" on HTTP messages. It allows ICAP clients to pass
HTTP messages to ICAP servers for some sort of transformation or
other processing ("adaptation"). The server executes its
transformation service on messages and sends back responses to the
client, usually with modified messages. The adapted messages may be
either HTTP requests or HTTP responses. Though transformations may
be possible on other non-HTTP content, they are beyond the scope of
this document.
ICAP(インターネットContent Adaptionプロトコル)はHTTPサービスのための簡単なオブジェクトベースの満足しているベクトル決定を提供するのが目的とされたプロトコルです。 本質では、ICAPは、HTTPメッセージで「遠隔手続き呼び出し」を実行するための軽量のプロトコルです。 それで、ICAPクライアントはある種の変換か他の処理(「適合」)のためのICAPサーバにHTTPメッセージを通過できます。 サーバは、メッセージで変換サービスを実行して、クライアントと、通常変更されたメッセージで応答を返送します。 適合しているメッセージは、HTTP要求かHTTP応答のどちらかであるかもしれません。 変換は他の非HTTP内容で可能であるかもしれませんが、それらはこのドキュメントの範囲を超えています。
Elson & Cerpa Informational [Page 3] RFC 3507 ICAP April 2003
[3ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
This type of Remote Procedure Call (RPC) is useful in a number of ways. For example:
Remote Procedure Call(RPC)のこのタイプは多くの方法で役に立ちます。 例えば:
o Simple transformations of content can be performed near the edge
of the network instead of requiring an updated copy of an object
from an origin server. For example, a content provider might want
to provide a popular web page with a different advertisement every
time the page is viewed. Currently, content providers implement
this policy by marking such pages as non-cachable and tracking
user cookies. This imposes additional load on the origin server
and the network. In our architecture, the page could be cached
once near the edges of the network. These edge caches can then
use an ICAP call to a nearby ad-insertion server every time the
page is served to a client.
o 発生源サーバからオブジェクトのアップデートされたコピーを必要とすることの代わりにネットワークの縁の近くで内容の簡単な変換を実行できます。例えば、ページが見られるときはいつも、コンテンツプロバイダーは、異なった広告をポピュラーなウェブページに提供したがっているかもしれません。 現在、そのようなページが同じくらい非キャッシュ可能であって追跡しているユーザクッキーであるとマークすることによって、コンテンツプロバイダーはこの政策を実施します。 これは発生源サーバとネットワークに追加負荷を課します。 私たちのアーキテクチャでは、ネットワークの縁の近くでページを一度キャッシュできました。 そして、ページがクライアントにサービスされているときはいつも、これらの縁のキャッシュは近い広告挿入サーバにICAP呼び出しを使用できます。
Other such transformations by edge servers are possible, either
with cooperation from the content provider (as in a content
distribution network), or as a value-added service provided by a
client's network provider (as in a surrogate). Examples of these
kinds of transformations are translation of web pages to different
human languages or to different formats that are appropriate for
special physical devices (e.g., PDA-based or cell-phone-based
browsers).
エッジサーバによる他のそのような変換はコンテンツプロバイダー(満足している流通機構のように)からの協力、または、クライアントのネットワーク内の提供者によって提供された付加価値が付いたサービスとして可能です(代理のように)。 これらの種類の変換に関する例は異なった人間の言語、または、異なった形式への特別なフィジカル・デバイス(例えば、PDAベースの、または、セル電話ベースのブラウザ)に、適切なウェブページの翻訳です。
o Surrogates or origin servers can avoid performing expensive
operations by shipping the work off to other servers instead.
This helps distribute load across multiple machines. For example,
consider a user attempting to download an executable program via a
surrogate (e.g., a caching proxy). The surrogate, acting as an
ICAP client, can ask an external server to check the executable
for viruses before accepting it into its cache.
o 代理か発生源サーバが、代わりに他のサーバに仕事を追っ払うことによって高価な操作を実行するのを避けることができます。 これは、複数のマシンの向こう側に負荷を分配するのを助けます。 例えば、代理(例えば、キャッシュしているプロキシ)を通して実行可能プログラムをダウンロードするのを試みるユーザを考えてください。 ICAPクライアントとして機能して、代理は、それをキャッシュに受け入れる前にウイルスのための実行可能をチェックするように外部のサーバに頼むことができます。
o Firewalls or surrogates can act as ICAP clients and send outgoing
requests to a service that checks to make sure the URI in the
request is allowed (for example, in a system that allows parental
control of web content viewed by children). In this case, it is a
*request* that is being adapted, not an object returned by a
response.
o ファイアウォールか代理が、要求におけるURIが許容されているのを(例えば子供によって見られたウェブ内容のペアレンタル・コントロールを許容するシステムで)確実にするためにICAPクライアントとして務めて、送信する要求をチェックするサービスに送ることができます。 この場合、それは応答で返されたオブジェクトではなく、適合させられている*要求*です。
In all of these examples, ICAP is helping to reduce or distribute the load on origin servers, surrogates, or the network itself. In some cases, ICAP facilitates transformations near the edge of the network, allowing greater cachability of the underlying content. In other examples, devices such as origin servers or surrogates are able to reduce their load by distributing expensive operations onto other machines. In all cases, ICAP has also created a standard interface for content adaptation to allow greater flexibility in content distribution or the addition of value added services in surrogates.
これらの例では、全部で、ICAPは、発生源サーバ、代理、またはネットワーク自体で負荷を減少するか、または分配するのを助けています。 いくつかの場合、基本的な内容の、よりすばらしいcachabilityを許容して、ICAPはネットワークの縁の近くで変換を容易にします。 他の例では、発生源サーバか代理などのデバイスは、高価な操作を他のマシンに広げることによって、彼らの負荷を減少させることができます。 また、すべての場合では、満足している適合が代理に満足している分配における、より大きい柔軟性か付加価値が付いたサービスの追加を許容するように、ICAPは標準インターフェースを作成しました。
Elson & Cerpa Informational [Page 4] RFC 3507 ICAP April 2003
[4ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
There are two major components in our architecture:
私たちのアーキテクチャには2個の主要コンポーネントがあります:
1. Transaction semantics -- "How do I ask for adaptation?"
1. トランザクション意味論--「私はどのように適合を求めますか?」
2. Control of policy -- "When am I supposed to ask for adaptation,
what kind of adaptation do I ask for, and from where?"
2. 方針のコントロール--「いつが私であるかは、適合を求めると思って、どこでどこからどういう適合を尋ねます」。
Currently, ICAP defines only the transaction semantics. For example, this document specifies how to send an HTTP message from an ICAP client to an ICAP server, specify the URI of the ICAP resource requested along with other resource-specific parameters, and receive the adapted message.
現在、ICAPはトランザクション意味論だけを定義します。 例えば、このドキュメントはどのようにICAPクライアントからICAPサーバにHTTPメッセージを送って、他のリソース特有のパラメタと共に要求されたICAPリソースのURIを指定して、適合しているメッセージを受け取るかを指定します。
Although a necessary building-block, this wire-protocol defined by ICAP is of limited use without the second part: an accompanying application framework in which it operates. The more difficult policy issue is beyond the scope of the current ICAP protocol, but is planned in future work.
必要なブロックですが、ICAPによって定義されたこのワイヤプロトコルは第二部なしで限られて役に立ちます: それが作動する付随のアプリケーションフレームワーク。 より難しい政策問題は、現在のICAPプロトコルの範囲を超えていますが、今後の活動で計画されています。
In initial implementations, we expect that implementation-specific manual configuration will be used to define policy. This includes the rules for recognizing messages that require adaptation, the URIs of available adaptation resources, and so on. For ICAP clients and servers to interoperate, the exact method used to define policy need not be consistent across implementations, as long as the policy itself is consistent.
初期の実装では、私たちは、実装特有の手動の構成が方針を定義するのに使用されると予想します。 これは適合を必要とするメッセージを認識するための規則、利用可能な適合リソースのURIなどを含んでいます。 ICAPクライアントとサーバが共同利用するために、方針を定義するのに使用される正確なメソッドは実装の向こう側に一貫している必要はありません、方針自体が一貫している限り。
IMPORTANT:
Note that at this time, in the absence of a policy-framework, it
is strongly RECOMMENDED that transformations SHOULD only be
performed on messages with the explicit consent of either the
content-provider or the user (or both). Deployment of
transformation services without the consent of either leads to, at
best, unpredictable results. For more discussion of these issues,
see Section 7.
重要: このとき方針フレームワークがないときそれが強くそうであることに注意してください、RECOMMENDED、変換SHOULDはコンテンツプロバイダーかユーザのどちらかの明白な同意(ともに)でメッセージに実行されるだけです。 どちらかの同意のない変換サービスの展開は予測できない結果にせいぜいつながります。 これらの問題の、より多くの議論に関しては、セクション7を見てください。
Once the full extent of the typical policy decisions are more fully understood through experience with these initial implementations, later follow-ons to this architecture may define an additional policy control protocol. This future protocol may allow a standard policy definition interface complementary to the ICAP transaction interface defined here.
典型的な政策決定の完全な範囲がこれらの初期の実装の経験で、より完全にいったん理解されていると、このアーキテクチャへの後のフォローオンは追加方針制御プロトコルを定義するかもしれません。 この将来のプロトコルは標準約款定義インタフェース補色をここで定義されたICAPトランザクションインタフェースまで許容するかもしれません。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。
Elson & Cerpa Informational [Page 5] RFC 3507 ICAP April 2003
[5ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
The special terminology used in this document is defined below. The majority of these terms are taken as-is from HTTP/1.1 [4] and are reproduced here for reference. A thorough understanding of HTTP/1.1 is assumed on the part of the reader.
本書では使用される特別な用語は以下で定義されます。 これらの用語の大部分が、HTTP/1.1[4]からそのままでかかって、参照のためにここで再生します。 HTTP/1.1の徹底的な理解は読者側の想定されます。
connection:
A transport layer virtual circuit established between two programs
for the purpose of communication.
接続: トランスポート層の仮想の回路は2の間にコミュニケーションの目的のためのプログラムを設立しました。
message:
The basic unit of HTTP communication, consisting of a structured
sequence of octets matching the syntax defined in Section 4 of
HTTP/1.1 [4] and transmitted via the connection.
メッセージ: HTTP/1.1[4]のセクション4で定義されて、接続で伝えられた構文に合っている八重奏の構造化された系列から成るHTTPコミュニケーションの原単位。
request:
An HTTP request message, as defined in Section 5 of HTTP/1.1 [4].
以下を要求してください。 HTTP/1.1[4]のセクション5で定義されるようなHTTP要求メッセージ。
response:
An HTTP response message, as defined in Section 6 of HTTP/1.1 [4].
応答: HTTP/1.1[4]のセクション6で定義されるようなHTTP応答メッセージ。
resource:
A network data object or service that can be identified by a URI,
as defined in Section 3.2 of HTTP/1.1 [4]. Resources may be
available in multiple representations (e.g., multiple languages,
data formats, size, resolutions) or vary in other ways.
リソース: HTTP/1.1[4]のセクション3.2で定義されるようにURIで特定できるネットワークデータ・オブジェクトかサービス。 リソースは、複数の表現(例えば、複数の言語、データ形式、サイズ、解決)で利用可能であるか、または他の方法で異なるかもしれません。
client:
A program that establishes connections for the purpose of sending
requests.
クライアント: 要求を送る目的のために関係を樹立するプログラム。
server:
An application program that accepts connections in order to
service requests by sending back responses. Any given program may
be capable of being both a client and a server; our use of these
terms refers only to the role being performed by the program for a
particular connection, rather than to the program's capabilities
in general. Likewise, any server may act as an origin server,
surrogate, gateway, or tunnel, switching behavior based on the
nature of each request.
サーバ: 応答を返送することによって要求を修理するために接続を受け入れるアプリケーション・プログラム。 どんな与えられたプログラムもクライアントとサーバの両方であることができるかもしれません。 私たちのこれらの用語の使用は一般に、プログラムの能力にというよりむしろ特定の接続のためのプログラムで実行される役割だけについて言及します。 同様に、どんなサーバも発生源サーバ、代理、ゲートウェイ、またはトンネルとして務めるかもしれません、それぞれの要求の本質に基づく振舞いを切り換えて。
origin server:
The server on which a given resource resides or is to be created.
発生源サーバ: 住んでいるか、または作成される与えられたリソースがことであるサーバ。
Elson & Cerpa Informational [Page 6] RFC 3507 ICAP April 2003
[6ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
proxy:
An intermediary program which acts as both a server and a client
for the purpose of making requests on behalf of other clients.
Requests are serviced internally or by passing them on, with
possible translation, to other servers. A proxy MUST implement
both the client and server requirements of this specification.
プロキシ: 他のクライアントを代表して要求をする目的のためのサーバとクライアントの両方として作動する仲介者プログラム。 要求は、内部的か可能な翻訳で他のサーバにそれらを伝えることによって、修理されます。 プロキシは、両方がこの仕様のクライアントとサーバ要件であると実装しなければなりません。
cache:
A program's local store of response messages and the subsystem
that controls its message storage, retrieval, and deletion. A
cache stores cachable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent
requests. Any client or server may include a cache, though a
cache cannot be used by a server that is acting as a tunnel.
以下をキャッシュしてください。 メッセージストレージ、検索、および削除を制御するプログラムの応答メッセージとサブシステムの地元の小売店。 キャッシュは、将来的で、同等な要求における応答時間とネットワーク回線容量消費を短縮するためにキャッシュ可能応答を保存します。 どんなクライアントやサーバもキャッシュを入れるかもしれません、トンネルとして機能しているサーバでキャッシュを使用できませんが。
cachable:
A response is cachable if a cache is allowed to store a copy of
the response message for use in answering subsequent requests.
The rules for determining the cachability of HTTP responses are
defined in Section 13 of [4]. Even if a resource is cachable,
there may be additional constraints on whether a cache can use the
cached copy for a particular request.
キャッシュ可能: キャッシュがその後の要求に答えることにおける使用のための応答メッセージのコピーを保存できるなら、応答はキャッシュ可能です。 HTTP応答のcachabilityを決定するための規則は[4]のセクション13で定義されます。 リソースがキャッシュ可能であっても、キャッシュが特定の要求にキャッシュされたコピーを使用できるかどうかに関して追加規制があるかもしれません。
surrogate:
A gateway co-located with an origin server, or at a different
point in the network, delegated the authority to operate on behalf
of, and typically working in close co-operation with, one or more
origin servers. Responses are typically delivered from an
internal cache. Surrogates may derive cache entries from the
origin server or from another of the origin server's delegates.
In some cases a surrogate may tunnel such requests.
代理: ゲートウェイが発生源サーバ、またはネットワークにおけるa異なったポイントで共同場所を見つけて、密接な協力で作動して、通常働く権威を代表として派遣した、1つ以上の発生源サーバ。 応答は内部キャッシュから通常提供されます。 代理は発生源サーバか発生源サーバの代表の別のものからキャッシュエントリーを引き出すかもしれません。 いくつかの場合、代理はそのような要求にトンネルを堀るかもしれません。
Where close co-operation between origin servers and surrogates
exists, this enables modifications of some protocol requirements,
including the Cache-Control directives in [4]. Such modifications
have yet to be fully specified.
発生源サーバと代理の間の密接な協力が存在しているところでは、これはいくつかのプロトコル要件の変更を可能にします、[4]にCache-コントロール指示を含んでいて。 そのような変更はまだ完全に指定されているというわけではありません。
Devices commonly known as "reverse proxies" and "(origin) server
accelerators" are both more properly defined as surrogates.
「逆のプロキシ」と「(発生源)サーバアクセラレータ」として一般的に知られているデバイスはともにより適切に代理と定義されます。
New definitions:
新しい定義:
ICAP resource:
Similar to an HTTP resource as described above, but the URI refers
to an ICAP service that performs adaptations of HTTP messages.
ICAPリソース: 上で説明されるHTTPリソースと同様です、URIだけがHTTPメッセージの適合を実行するICAPサービスについて言及します。
Elson & Cerpa Informational [Page 7] RFC 3507 ICAP April 2003
[7ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
ICAP server:
Similar to an HTTP server as described above, except that the
application services ICAP requests.
ICAPサーバ: アプリケーションがICAP要求を修理するのを除いて、上で説明されるHTTPサーバと同様です。
ICAP client:
A program that establishes connections to ICAP servers for the
purpose of sending requests. An ICAP client is often, but not
always, a surrogate acting on behalf of a user.
ICAPクライアント: 要求を送る目的のためにICAPサーバに関係を樹立するプログラム。 しばしばである代理がユーザを代表して行動して、ICAPクライアントはいつもそうであるというわけではありません。
3. ICAP Overall Operation
3. ICAPの総合的な操作
Before describing ICAP's semantics in detail, we will first give a general overview of the protocol's major functions and expected uses. As described earlier, ICAP focuses on modification of HTTP requests (Section 3.1), and modification of HTTP responses (Section 3.2).
詳細にICAPの意味論について説明する前に、私たちは最初に、プロトコルの主要な機能と予想された用途の概要を与えるつもりです。 より早く説明されるように、ICAPはHTTP要求の変更(セクション3.1)、およびHTTP応答の変更(セクション3.2)に焦点を合わせます。
3.1 Request Modification
3.1 要求変更
In "request modification" (reqmod) mode, an ICAP client sends an HTTP request to an ICAP server. The ICAP server may then:
「要求変更」(reqmod)モードで、ICAPクライアントはHTTP要求をICAPサーバに送ります。ICAPサーバはそしてときにそうするかもしれません:
1) Send back a modified version of the request. The ICAP client may
then perform the modified request by contacting an origin server;
or, pipeline the modified request to another ICAP server for
further modification.
1) 要求の変更されたバージョンを返送してください。 次に、ICAPクライアントは発生源サーバに連絡することによって、変更された要求を実行するかもしれません。 または、変更がさらなる変更のための別のICAPサーバに要求するパイプライン。
2) Send back an HTTP response to the request. This is used to
provide information useful to the user in case of an error (e.g.,
"you sent a request to view a page you are not allowed to see").
2) 要求へのHTTP応答を返送してください。 これは、誤りの場合にユーザの役に立つ情報を提供するのに使用されます(例えば、「あなたはあなたが見ることができない1ページを見るという要求を送りました」)。
3) Return an error.
3) 誤りを返してください。
ICAP clients MUST be able to handle all three types of responses. However, in line with the guidance provided for HTTP surrogates in Section 13.8 of [4], ICAP client implementors do have flexibility in handling errors. If the ICAP server returns an error, the ICAP client may (for example) return the error to the user, execute the unadapted request as it arrived from the client, or re-try the adaptation again.
ICAPクライアントはすべての3つのタイプの応答を扱うことができなければなりません。 しかしながら、[4]のセクション13.8のHTTP代理に提供された指導に沿って、ICAPクライアント作成者は取り扱い誤りにおける柔軟性を持っています。 ICAPサーバが誤りを返すなら、ICAPクライアントは、(例えば) 誤りをユーザに返すか、クライアントから到着したので「非-適合させ」られた要求を実行するか、または再び適合を再試行するかもしれません。
We will illustrate this method with an example application: content filtering. Consider a surrogate that receives a request from a client for a web page on an origin server. The surrogate, acting as an ICAP client, sends the client's request to an ICAP server that performs URI-based content filtering. If access to the requested URI is allowed, the request is returned to the ICAP client unmodified. However, if the ICAP server chooses to disallow access to the requested resources, it may either:
私たちは例のアプリケーションをこのメソッドに入れるつもりです: コンテントのフィルタリング。 ウェブページのために発生源サーバにクライアントから要求を受け取る代理を考えてください。ICAPクライアントとして機能して、代理はURIベースのコンテントのフィルタリングを実行するICAPサーバにクライアントの要求を送ります。 要求されたURIへのアクセスを許すなら、ICAPクライアントに要求を変更されていなく返します。 しかしながら、ICAPサーバが、要求されたリソースへのアクセスを禁じるのを選ぶなら、選びます:
Elson & Cerpa Informational [Page 8] RFC 3507 ICAP April 2003
[8ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
1) Modify the request so that it points to a page containing an error
message instead of the original URI.
1) オリジナルのURIの代わりにエラーメッセージを含む1ページを示すように、要求を変更してください。
2) Return an encapsulated HTTP response that indicates an HTTP error.
2) HTTP誤りを示すカプセル化されたHTTP応答を返してください。
This method can be used for a variety of other applications; for example, anonymization, modification of the Accept: headers to handle special device requirements, and so forth.
他のさまざまなアプリケーションにこのメソッドを使用できます。 例えば、anonymization、Acceptの変更: 特別なデバイス要件などを扱うヘッダー。
Typical data flow:
典型的なデータは流れます:
origin-server
| /|\
| |
5 | | 4
| |
\|/ | 2
ICAP-client --------------> ICAP-resource
(surrogate) <-------------- on ICAP-server
| /|\ 3
| |
6 | | 1
| |
\|/ |
client
発生源サーバ| /|\ | | 5 | | 4 | | \|/ | 2ICAP-クライアント-------------->ICAP-リソース(代理)<。-------------- ICAP-サーバに関して| /|\ 3 | | 6 | | 1 | | \|/ | クライアント
1. A client makes a request to a ICAP-capable surrogate (ICAP client)
for an object on an origin server.
1. クライアントはオブジェクトのために発生源サーバでICAP有能な代理(ICAPクライアント)に要求を出します。
2. The surrogate sends the request to the ICAP server.
2. 代理はICAPサーバに要求を送ります。
3. The ICAP server executes the ICAP resource's service on the
request and sends the possibly modified request, or a response to
the request back to the ICAP client.
3. ICAPサーバは、ICAPクライアントへの要求に要求のときにICAPリソースのサービスを実行して、ことによると変更された要求、または応答を送ります。
If Step 3 returned a request:
Step3が要求を返したなら:
4. The surrogate sends the request, possibly different from original
client request, to the origin server.
4. 代理はことによるとオリジナルのクライアント要求から発生源サーバまで異なった要求を送ります。
5. The origin server responds to request.
5. 発生源サーバは要求に応じます。
6. The surrogate sends the reply (from either the ICAP server or the
origin server) to the client.
6. 代理は回答(ICAPサーバか発生源サーバのどちらかからの)をクライアントに送ります。
Elson & Cerpa Informational [Page 9] RFC 3507 ICAP April 2003
[9ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
3.2 Response Modification
3.2 応答変更
In the "response modification" (respmod) mode, an ICAP client sends an HTTP response to an ICAP server. (The response sent by the ICAP client typically has been generated by an origin server.) The ICAP server may then:
「応答変更」(respmod)モードで、ICAPクライアントはICAPサーバへのHTTP応答を送ります。. (ICAPクライアントによって送られた応答は発生源サーバによって通常生成されました。) ICAPサーバはそしてときにそうするかもしれません:
1) Send back a modified version of the response.
1) 応答の変更されたバージョンを返送してください。
2) Return an error.
2) 誤りを返してください。
The response modification method is intended for post-processing performed on an HTTP response before it is delivered to a client. Examples include formatting HTML for display on special devices, human language translation, virus checking, and so forth.
それがクライアントに提供される前にHTTP応答に実行されて、応答変更メソッドは後工程の間、意図します。 例は特別なデバイスにおけるディスプレイのための形式HTML、人間の言語翻訳、ウイルスの照合などを含んでいます。
Typical data flow:
典型的なデータは流れます:
origin-server
| /|\
| |
3 | | 2
| |
\|/ | 4
ICAP-client --------------> ICAP-resource
(surrogate) <-------------- on ICAP-server
| /|\ 5
| |
6 | | 1
| |
\|/ |
client
発生源サーバ| /|\ | | 3 | | 2 | | \|/ | 4ICAP-クライアント-------------->ICAP-リソース(代理)<。-------------- ICAP-サーバに関して| /|\ 5 | | 6 | | 1 | | \|/ | クライアント
1. A client makes a request to a ICAP-capable surrogate (ICAP client)
for an object on an origin server.
1. クライアントはオブジェクトのために発生源サーバでICAP有能な代理(ICAPクライアント)に要求を出します。
2. The surrogate sends the request to the origin server.
2. 代理は発生源サーバに要求を送ります。
3. The origin server responds to request.
3. 発生源サーバは要求に応じます。
4. The ICAP-capable surrogate sends the origin server's reply to the
ICAP server.
4. ICAP有能な代理は発生源サーバの回答をICAPサーバに送ります。
5. The ICAP server executes the ICAP resource's service on the origin
server's reply and sends the possibly modified reply back to the
ICAP client.
5. ICAPサーバは、発生源サーバの回答のときにICAPリソースのサービスを実行して、ことによると変更された回答をICAPクライアントに送り返します。
Elson & Cerpa Informational [Page 10] RFC 3507 ICAP April 2003
[10ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
6. The surrogate sends the reply, possibly modified from the original
origin server's reply, to the client.
6. 代理はことによるとオリジナルの発生源サーバの回答から変更された回答をクライアントに送ります。
4. Protocol Semantics
4. プロトコル意味論
4.1 General Operation
4.1 一般操作
ICAP is a request/response protocol similar in semantics and usage to HTTP/1.1 [4]. Despite the similarity, ICAP is not HTTP, nor is it an application protocol that runs over HTTP. This means, for example, that ICAP messages can not be forwarded by HTTP surrogates. Our reasons for not building directly on top of HTTP are discussed in Section 8.1.
ICAPは意味論と用法においてHTTP/1.1[4]と同様の要求/応答プロトコルです。 類似性にもかかわらず、ICAPはHTTPではありません、そして、HTTPをひくのは、アプリケーション・プロトコルではありません。 例えば、これは、HTTP代理がICAPメッセージを転送できないことを意味します。 セクション8.1で私たちの直接HTTPの上に建てない理由について議論します。
ICAP uses TCP/IP as a transport protocol. The default port is 1344, but other ports may be used. The TCP flow is initiated by the ICAP client to a passively listening ICAP server.
ICAPはトランスポート・プロトコルとしてTCP/IPを使用します。 デフォルトポートは1344ですが、他のポートは使用されるかもしれません。 TCP流動はICAPクライアントによって受け身に聴いているICAPサーバに起こされます。
ICAP messages consist of requests from client to server and responses from server to client. Requests and responses use the generic message format of RFC 2822 [3] -- that is, a start-line (either a request line or a status line), a number of header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and a message-body.
ICAPメッセージはクライアントからサーバまでの要求とサーバからクライアントまでの応答から成ります。 要求と応答はRFC2822[3]のジェネリックメッセージ・フォーマットを使用します--すなわち、スタート系列(要求系列か状況表示行のどちらか)、多くのヘッダーフィールド(また、「ヘッダー」として、知られている)、ヘッダーフィールドの終わりを示す空の系列(すなわち、何もCRLFに先行していない系列)、およびメッセージ本体。
The header lines of an ICAP message specify the ICAP resource being requested as well as other meta-data such as cache control information. The message body of an ICAP request contains the (encapsulated) HTTP messages that are being modified.
ICAPメッセージのヘッダー系列はキャッシュ制御情報などの他のメタデータと同様に要求されているICAPリソースを指定します。 ICAP要求のメッセージ本体は変更されている(要約します)HTTPメッセージを含んでいます。
As in HTTP/1.1, a single transport connection MAY (perhaps even SHOULD) be re-used for multiple request/response pairs. The rules for doing so in ICAP are the same as described in Section 8.1.2.2 of [4]. Specifically, requests are matched up with responses by allowing only one outstanding request on a transport connection at a time. Multiple parallel connections MAY be used as in HTTP.
HTTP/1.1のように、単独の輸送接続は複数の要求/応答に、再中古の組であるかもしれません(恐らくSHOULDさえ)。 ICAPでそうするための規則は[4]でセクション8.1.2で.2について説明するのと同じです。 明確に、要求は一度に輸送接続のときに1つの傑出している要求だけを許すことによって応答に上がった状態で取り組んでいます。 複数の並列接続がHTTPのように使用されているかもしれません。
4.2 ICAP URIs
4.2 ICAP URI
All ICAP requests specify the ICAP resource being requested from the server using an ICAP URI. This MUST be an absolute URI that specifies both the complete hostname and the path of the resource being requested. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [1], Section 3. The URI structure defined by ICAP is roughly:
すべてのICAP要求がサーバからICAP URIを使用することで要求されるICAPリソースを指定します。 これは要求されている完全なホスト名とリソースの経路の両方を指定する絶対URIであるに違いありません。 URL構文と意味論の決定的な情報に関しては、見てください、「Uniform Resource Identifier(URI):」 「ジェネリック構文と意味論」(RFC2396[1])は3を区分します。 ICAPによって定義されたURI構造はおよそ以下の通りです。
Elson & Cerpa Informational [Page 11] RFC 3507 ICAP April 2003
[11ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
ICAP_URI = Scheme ":" Net_Path [ "?" Query ]
「ICAP_URI=体系」:、」 ネット_経路[“?"質問]
Scheme = "icap"
体系="icap"
Net_Path = "//" Authority [ Abs_Path ]
「ネット_経路は」 //と等しい」という権威[腹筋_経路]
Authority = [ userinfo "@" ] host [ ":" port ]
権威=[userinfo"@"]ホスト[「:」 ポート]
ICAP adds the new scheme "icap" to the ones defined in RFC 2396. If the port is empty or not given, port 1344 is assumed. An example ICAP URI line might look like this:
ICAPは新しい体系"icap"をRFC2396で定義されたものに加えます。 ポートが人影がないか考えないで、ポート1344は想定されます。 例のICAP URI系列はこれに似るかもしれません:
icap://icap.example.net:2000/services/icap-service-1
icap://icap.example.net: icap2000/サービス/サービス1
An ICAP server MUST be able to recognize all of its hosts names, including any aliases, local variations, and numeric IP addresses of its interfaces.
ICAPサーバはホスト名のすべてを認識できなければなりません、インタフェースのどんな別名、地理的変異、および数値IPアドレスも含んでいて。
Any arguments that an ICAP client wishes to pass to an ICAP service to modify the nature of the service MAY be passed as part of the ICAP-URI, using the standard "?"-encoding of attribute-value pairs used in HTTP. For example:
ICAPクライアントがサービスの本質を変更するためにICAPサービスに通りたがっているというどんな主張もICAP-URIの一部として通過されるかもしれません、HTTPに使用される属性値組の標準の“?"-コード化を使用して。 例えば:
icap://icap.net/service?mode=translate&lang=french
icap://icap.net/サービス?モード=は翻訳されます、そして、langはフレンチと等しいです。
4.3 ICAP Headers
4.3 ICAPヘッダー
The following sections define the valid headers for ICAP messages. Section 4.3.1 describes headers common to both requests and responses. Request-specific and response-specific headers are described in Sections 4.3.2 and 4.3.3, respectively.
以下のセクションはICAPメッセージのために有効なヘッダーを定義します。 セクション4.3 .1 要求と応答の両方に共通のヘッダーについて説明します。 要求特有の、そして、応答特有のヘッダーはセクション4.3.2と4.3で説明されます。それぞれ.3。
User-defined header extensions are allowed. In compliance with the
precedent established by the Internet mail format [3] and later
adopted by HTTP [4], all user-defined headers MUST follow the "X-"
naming convention ("X-Extension-Header: Foo"). ICAP implementations
MAY ignore any "X-" headers without loss of compliance with the
protocol as defined in this document.
ユーザによって定義されたヘッダー拡大は許されています。 インターネットメール書式[3]によって確立されて、後でHTTP[4]によって採用された先例に従って、(「X-拡張ヘッダー: Foo」)とコンベンションを命名して、すべてのユーザによって定義されたヘッダーが「X」の後をつけなければなりません。 ICAP実装は本書では定義されるようにプロトコルへの承諾の損失なしでどんな「X」ヘッダーも無視するかもしれません。
Each header field consists of a name followed by a colon (":") and
the field value. Field names are case-insensitive. ICAP follows the
rules describe in section 4.2 of [4].
各ヘッダーフィールドがコロンがあとに続いた名前から成る、(「:」、)、そして、分野値。 フィールド名は大文字と小文字を区別しないです。 規則が[4]のセクション4.2で説明するICAP尾行。
4.3.1 Headers Common to Requests and Responses
4.3.1 要求と応答に共通のヘッダー
The headers of all ICAP messages MAY include the following directives, defined in ICAP the same as they are in HTTP:
すべてのICAPメッセージのヘッダーはHTTPにはそれらがあるのと同じICAPで定義された以下の指示を入れるかもしれません:
Elson & Cerpa Informational [Page 12] RFC 3507 ICAP April 2003
[12ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
Cache-Control
Connection
Date
Expires
Pragma
Trailer
Upgrade
キャッシュ制御接続日付はPragmaトレーラアップグレードを吐き出します。
Note in particular that the "Transfer-Encoding" option is not allowed. The special transfer-encoding requirements of ICAP bodies are described in Section 4.4.
「転送をコード化している」オプションが許容されていないことに特に注意してください。 ICAPボディーの特別な転送をコード化する要件はセクション4.4で説明されます。
The Upgrade header MAY be used to negotiate Transport-Layer Security on an ICAP connection, exactly as described for HTTP/1.1 in [4].
UpgradeヘッダーはICAP接続に関してTransport-層のSecurityを交渉するのに使用されるかもしれません、ちょうど[4]のHTTP/1.1のために説明されるように。
The ICAP-specific headers defined are:
定義されたICAP特有のヘッダーは以下の通りです。
Encapsulated (See Section 4.4)
要約します。(セクション4.4を見ます)
4.3.2 Request Headers
4.3.2 ヘッダーを要求してください。
Similar to HTTP, ICAP requests MUST start with a request line that contains a method, the complete URI of the ICAP resource being requested, and an ICAP version string. The current version number of ICAP is "1.0".
HTTPと同様です、ICAP要求はメソッドを含む要求系列、要求されているICAPリソースの完全なURI、およびICAPバージョンストリングから始まらなければなりません。 ICAPの最新版番号は「1インチ」です。
This version of ICAP defines three methods:
ICAPのこのバージョンは3つのメソッドを定義します:
REQMOD - for Request Modification (Section 4.8)
RESPMOD - for Response Modification (Section 4.9)
OPTIONS - to learn about configuration (Section 4.10)
REQMOD--Response Modification(セクション4.9)OPTIONSのためのRequest Modification(セクション4.8)RESPMODが構成に関して学ぶように(セクション4.10)
The OPTIONS method MUST be implemented by all ICAP servers. All other methods are optional and MAY be implemented.
すべてのICAPサーバでOPTIONSメソッドを実装しなければなりません。 他のすべてのメソッドが、任意であり、実装されるかもしれません。
User-defined extension methods are allowed. Before attempting to use an extension method, an ICAP client SHOULD use the OPTIONS method to query the ICAP server's list of supported methods; see Section 4.10. (If an ICAP server receives a request for an unknown method, it MUST give a 501 error response as described in the next section.)
ユーザによって定義された拡大メソッドは許容されています。 拡大メソッド、ICAPを使用するのを試みる前に、クライアントSHOULDはICAPサーバのサポートしているメソッドのリストについて質問するOPTIONSメソッドを使用します。 セクション4.10を見てください。 (ICAPサーバが未知のメソッドを求める要求を受け取るなら、それは次のセクションで説明されるように501誤り応答を与えなければなりません。)
Given the URI rules described in Section 4.2, a well-formed ICAP request line looks like the following example:
セクション4.2で説明されたURI規則を考えて、整形式のICAP要求系列は以下の例に似ています:
RESPMOD icap://icap.example.net/translate?mode=french ICAP/1.0
RESPMOD icap://icap.example.net/は翻訳されます--モードはフレンチICAP/1.0と等しいです。
Elson & Cerpa Informational [Page 13] RFC 3507 ICAP April 2003
[13ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
A number of request-specific headers are allowed in ICAP requests, following the same semantics as the corresponding HTTP request headers (Section 5.3 of [4]). These are:
多くの要求特有のヘッダーがICAP要求に許容されています、対応するHTTP要求ヘッダーと同じ意味論に従って。([4])のセクション5.3。 これらは以下の通りです。
Authorization
Allow (see Section 4.6)
From (see Section 14.22 of [4])
Host (REQUIRED in ICAP as it is in HTTP/1.1)
Referer (see Section 14.36 of [4])
User-Agent
承認Allow(セクション4.6を見る)、([4]) ホスト(HTTP/1.1にはそれとしてのICAPのREQUIREDがある)Refererのセクション14.22を見てください、([4]) ユーザエージェントのセクション14.36を見てください。
In addition to HTTP-like headers, there are also request headers unique to ICAP defined:
また、HTTPのようなヘッダーに加えて、定義されたICAPにユニークな要求ヘッダーがあります:
Preview (see Section 4.5)
プレビュー(セクション4.5を見ます)
4.3.3 Response Headers
4.3.3 応答ヘッダ
ICAP responses MUST start with an ICAP status line, similar in form to that used by HTTP, including the ICAP version and a status code. For example:
ICAP応答はICAP状況表示行から始まらなければなりません、フォームにおいてHTTPによって使用されるそれと同様です、ICAPバージョンとステータスコードを含んでいて。 例えば:
ICAP/1.0 200 OK
ICAP/1.0 200OK
Semantics of ICAP status codes in ICAP match the status codes defined by HTTP (Section 6.1.1 and 10 of [4]), except where otherwise indicated in this document; n.b. 100 (Section 4.5) and 204 (Section 4.6).
ICAPのICAPステータスコードの意味論はHTTPによって定義されたステータスコードに合っています。([4])について6.1に.1と10を区分して、本書では示されて、そうでないところで区分してください。 n. b。 100 (セクション4.5)と204(セクション4.6)。
ICAP error codes that differ from their HTTP counterparts are:
彼らのHTTP対応者と異なっているICAPエラーコードは以下の通りです。
100 - Continue after ICAP Preview (Section 4.5).
100--ICAPが(セクション4.5)を下見した後に続いてください。
204 - No modifications needed (Section 4.6).
204--どんな変更も(セクション4.6)を必要としませんでした。
400 - Bad request.
400--悪い要求。
404 - ICAP Service not found.
404--見つけられなかったICAP Service。
405 - Method not allowed for service (e.g., RESPMOD requested for
service that supports only REQMOD).
405--メソッドはサービス(例えばREQMODだけをサポートするサービスのために要求されたRESPMOD)を考慮しませんでした。
408 - Request timeout. ICAP server gave up waiting for a request
from an ICAP client.
408--タイムアウトを要求してください。 ICAPサーバは、ICAPクライアントからの要求を待つのをやめました。
500 - Server error. Error on the ICAP server, such as "out of disk
space".
500--サーバ誤り。 ICAPサーバにおける「椎間腔」などの誤り。
Elson & Cerpa Informational [Page 14] RFC 3507 ICAP April 2003
[14ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
501 - Method not implemented. This response is illegal for an
OPTIONS request since implementation of OPTIONS is mandatory.
501--実装されなかったメソッド。 OPTIONSの実装が義務的であるので、OPTIONS要求に、この応答は不法です。
502 - Bad Gateway. This is an ICAP proxy and proxying produced an
error.
502--悪いゲートウェイ。 これはICAPプロキシです、そして、proxyingは誤りを起こしました。
503 - Service overloaded. The ICAP server has exceeded a maximum
connection limit associated with this service; the ICAP client
should not exceed this limit in the future.
503--積みすぎられたサービス。 ICAPサーバはこのサービスに関連している最大の接続限界を超えていました。 ICAPクライアントは将来、この限界を超えるべきではありません。
505 - ICAP version not supported by server.
505--サーバによってサポートされなかったICAPバージョン。
As in HTTP, the 4xx class of error codes indicate client errors, and the 5xx class indicate server errors.
HTTPでは、エラーコードの4xxのクラスがクライアント誤りを示して、5xxのクラスがサーバ誤りを示すので。
ICAP's response-header fields allow the server to pass additional information in the response that cannot be placed in the ICAP's status line.
ICAPの応答ヘッダ分野で、サーバはICAPの状況表示行に置くことができない応答における追加情報を通過できます。
A response-specific header is allowed in ICAP requests, following the same semantics as the corresponding HTTP response headers (Section 6.2 of [4]). This is:
応答特有のヘッダーはICAP要求に許容されています、対応するHTTP応答ヘッダと同じ意味論に従って。([4])のセクション6.2。 これは以下の通りです。
Server (see Section 14.38 of [4])
サーバ([4])のセクション14.38を見てください。
In addition to HTTP-like headers, there is also a response header unique to ICAP defined:
また、HTTPのようなヘッダーに加えて、定義されたICAPにユニークな応答ヘッダがいます:
ISTag (see Section 4.7)
ISTag(セクション4.7を見ます)
4.3.4 ICAP-Related Headers in HTTP Messages
4.3.4 HTTPメッセージのICAP関連のヘッダー
When an ICAP-enabled HTTP surrogate makes an HTTP request to an origin server, it is often useful to advise the origin server of the surrogate's ICAP capabilities. Origin servers can use this information to modify its response accordingly. For example, an origin server may choose not to insert an advertisement into a page if it knows that a downstream ICAP server can insert the ad instead.
ICAPによって可能にされたHTTP代理がHTTP要求を発生源サーバにするとき、代理のICAP能力を発生源サーバに知らせるのはしばしば役に立ちます。 発生源サーバは、それに従って、応答を変更するのにこの情報を使用できます。 例えば、発生源サーバは、川下のICAPサーバが代わりに広告を載せることができるのを知っているなら1ページに広告を載せないのを選ぶかもしれません。
Although this ICAP specification can not mandate how HTTP is used in communication between HTTP clients and servers, we do suggest a convention: such headers (if used) SHOULD start with "X-ICAP". HTTP clients with ICAP services SHOULD minimally include an "X-ICAP- Version: 1.0" header along with their application-specific headers.
このICAP仕様はHTTPがHTTPクライアントとサーバとのコミュニケーションでどう使用されるかを強制できませんが、私たちはコンベンションを勧めます: そのようなヘッダー(使用されるなら)SHOULDは"X-ICAP"から始めます。 ICAPサービスSHOULDをもっているHTTPクライアントが最少量で入れる、「X-ICAPバージョン:」 彼らのアプリケーション特有のヘッダーに伴う1インチのヘッダー。
Elson & Cerpa Informational [Page 15] RFC 3507 ICAP April 2003
[15ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
4.4 ICAP Bodies: Encapsulation of HTTP Messages
4.4 ICAPボディー: HTTPメッセージのカプセル化
The ICAP encapsulation model is a lightweight means of packaging any number of HTTP message sections into an encapsulating ICAP message- body, in order to allow the vectoring of requests, responses, and request/response pairs to an ICAP server.
ICAPカプセル化モデルは要約ICAPメッセージへのいろいろなHTTPメッセージ部が具体化させるパッケージの軽量の手段です、要求、応答、および要求/応答組のベクトル決定をICAPサーバに許容するために。
This is accomplished by concatenating interesting message parts (encapsulatED sections) into a single ICAP message-body (the encapsulatING message). The encapsulated sections may be the headers or bodies of HTTP messages.
これは、単一のICAPメッセージボディー(encapsulatINGメッセージ)におもしろいメッセージ部分(encapsulatED部)を連結することによって、達成されます。 カプセル化されたセクションは、HTTPメッセージのヘッダーかボディーであるかもしれません。
Encapsulated bodies MUST be transferred using the "chunked" transfer-coding described in Section 3.6.1 of [4]. However, encapsulated headers MUST NOT be chunked. In other words, an ICAP message-body switches from being non-chunked to chunked as the body passes from the encapsulated header to encapsulated body section. (See Examples in Sections 4.8.3 and 4.9.3.). The motivation behind this decision is described in Section 8.2.
セクション3.6.1で説明された"chunkedする"の転送コード化を使用して、カプセル化されたボディーは[4]でわたっているに違いありません。 しかしながら、カプセル化されたヘッダーをchunkedしてはいけません。 言い換えれば、ICAPメッセージボディーはボディーがカプセル化されたヘッダーからカプセル化されたボディー部まで通りながらchunkedされるのに非chunkedされるのから切り替わります。 (.3にセクション4.8.3と4.9における例を見ます。) この決定の後ろの動機はセクション8.2で説明されます。
4.4.1 The "Encapsulated" Header
4.4.1 「カプセル化された」ヘッダー
The offset of each encapsulated section's start relative to the start of the encapsulating message's body is noted using the "Encapsulated" header. This header MUST be included in every ICAP message. For example, the header
「カプセル化された」ヘッダーを使用することで要約メッセージのボディーの始まりに比例したそれぞれのカプセル化されたセクションの始めのオフセットは注意されます。 あらゆるICAPメッセージにこのヘッダーを含まなければなりません。 例えば、ヘッダー
Encapsulated: req-hdr=0, res-hdr=45, res-body=100
カプセル化される: req-hdr=0、res-hdr=45、res-ボディー=100
indicates a message that encapsulates a group of request headers, a group of response headers, and then a response body. Each of these is included at the byte-offsets listed. The byte-offsets are in decimal notation for consistency with HTTP's Content-Length header.
要求ヘッダー、応答ヘッダのグループ、および次に、応答本体のグループをカプセル化するメッセージを示します。 それぞれのこれらは記載されたバイトオフセットのときに含まれています。 バイトオフセットがHTTPのContent-長さのヘッダーと共に一貫性のための10進法であります。
The special entity "null-body" indicates there is no encapsulated body in the ICAP message.
特別な実体「ヌルボディー」は、ICAPメッセージにはカプセル化されたボディーが全くないのを示します。
The syntax of an Encapsulated header is:
Encapsulatedヘッダーの構文は以下の通りです。
encapsulated_header: "Encapsulated: " encapsulated_list
encapsulated_list: encapsulated_entity |
encapsulated_entity ", " encapsulated_list
encapsulated_entity: reqhdr | reshdr | reqbody | resbody | optbody
reqhdr = "req-hdr" "=" (decimal integer)
reshdr = "res-hdr" "=" (decimal integer)
reqbody = { "req-body" | "null-body" } "=" (decimal integer)
resbody = { "res-body" | "null-body" } "=" (decimal integer)
optbody = { "opt-body" | "null-body" } "=" (decimal integer)
カプセル化された_ヘッダー: 「カプセル化されました」 「カプセル化された_リストは、_がリストであるとカプセル化しました」 _実体であるとカプセル化されます。| 「_実体であるとカプセル化され」て、「カプセル化された_リストは、_が実体であるとカプセル化しました」。 reqhdr| reshdr| reqbody| resbody| 「req-ボディー」| "res-hdr"「=」(10進整数)"req-hdr"「=」(10進整数)optbody reqhdr=reshdr=reqbody=「ヌルボディー」「=」(10進整数)resbodyが「res-ボディー」| 「ヌルボディー」「=」(10進整数)optbody=と等しい、「」 | ボディーを選んでいる「ヌルボディー」、「=」(10進整数)
Elson & Cerpa Informational [Page 16] RFC 3507 ICAP April 2003
[16ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
There are semantic restrictions on Encapsulated headers beyond the syntactic restrictions. The order in which the encapsulated parts appear in the encapsulating message-body MUST be the same as the order in which the parts are named in the Encapsulated header. In other words, the offsets listed in the Encapsulated line MUST be monotonically increasing. In addition, the legal forms of the Encapsulated header depend on the method being used (REQMOD, RESPMOD, or OPTIONS). Specifically:
意味制限はEncapsulatedヘッダーの上に構文の制限を超えています。 カプセル化された部品が要約メッセージ本体に現れるオーダーは部品がEncapsulatedヘッダーで命名されるオーダーと同じであるに違いありません。 言い換えれば、Encapsulated系列で記載されたオフセットは単調に増加しなければなりません。 さらに、Encapsulatedヘッダーの法令諸様式は使用されるメソッド(REQMOD、RESPMOD、またはOPTIONS)に依存します。 明確に:
REQMOD request encapsulated_list: [reqhdr] reqbody
REQMOD response encapsulated_list: {[reqhdr] reqbody} |
{[reshdr] resbody}
RESPMOD request encapsulated_list: [reqhdr] [reshdr] resbody
RESPMOD response encapsulated_list: [reshdr] resbody
OPTIONS response encapsulated_list: optbody
REQMODはカプセル化された_リストを要求します: [reqhdr]reqbody REQMOD応答は、_がリストであるとカプセル化しました: [reqhdr]reqbody| RESPMODが要求する[reshdr]resbodyは、_がリストであるとカプセル化しました: [reqhdr][reshdr]resbody RESPMOD応答は、_がリストであるとカプセル化しました: [reshdr]resbody OPTIONS応答は、_がリストであるとカプセル化しました: optbody
In the above grammar, note that encapsulated headers are always optional. At most one body per encapsulated message is allowed. If no encapsulated body is presented, the "null-body" header is used instead; this is useful because it indicates the length of the header section.
上の文法で、カプセル化されたヘッダーがいつも任意であることに注意してください。 高々、カプセル化されたメッセージあたり1つのボディーが許容されています。 カプセル化されたボディーが全く提示されないなら、「ヌルボディー」ヘッダーは代わりに使用されます。 ヘッダー部分の長さを示すので、これは役に立ちます。
Examples of legal Encapsulated headers:
法的なEncapsulatedヘッダーに関する例:
/* REQMOD request: This encapsulated HTTP request's headers start
* at offset 0; the HTTP request body (e.g., in a POST) starts
* at 412. */
Encapsulated: req-hdr=0, req-body=412
/*REQMODは以下を要求します。 このカプセル化されたHTTP要求のヘッダーはオフセット0時に*を始めます。 HTTP要求本体(例えば、ポストにおける)は412で*を始めます。 */は要約されました: req-hdr=0、req-ボディー=412
/* REQMOD request: Similar to the above, but no request body is
* present (e.g., a GET). We use the null-body directive instead.
* In both this case and the previous one, we can tell from the
* Encapsulated header that the request headers were 412 bytes
* long. */
Encapsulated: req-hdr=0, null-body=412
/*REQMODは以下を要求します。 上にもかかわらず、いいえ、要求本体と同様であるのは、*プレゼント(例えば、GET)です。 私たちは代わりにヌルボディー指示を使用します。 * 本件と前のものの両方では、私たちは、ヘッダーであるとカプセル化された*から要求ヘッダーが*長い間412バイトであったと言うことができます。 */は要約されました: req-hdr=0、ヌルボディーの=412
/* REQMOD response: ICAP server returned a modified request,
* with body */
Encapsulated: req-hdr=0, req-body=512
/*REQMOD応答: ICAPサーバはボディー*/カプセル化されると共に変更された要求、*を返しました: req-hdr=0、req-ボディー=512
/* RESPMOD request: Request headers at 0, response headers at 822,
* response body at 1655. Note that no request body is allowed in
* RESPMOD requests. */
Encapsulated: req-hdr=0, res-hdr=822, res-body=1655
/*RESPMODは以下を要求します。 822、1655年の*応答本体で0時のヘッダー、応答ヘッダを要求してください。 要求本体が全く*RESPMOD要求に許容されていないことに注意してください。 */は要約されました: req-hdr=0、res-hdr=822、res-ボディー=1655
/* RESPMOD or REQMOD response: header and body returned */ Encapsulated: res-hdr=0, res-body=749
/*RESPMODかREQMOD応答: ヘッダーとボディーは*/カプセル化された状態で戻りました: res-hdr=0、res-ボディー=749
Elson & Cerpa Informational [Page 17] RFC 3507 ICAP April 2003
[17ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
/* OPTIONS response when there IS an options body */ Encapsulated: opt-body=0
オプションボディー*/があるとき、/*OPTIONS応答は要約されました: ボディー=を選んでいる0
/* OPTIONS response when there IS NOT an options body */ Encapsulated: null-body=0
オプションボディー*/がないとき、/*OPTIONS応答は要約されました: ヌルボディーの=0
4.4.2 Encapsulated HTTP Headers
4.4.2 カプセル化されたHTTPヘッダ
By default, ICAP messages may encapsulate HTTP message headers and entity bodies. HTTP headers MUST start with the request-line or status-line for requests and responses, respectively, followed by interesting HTTP headers.
デフォルトで、ICAPメッセージは、HTTPがメッセージヘッダーと実体本体であるとカプセル化するかもしれません。 HTTPヘッダはおもしろいHTTPヘッダがそれぞれあとに続いた要求と応答のために要求系列か状況表示行から始まらなければなりません。
The encapsulated headers MUST be terminated by a blank line, in order to make them human readable, and in order to terminate line-by-line HTTP parsers.
空白行でカプセル化されたヘッダーを終えなければなりません、彼らを人間読み込み可能にして、1行ずつのHTTPパーサを終えるために。
HTTP/1.1 makes a distinction between end-to-end headers and hop-by- hop headers (see Section 13.5.1 of [4]). End-to-end headers are meaningful to the ultimate recipient of a message, whereas hop-by-hop headers are meaningful only for a single transport-layer connection. Hop-by-hop headers include Connection, Keep-Alive, and so forth. All end-to-end HTTP headers SHOULD be encapsulated, and all hop-by-hop headers MUST NOT be encapsulated.
HTTP/1.1は、終わりから終わりへのヘッダーの区別にaを作って、近く跳びホップをヘッダーに作ります。([4])についてセクション13.5.1を見てください。 メッセージの究極の受取人にとって、終わりから終わりへのヘッダーは重要ですが、単独のトランスポート層接続だけに、ホップごとのヘッダーは重要です。 ホップごとのヘッダーはConnection、生きているKeepなどを入れます。 すべての終わらせる終わりのHTTPヘッダSHOULDがカプセル化されて、ホップですべて跳びます。ヘッダーはカプセルに入れられてはいけません。
Despite the above restrictions on encapsulation, the hop-by-hop Proxy-Authenticate and Proxy-Authorization headers MUST be forwarded to the ICAP server in the ICAP header section (not the encapsulated message). This allows propagation of client credentials that might have been sent to the ICAP client in cases where the ICAP client is also an HTTP surrogate. Note that this does not contradict HTTP/1.1, which explicitly states "A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request." (Section 14.34).
カプセル化における上の制限、ホップごとにProxy認証して、ICAPヘッダー部分(カプセル化されたメッセージでない)のICAPサーバにProxy-承認ヘッダーを送らなければなりません。 これはまたICAPクライアントがそうである場合におけるICAPクライアントに送られたかもしれないクライアント資格証明書の伝播にHTTP代理を許容します。 これがHTTP/1.1に矛盾しないことに注意してください。(明らかに、1.1は「プロキシはそれがプロキシが協力して与えられた要求を認証するメカニズムであるならクライアント要求から次期プロキシまで資格証明書をリレーするかもしれません。」と述べます)。 (セクション14.34。)
The Via header of an encapsulated message SHOULD be modified by an ICAP server as if the encapsulated message were traveling through an HTTP surrogate. The Via header added by an ICAP server MUST specify protocol as ICAP/1.0.
変更されていて、ICAPサーバがまるでカプセル化することが通信するようであったというHTTP代理を通って旅行するカプセル化されたメッセージSHOULDのViaヘッダー。 ICAPサーバによって加えられたViaヘッダーはICAP/1.0としてプロトコルを指定しなければなりません。
4.5 Message Preview
4.5 メッセージプレビュー
ICAP REQMOD or RESPMOD requests sent by the ICAP client to the ICAP server may include a "preview". This feature allows an ICAP server to see the beginning of a transaction, then decide if it wants to
ICAPクライアントによってICAPサーバに送られたICAP REQMODかRESPMOD要求が「プレビュー」を含むかもしれません。 この特徴で、ICAPサーバをトランザクションの始まりを見て、次に、それがそうしたがっているかどうか決めます。
Elson & Cerpa Informational [Page 18] RFC 3507 ICAP April 2003
[18ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
opt-out of the transaction early instead of receiving the remainder of the request message. Previewing can yield significant performance improvements in a variety of situations, such as the following:
要求メッセージの残りを受け取ることの代わりに早くトランザクションから手を引いてください。 下見は以下などのさまざまな状況における顕著な性能改良をもたらすことができます:
- Virus-checkers can certify a large fraction of files as "clean"
just by looking at the file type, file name extension, and the
first few bytes of the file. Only the remaining files need to be
transmitted to the virus-checking ICAP server in their entirety.
- ウイルスチェックソフトは、まさしくファイルのファイルがタイプされるのを見る、ファイル名の拡張子、および最初の数バイトでファイルの大きい部分が「清潔である」と認証できます。 残っているファイルだけが、ウイルスをチェックするICAPサーバに全体として伝えられる必要があります。
- Content filters can use Preview to decide if an HTTP entity needs
to be inspected (the HTTP file type alone is not enough in cases
where "text" actually turns out to be graphics data). The magic
numbers at the front of the file can identify a file as a JPEG or
GIF.
- 満足しているフィルタは、HTTP実体が、点検される必要であるかどうか(HTTPファイルの種類だけが「テキスト」が実際にグラフィックスデータであると判明する場合に十分ではありません)決めるのにPreviewを使用できます。 ファイルの前部におけるマジックナンバーは、ファイルがJPEGかGIFであると認識できます。
- If an ICAP server wants to transcode all GIF87 files into GIF89
files, then the GIF87 files could quickly be detected by looking
at the first few body bytes of the file.
- ICAPサーバがGIF89ファイルの中へのすべてのGIF87ファイルを「移-コード」に必要とするなら、GIF87ファイルは、ファイルの最初のボディー数バイトを見ることによって、すぐに検出されるかもしれません。
- If an ICAP server wants to force all cacheable files to expire in
24 hours or less, then this could be implemented by selecting HTTP
messages with expiries more than 24 hours in the future.
- ICAPサーバが、すべての「キャッシュ-可能」ファイルを24時間以下後に期限が切れさせる必要があるなら、これは、将来、24時間以上expiriesでHTTPメッセージを選択することによって、実装されるかもしれません。
ICAP servers SHOULD use the OPTIONS method (see Section 4.10) to specify how many bytes of preview are needed for a particular ICAP application on a per-resource basis. Clients SHOULD be able to provide Previews of at least 4096 bytes. Clients furthermore SHOULD provide a Preview when using any ICAP resource that has indicated a Preview is useful. (This indication might be provided via the OPTIONS method, or some other "out-of-band" configuration.) Clients SHOULD NOT provide a larger Preview than a server has indicated it is willing to accept.
ICAPサーバSHOULDはいくつのバイトのプレビューが1リソースあたり1個のベースで特定のICAPアプリケーションに必要であるかを指定するOPTIONSメソッド(セクション4.10を見る)を使用します。 クライアントSHOULD、少なくとも4096バイトのPreviewsを提供できてください。 クライアント、Previewが役に立つのを示したどんなICAPリソースも使用するとき、その上、SHOULDはPreviewを提供します。 (OPTIONSメソッド、または「バンドの外」というある他の構成でこの指示を提供するかもしれません。) クライアントSHOULD NOTはサーバが、受け入れても構わないと思っているのを示したより大きいPreviewを提供します。
To effect a Preview, an ICAP client MUST add a "Preview:" header to its request headers indicating the length of the preview. The ICAP client then sends:
Previewに作用するように、ICAPクライアントは、aが「以下を下見する」と言い足さなければなりません。 プレビューの長さを示す要求ヘッダーへのヘッダー。 次に、ICAPクライアントは発信します:
- all of the encapsulated header sections, and
- そしてカプセル化されたヘッダー部分のすべて。
- the beginning of the encapsulated body section, if any, up to the
number of bytes advertised in the Preview (possibly 0).
- もしあればPreview(ことによると0)の広告に掲載されたバイト数までのカプセル化されたボディー部の始まり。
After the Preview is sent, the client stops and waits for an intermediate response from the ICAP server before continuing. This mechanism is similar to the "100-Continue" feature found in HTTP, except that the stop-and-wait point can be within the message body. In contrast, HTTP requires that the point must be the boundary between the headers and body.
Previewを送った後に、クライアントは、続く前に、ICAPサーバから中間的応答を止めて、待ちます。 このメカニズムが同様である、「100、-続いてください、」 特徴によって、それを除いたHTTPでメッセージ本体の中に停止と待ちポイントがあることができるのがわかりました。 対照的に、HTTPは、ポイントがヘッダーとボディーの間の境界であるに違いないことを必要とします。
Elson & Cerpa Informational [Page 19] RFC 3507 ICAP April 2003
[19ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
For example, to effect a Preview consisting of only encapsulated HTTP headers, the ICAP client would add the following header to the ICAP request:
例えば、カプセル化されたHTTPヘッダだけから成るPreviewに作用するように、ICAPクライアントは以下のヘッダーをICAP要求に追加するでしょう:
Preview: 0
以下を下見してください。 0
This indicates that the ICAP client will send only the encapsulated header sections to the ICAP server, then it will send a zero-length chunk and stop and wait for a "go ahead" to send more encapsulated body bytes to the ICAP server.
これが、ICAPクライアントがカプセル化されたヘッダー部分だけをICAPサーバに送るのを示して、次に、それは、ゼロ・レングス塊を送って、止まって、「前方に行ってください」がICAPサーバにより多くのカプセル化されたボディーバイト発信するのを待つでしょう。
Similarly, the ICAP header:
同様である、ICAPヘッダー:
Preview: 4096
以下を下見してください。 4096
Indicates that the ICAP client will attempt to send 4096 bytes of origin server data in the encapsulated body of the ICAP request to the ICAP server. It is important to note that the actual transfer may be less, because the ICAP client is acting like a surrogate and is not looking ahead to find the total length of the origin server response. The entire ICAP encapsulated header section(s) will be sent, followed by up to 4096 bytes of encapsulated HTTP body. The chunk body terminator "0\r\n\r\n" is always included in these transactions.
ICAPクライアントは、ICAP要求のカプセル化されたボディーで4096バイトの発生源サーバデータをICAPサーバに送るのを試みるでしょう。ICAPクライアントが代理のように行動していて、発生源サーバ応答の全長を見つけるために前を見ていないので、実際の転送が、より少ないかもしれないことに注意するのが重要であることを示します。 最大4096バイトのカプセル化されたHTTP本体があとに続いていて、ヘッダー部分であるとカプセル化された全体のICAPを送るでしょう。 塊ボディーターミネータ「0円r\n円r\n」はいつもこれらの取引において含まれています。
After sending the preview, the ICAP client will wait for a response from the ICAP server. The response MUST be one of the following:
プレビューを送った後に、ICAPクライアントはICAPサーバから応答を待っています。応答は以下の1つであるに違いありません:
- 204 No Content. The ICAP server does not want to (or can not)
modify the ICAP client's request. The ICAP client MUST treat this
the same as if it had sent the entire message to the ICAP server
and an identical message was returned.
- 204 内容がありません。 または、ICAPサーバがそうしたがっていない、()、ICAPクライアントの要求を変更できてください。 まるで全体のメッセージをICAPサーバに送ったかのようにICAPクライアントはこの同じくらいを扱わなければなりません、そして、同じメッセージを返しました。
- ICAP reqmod or respmod response, depending what method was the
original request. See Section 4.8.2 and 4.9.2 for the format of
reqmod and respmod responses.
- どんなメソッドがオリジナルの要求であったかによるICAP reqmodかrespmod応答。 セクション4.8.2と4.9を見てください。.2 reqmodとrespmod応答の形式のために。
- 100 Continue. If the entire encapsulated HTTP body did not fit
in the preview, the ICAP client MUST send the remainder of its
ICAP message, starting from the first chunk after the preview. If
the entire message fit in the preview (detected by the "EOF"
symbol explained below), then the ICAP server MUST NOT respond
with 100 Continue.
- 100は続きます。 全体のカプセル化されたHTTP本体がプレビューをうまくはめ込まなかったなら、ICAPクライアントはICAPメッセージの残りを送らなければなりません、プレビューの後に最初の塊から始めて。 全体のメッセージがプレビュー(以下で説明された"EOF"シンボルで、検出される)をうまくはめ込んだなら、サーバが100で反応させてはいけないICAPは続きます。
When an ICAP client is performing a preview, it may not yet know how many bytes will ultimately be available in the arriving HTTP message that it is relaying to the HTTP server. Therefore, ICAP defines a way for ICAP clients to indicate "EOF" to ICAP servers if one
ICAPクライアントがプレビューを実行しているとき、それは、いくつのバイトが結局それがHTTPサーバにリレーしている到着しているHTTPメッセージで有効になるかをまだ知っていないかもしれません。したがって、ICAPは1であるならICAPクライアントが"EOF"をICAPサーバに示す方法を定義します。
Elson & Cerpa Informational [Page 20] RFC 3507 ICAP April 2003
[20ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
unexpectedly arrives during the preview process. This is a particularly useful optimization if a header-only HTTP response arrives at the ICAP client (i.e., zero bytes of body); only a single round trip will be needed for the complete ICAP server response.
不意に、プレビュープロセスの間、到着します。 ヘッダーだけHTTP応答がICAPクライアントに到着するなら(すなわち、バイトのボディーのゼロを合わせてください)、これは特に役に立つ最適化です。 単発旅行だけが完全なICAPサーバ応答に必要でしょう。
We define an HTTP chunk-extension of "ieof" to indicate that an ICAP chunk is the last chunk (see [4]). The ICAP server MUST strip this chunk extension before passing the chunk data to an ICAP application process.
私たちはICAP塊が最後の塊であることを示す"ieof"のHTTP塊拡大を定義します。([4])を見てください。 塊データをICAPアプリケーション・プロセスに通過する前に、ICAPサーバはこの塊拡大を剥取らなければなりません。
For example, consider an ICAP client that has just received HTTP response headers from an origin server and initiates an ICAP RESPMOD transaction to an ICAP server. It does not know yet how many body bytes will be arriving from the origin server because the server is not using the Content-Length header. The ICAP client informs the ICAP server that it will be sending a 1024-byte preview using a "Preview: 1024" request header. If the HTTP origin server then closes its connection to the ICAP client before sending any data (i.e., it provides a zero-byte body), the corresponding zero-byte preview for that zero-byte origin response would appear as follows:
例えば、発生源サーバからHTTP応答ヘッダをちょうど受け取って、ICAPサーバにICAP RESPMODトランザクションを開始するICAPクライアントを考えてください。それは、サーバがContent-長さのヘッダーを使用していないのでいくつのボディーバイトが発生源サーバから到着するかをまだ知っていません。 ICAPクライアントは、「以下を下見してください」というaを使用することで1024年のバイトのプレビューを送って、ことであることをICAPサーバに知らせます。 「1024」はヘッダーを要求します。 次に、どんなデータも送る前にHTTP発生源サーバがICAPクライアントに接続を終えるなら(すなわち、それは無バイト本体を提供します)、その無バイト発生源応答のための対応する無バイトプレビューは以下の通りに見えるでしょう:
\r\n
0; ieof\r\n\r\n
\、r n0円。 ieof\r\n円r\n
If an ICAP server sees this preview, it knows from the presence of "ieof" that the client will not be sending any more chunk data. In this case, the server MUST respond with the modified response or a 204 No Content message right away. It MUST NOT send a 100-Continue response in this case. (In contrast, if the origin response had been 1 byte or larger, the "ieof" would not have appeared. In that case, an ICAP server MAY reply with 100-Continue, a modified response, or 204 No Content.)
ICAPサーバがこのプレビューを見るなら、それは、"ieof"の存在からクライアントがそれ以上の塊データを送らないのを知っています。 この場合、サーバはすぐ、変更された応答か204いいえContentメッセージで反応しなければなりません。 aを送ってはいけない、100、-続いてください、この場合、応答。 (対照的に、発生源応答が1バイト以上であったなら、"ieof"は現れなかったでしょうに。 その場合、ICAPサーバが返答するかもしれない、100、-続いてください、変更された応答、または204ノーContent。)
In another example, if the preview is 1024 bytes and the origin response is 1024 bytes in two chunks, then the encapsulation would appear as follows:
別の例では、カプセル化はプレビューが1024バイトであり、発生源応答が2つの塊で1024バイトであるなら以下の通りに見えるでしょう:
200\r\n
<512 bytes of data>\r\n
200\r\n
<512 bytes of data>\r\n
0; ieof\r\n\r\n
データ>\r n200円の\r\n<の200\r円nの<512バイト、512バイトのデータ>\r\n、0。 ieof\r\n円r\n
<204 or modified response> (100 Continue disallowed due to ieof)
<204か変更された応答>。(100は禁じられた支払われるべきものをieofに続けています)
If the preview is 1024 bytes and the origin response is 1025 bytes (and the ICAP server responds with 100-continue), then these chunks would appear on the wire:
そして、プレビューが1024バイトであり、発生源応答が1025バイトである、(ICAPサーバが応じる、100、-続いてください、)、次に、これらの塊はワイヤの上に現れるでしょう:
Elson & Cerpa Informational [Page 21] RFC 3507 ICAP April 2003
[21ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
200\r\n
<512 bytes of data>\r\n
200\r\n
<512 bytes of data>\r\n
0\r\n
データ>\r n200円の\r\n<の200\r円nの<512バイト、512バイトのデータ>\r n0円\r\、n
<100 Continue Message>
<100はメッセージ>を続けています。
1\r\n
<1 byte of data>\r\n
0\r\n\r\n <no ieof because we are no longer in preview mode>
私たちがもう少しも中にいないので、1円rの\n<、1バイトのデータ>\r n0円の\r\n\r\n<ノーieofはモード>を下見します。
Once the ICAP server receives the eof indicator, it finishes reading the current chunk stream.
ICAPサーバがいったんeofインディケータを受けると、それは、現在の塊ストリームを読み終えます。
Note that when offering a Preview, the ICAP client is committing to temporarily buffer the previewed portion of the message so that it can honor a "204 No Content" response. The remainder of the message is not necessarily buffered; it might be pipelined directly from another source to the ICAP server after a 100-Continue.
Previewを提供するとき、ICAPクライアントが「204いいえ内容」応答を光栄に思うことができるように一時メッセージの下見された部分をバッファリングするように公約していることに注意してください。 メッセージの残りは必ずバッファリングされるというわけではありません。 それが直接別のソースからICAPサーバまで後aであることでpipelinedされるかもしれない、100、-続いてください。
4.6 "204 No Content" Responses outside of Previews
4.6 Previewsの外の「204いいえ内容」Responses
An ICAP client MAY choose to honor "204 No Content" responses for an entire message. This is the decision of the client because it imposes a burden on the client of buffering the entire message.
ICAPクライアントは、全体のメッセージのための「204いいえ内容」応答を光栄に思うのを選ぶかもしれません。 全体のメッセージをバッファリングするクライアントの上で負担をかけるので、これはクライアントの決定です。
An ICAP client MAY include "Allow: 204" in its request headers, indicating that the server MAY reply to the message with a "204 No Content" response if the object does not need modification.
ICAPクライアントは「以下を許容してください」を入れるかもしれません。 「204」 要求ヘッダーでは、サーバがオブジェクトであるなら「204いいえ内容」応答でメッセージに答えるかもしれないのを示すのが変更を必要としません。
If an ICAP server receives a request that does not have "Allow: 204", it MUST NOT reply with a 204. In this case, an ICAP server MUST return the entire message back to the client, even though it is identical to the message it received.
ICAPサーバが要求を受け取るなら、それには、「以下を許容してください」がありません。 「204」 それは204で返答してはいけません。 この場合、ICAPサーバは全体のメッセージをクライアントに返して戻さなければなりません、それが受け取ったメッセージと同じですが。
The ONLY EXCEPTION to this rule is in the case of a message preview, as described in the previous section. If this is the case, an ICAP server can respond with a 204 No Content message in response to a message preview EVEN if the original request did not have the "Allow: 204" header.
メッセージプレビューの場合にはこの規則へのONLY EXCEPTIONが前項で説明されるようにあります。 これがそうであり、オリジナルの要求に「以下を許容してください」がなかったなら、ICAPサーバは204いいえContentメッセージでメッセージプレビューEVENに対応して反応できます。 「204」ヘッダー。
4.7 ISTag Response Header
4.7 ISTag応答ヘッダ
The ISTag ("ICAP Service Tag") response-header field provides a way
for ICAP servers to send a service-specific "cookie" to ICAP clients
that represents a service's current state. It is a 32-byte-maximum
alphanumeric string of data (not including the null character) that
ISTag(「ICAPサービスタグ」)応答ヘッダ分野はICAPサーバがICAPクライアントへのサービスの現状を表すサービス特有の「クッキー」を送る方法を提供します。 それが32バイトの最大の英数字の一連のデータ(ヌル文字を含んでいなくて)である、それ
Elson & Cerpa Informational [Page 22] RFC 3507 ICAP April 2003
[22ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
may, for example, be a representation of the software version or configuration of a service. An ISTag validates that previous ICAP server responses can still be considered fresh by an ICAP client that may be caching them. If a change on the ICAP server invalidates previous responses, the ICAP server can invalidate portions of the ICAP client's cache by changing its ISTag. The ISTag MUST be included in every ICAP response from an ICAP server.
例えば、サービスのソフトウェアバージョンか構成の表現であるかもしれません。 それらをキャッシュしているかもしれないICAPクライアントで新鮮な状態で考えられて、ISTagはまだその前のICAPサーバ応答缶を有効にしています。 ICAPサーバの変化が前の応答を無効にするなら、ICAPサーバは、ISTagを変えることによって、ICAPクライアントのキャッシュの部分を無効にすることができます。 あらゆるICAP応答にICAPサーバからISTagを含まなければなりません。
For example, consider a virus-scanning ICAP service. The ISTag might be a combination of the virus scanner's software version and the release number of its virus signature database. When the database is updated, the ISTag can be changed to invalidate all previous responses that had been certified as "clean" and cached with the old ISTag.
例えば、ウイルスをスキャンするICAPがサービスであると考えてください。 ISTagはウイルス・スキャナーのソフトウェアバージョンの組み合わせとウイルス署名データベースのリリース番号であるかもしれません。 データベースをアップデートするとき、「清潔であること」が公認されて、古いISTagと共にキャッシュされた前のすべての応答を無効にするためにISTagを変えることができます。
ISTag is similar, but not identical, to the HTTP ETag. While an ETag is a validator for a particular entity (object), an ISTag validates all entities generated by a particular service (URI). A change in the ISTag invalidates all the other entities provided a service with the old ISTag, not just the entity whose response contained the updated ISTag.
ISTagは同様ですが、HTTP ETagと同じではありません。 ETagは特定の実体(オブジェクト)のためのvalidatorですが、ISTagは特定のサービス(URI)で生成されたすべての実体を有効にします。 ISTagにおける変化は応答がアップデートされたISTagを含んだ実体だけではなく、他の実体が古いISTagとのサービスを提供したすべてを無効にします。
The syntax of an ISTag is simply:
ISTag = "ISTag: " quoted-string
ISTagの構文は単に以下の通りです。 ISTagが等しい、「ISTag:」 「引用文字列」
In this document we use the quoted-string definition defined in section 2.2 of [4].
本書では私たちは[4]のセクション2.2で定義された引用文字列定義を使用します。
For example:
ISTag: "874900-1994-1c02798"
例えば: ISTag: 「874900-1994-1 c02798」
4.8 Request Modification Mode
4.8 要求変更モード
In this method, described in Section 3.1, an ICAP client sends an HTTP request to an ICAP server. The ICAP server returns a modified version of the request, an HTTP response, or (if the client indicates it supports 204 responses) an indication that no modification is required.
セクション3.1で説明されたこのメソッドで、ICAPクライアントはHTTP要求をICAPサーバに送ります。ICAPサーバは要求の変更されたバージョン、HTTP応答、または変更が全く必要でないという(クライアントが、204の応答をサポートするのを示すなら)指示を返します。
4.8.1 Request
4.8.1 要求
In REQMOD mode, the ICAP request MUST contain an encapsulated HTTP request. The headers and body (if any) MUST both be encapsulated, except that hop-by-hop headers are not encapsulated.
REQMODモードで、ICAP要求はカプセル化されたHTTP要求を含まなければなりません。 ホップごとのヘッダーがカプセルに入れられないのを除いて、ともに、ヘッダーとボディー(もしあれば)をカプセルに入れらなければなりません。
Elson & Cerpa Informational [Page 23] RFC 3507 ICAP April 2003
[23ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
4.8.2 Response
4.8.2 応答
The response from the ICAP server back to the ICAP client may take one of four forms:
ICAPサーバからICAPクライアントまでの応答は4つのフォームの1つを取るかもしれません:
- An error indication,
- 誤り表示
- A 204 indicating that the ICAP client's request requires no
adaptation (see Section 4.6 for limitations of this response),
- ICAPクライアントの要求が適合(この応答の制限に関してセクション4.6を見る)を全く必要としないのを示す204
- An encapsulated, adapted version of the ICAP client's request, or
- またはICAPクライアントの要求のカプセル化されて、適合しているバージョン。
- An encapsulated HTTP error response. Note that Request
Modification requests may only be satisfied with HTTP responses in
cases when the HTTP response is an error (e.g., 403 Forbidden).
- カプセル化されたHTTP誤り応答。 HTTP応答が誤り(例えば、403Forbidden)であるときにだけ、Request Modification要求が場合におけるHTTP応答に満たされるかもしれないことに注意してください。
The first line of the response message MUST be a status line as described in Section 4.3.3. If the return code is a 2XX, the ICAP client SHOULD continue its normal execution of the request. If the ICAP client is a surrogate, this may include serving an object from its cache or forwarding the modified request to an origin server. Note it is valid for a 2XX ICAP response to contain an encapsulated HTTP error response, which in turn should be returned to the downstream client by the ICAP client.
応答メッセージの最初の系列はセクション4.3.3で説明されるように状況表示行であるに違いありません。 復帰コードが2XXであるなら、ICAPクライアントSHOULDは要求の通常の実行を続けています。 ICAPクライアントが代理であるなら、これは、キャッシュからオブジェクトに役立つか、または変更された要求を発生源サーバに転送するのを含むかもしれません。2XX ICAP応答がICAPクライアントによって順番に川下のクライアントに返されるべきであるカプセル化されたHTTP誤り応答を含むのが、有効であることに注意してください。
For other return codes that indicate an error, the ICAP client MAY (for example) return the error to the downstream client or user, execute the unadapted request as it arrived from the client, or re- try the adaptation again.
誤りを示す他の復帰コードのために、ICAPクライアントは、(例えば) 川下のクライアントかユーザに誤りを返すか、クライアントから到着したので「非-適合させ」られた要求を実行するか、または再び適合を再試みるかもしれません。
The modified request headers, if any, MUST be returned to the ICAP client using appropriate encapsulation as described in Section 4.4.
セクション4.4で説明されるように適切なカプセル化を使用して、もしあれば変更された要求ヘッダーをICAPクライアントに返さなければなりません。
4.8.3 Examples
4.8.3 例
Consider the following example, in which a surrogate receives a simple GET request from a client. The surrogate, acting as an ICAP client, then forwards this request to an ICAP server for modification. The ICAP server modifies the request headers and sends them back to the ICAP client. Our hypothetical ICAP server will modify several headers and strip the cookie from the original request.
以下の例を考えてください。そこでは、代理がクライアントから簡単なGET要求を受け取ります。 そして、ICAPクライアントとして機能して、代理は変更のためのICAPサーバにこの要求を転送します。 ICAPサーバは、要求ヘッダーを変更して、ICAPクライアントに彼らを送り返します。 私たちの仮定しているICAPサーバは、オリジナルの要求から数個のヘッダーを変更して、クッキーを剥取るでしょう。
In all of our examples, we include the extra meta-data added to the message due to chunking the encapsulated message body (if any). We assume that end-of-line terminations, and blank lines, are two-byte "CRLF" sequences.
例では、全部で、私たちはカプセル化されたメッセージが具体化させる(もしあれば)分魂化のためメッセージに追加された付加的なメタデータを入れます。 私たちは、行末終了、および空白行が2バイトの"CRLF"系列であると思います。
Elson & Cerpa Informational [Page 24] RFC 3507 ICAP April 2003
[24ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
ICAP Request Modification Example 1 - ICAP Request ---------------------------------------------------------------- REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0 Host: icap-server.net Encapsulated: req-hdr=0, null-body=170
ICAP要求変更の例1--ICAP要求---------------------------------------------------------------- REQMOD icap://icap-server.net/サーバ?arg=87 ICAP/1.0Host: icap-server.net Encapsulated: req-hdr=0、ヌルボディーの=170
GET / HTTP/1.1 Host: www.origin-server.com Accept: text/html, text/plain Accept-Encoding: compress Cookie: ff39fk3jur@4ii0e02i If-None-Match: "xyzzy", "r2d2xxxx"
/ HTTP/1.1ホストを手に入れてください: www.origin-server.com Accept: テキスト/html、テキスト/明瞭なAccept-コード化: Cookieを圧縮してください: ff39fk3jur@4ii0e02i 、なにも合っていないなら: "xyzzy"、"r2d2xxxx"
---------------------------------------------------------------- ICAP Request Modification Example 1 - ICAP Response ---------------------------------------------------------------- ICAP/1.0 200 OK Date: Mon, 10 Jan 2000 09:55:21 GMT Server: ICAP-Server-Software/1.0 Connection: close ISTag: "W3E4R7U9-L2E4-2" Encapsulated: req-hdr=0, null-body=231
---------------------------------------------------------------- ICAP要求変更の例1--ICAP応答---------------------------------------------------------------- ICAP/1.0 200OK日付: グリニッジ標準時2000年1月10日月曜日9時55分21秒のサーバ: ICAPサーバソフトウェア/1.0接続: ISTagを閉じてください: 「W3E4R7U9-L2E4-2インチは要約されました」 req-hdr=0、ヌルボディーの=231
GET /modified-path HTTP/1.1 Host: www.origin-server.com Via: 1.0 icap-server.net (ICAP Example ReqMod Service 1.1) Accept: text/html, text/plain, image/gif Accept-Encoding: gzip, compress If-None-Match: "xyzzy", "r2d2xxxx"
変更された経路HTTP/1.1が接待する/を手に入れてください: www.origin-server.com Via: (ICAP Example ReqMod Service1.1)が受け入れる1.0icap-server.net: テキスト/明瞭で、gif Acceptをイメージ/コード化しているテキスト/html: gzip、なにも合わせないIfを圧縮してください: "xyzzy"、"r2d2xxxx"
----------------------------------------------------------------
----------------------------------------------------------------
The second example is similar to the first, except that the request being modified in this case is a POST instead of a GET. Note that the encapsulated Content-Length argument has been modified to reflect the modified body of the POST message. The outer ICAP message does not need a Content-Length header because it uses chunking (not shown).
2番目の例は1日と同様です、この場合変更される要求がGETの代わりにポストであるのを除いて。 カプセル化されたContent-長さの議論がポストメッセージの変更されたボディーを反映するように変更されたことに注意してください。 分魂化(目立たない)を使用するので、外側のICAPメッセージはContent-長さのヘッダーを必要としません。
In this second example, the Encapsulated header shows the division between the forwarded header and forwarded body, for both the request and the response.
この2番目の例では、Encapsulatedヘッダーは進められたヘッダーと進められたボディーの間の分割を見せています、要求と応答の両方のために。
ICAP Request Modification Example 2 - ICAP Request ---------------------------------------------------------------- REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0 Host: icap-server.net Encapsulated: req-hdr=0, req-body=147
ICAP要求変更の例2--ICAP要求---------------------------------------------------------------- REQMOD icap://icap-server.net/サーバ?arg=87 ICAP/1.0Host: icap-server.net Encapsulated: req-hdr=0、req-ボディー=147
Elson & Cerpa Informational [Page 25] RFC 3507 ICAP April 2003
[25ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
POST /origin-resource/form.pl HTTP/1.1 Host: www.origin-server.com Accept: text/html, text/plain Accept-Encoding: compress Pragma: no-cache
発生源ポスト/リソース/form.pl HTTP/1.1ホスト: www.origin-server.com Accept: テキスト/html、テキスト/明瞭なAccept-コード化: Pragmaを圧縮してください: キャッシュがありません。
1e I am posting this information. 0
この情報を掲示する1e。 0
---------------------------------------------------------------- ICAP Request Modification Example 2 - ICAP Response ---------------------------------------------------------------- ICAP/1.0 200 OK Date: Mon, 10 Jan 2000 09:55:21 GMT Server: ICAP-Server-Software/1.0 Connection: close ISTag: "W3E4R7U9-L2E4-2" Encapsulated: req-hdr=0, req-body=244
---------------------------------------------------------------- ICAP要求変更の例2--ICAP応答---------------------------------------------------------------- ICAP/1.0 200OK日付: グリニッジ標準時2000年1月10日月曜日9時55分21秒のサーバ: ICAPサーバソフトウェア/1.0接続: ISTagを閉じてください: 「W3E4R7U9-L2E4-2インチは要約されました」 req-hdr=0、req-ボディー=244
POST /origin-resource/form.pl HTTP/1.1 Host: www.origin-server.com Via: 1.0 icap-server.net (ICAP Example ReqMod Service 1.1) Accept: text/html, text/plain, image/gif Accept-Encoding: gzip, compress Pragma: no-cache Content-Length: 45
発生源ポスト/リソース/form.pl HTTP/1.1ホスト: www.origin-server.com Via: (ICAP Example ReqMod Service1.1)が受け入れる1.0icap-server.net: テキスト/明瞭で、gif Acceptをイメージ/コード化しているテキスト/html: gzip、Pragmaを圧縮してください: Content-長さをキャッシュしないでください: 45
2d I am posting this information. ICAP powered! 0
この情報を掲示する2d。 動かされたICAP! 0
---------------------------------------------------------------- Finally, this third example shows an ICAP server returning an error response when it receives a Request Modification request.
---------------------------------------------------------------- 最終的に、この3番目の例は、Request Modification要求を受け取るとき、ICAPサーバが誤り応答を返すのを示します。
ICAP Request Modification Example 3 - ICAP Request ---------------------------------------------------------------- REQMOD icap://icap-server.net/content-filter ICAP/1.0 Host: icap-server.net Encapsulated: req-hdr=0, null-body=119
ICAP要求変更の例3--ICAP要求---------------------------------------------------------------- 満足しているREQMOD icap://icap-server.net/フィルタICAP/1.0Host: icap-server.net Encapsulated: req-hdr=0、ヌルボディーの=119
GET /naughty-content HTTP/1.1 Host: www.naughty-site.com Accept: text/html, text/plain Accept-Encoding: compress
下品の内容HTTP/1.1が接待する/を手に入れてください: www.naughty-site.com Accept: テキスト/html、テキスト/明瞭なAccept-コード化: 湿布
----------------------------------------------------------------
----------------------------------------------------------------
Elson & Cerpa Informational [Page 26] RFC 3507 ICAP April 2003
[26ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
ICAP Request Modification Example 3 - ICAP Response ---------------------------------------------------------------- ICAP/1.0 200 OK Date: Mon, 10 Jan 2000 09:55:21 GMT Server: ICAP-Server-Software/1.0 Connection: close ISTag: "W3E4R7U9-L2E4-2" Encapsulated: res-hdr=0, res-body=213
ICAP要求変更の例3--ICAP応答---------------------------------------------------------------- ICAP/1.0 200OK日付: グリニッジ標準時2000年1月10日月曜日9時55分21秒のサーバ: ICAPサーバソフトウェア/1.0接続: ISTagを閉じてください: 「W3E4R7U9-L2E4-2インチは要約されました」 res-hdr=0、res-ボディー=213
HTTP/1.1 403 Forbidden Date: Wed, 08 Nov 2000 16:02:10 GMT Server: Apache/1.3.12 (Unix) Last-Modified: Thu, 02 Nov 2000 13:51:37 GMT ETag: "63600-1989-3a017169" Content-Length: 58 Content-Type: text/html
HTTP/1.1 403の禁制の日付: グリニッジ標準時2000年11月8日水曜日16時2分10秒のサーバ: アパッチ/1.3.12(unix)最終更新日: グリニッジ標準時2000年11月2日木曜日13時51分37秒ETag: 「63600-1989-3 a017169」コンテンツの長さ: 58コンテントタイプ: テキスト/html
3a Sorry, you are not allowed to access that naughty content. 0
3a、すみません、あなたはその下品の内容にアクセスできません。 0
----------------------------------------------------------------
----------------------------------------------------------------
4.9 Response Modification Mode
4.9 応答変更モード
In this method, described in Section 3.2, an ICAP client sends an origin server's HTTP response to an ICAP server, and (if available) the original client request that caused that response. Similar to Request Modification method, the response from the ICAP server can be an adapted HTTP response, an error, or a 204 response code indicating that no adaptation is required.
セクション3.2で説明されたこのメソッドで、ICAPクライアントはICAPサーバへの発生源サーバのHTTP応答、およびその応答を引き起こした(利用可能であるなら)オリジナルのクライアント要求を送ります。 Request Modificationメソッドと同様です、ICAPサーバからの応答は、適合は全く必要でないことを示す適合しているHTTP応答、誤り、または204応答コードであるかもしれません。
4.9.1 Request
4.9.1 要求
Using encapsulation described in Section 4.4, the header and body of the HTTP response to be modified MUST be included in the ICAP body. If available, the header of the original client request SHOULD also be included. As with the other method, the hop-by-hop headers of the encapsulated messages MUST NOT be forwarded. The Encapsulated header MUST indicate the byte-offsets of the beginning of each of these four parts.
ICAPボディーに変更されるためにHTTP応答のセクション4.4、ヘッダー、およびボディーで説明されたカプセル化を使用するのを含まなければなりません。 利用可能であるなら、また、含まれていて、オリジナルのクライアントのヘッダーはSHOULDを要求します。 もう片方のメソッドでホップごとのカプセル化されたメッセージのヘッダーを進めてはいけないので。 Encapsulatedヘッダーはそれぞれのこれらの4つの部品の始まりのバイトオフセットを示さなければなりません。
4.9.2 Response
4.9.2 応答
The response from the ICAP server looks just like a reply in the Request Modification method (Section 4.8); that is,
Request Modificationメソッド(セクション4.8)でICAPサーバからの応答はまさしく回答に似ています。 that is,
- An error indication,
- 誤り表示
Elson & Cerpa Informational [Page 27] RFC 3507 ICAP April 2003
[27ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
- An encapsulated and potentially modified HTTP response header and
response body, or
- またはカプセル化された、潜在的に変更されたHTTP応答ヘッダと応答本体。
- An HTTP response 204 indicating that the ICAP client's request
requires no adaptation.
- それを示すHTTP応答204は適合を全く必要としませんICAPクライアントのものが、要求する。
The first line of the response message MUST be a status line as described in Section 4.3.3. If the return code is a 2XX, the ICAP client SHOULD continue its normal execution of the response. The ICAP client MAY re-examine the headers in the response's message headers in order to make further decisions about the response (e.g., its cachability).
応答メッセージの最初の系列はセクション4.3.3で説明されるように状況表示行であるに違いありません。 復帰コードが2XXであるなら、ICAPクライアントSHOULDは応答の通常の実行を続けています。 ICAPクライアントは、さらに応答に関する決定を(例えば、cachability)にするように応答のメッセージヘッダーでヘッダーを再検討するかもしれません。
For other return codes that indicate an error, the ICAP client SHOULD NOT return these directly to downstream client, since these errors only make sense in the ICAP client/server transaction.
誤りを示す他の復帰コードのために、ICAPクライアントSHOULD NOTは直接川下のクライアントにこれらを返します、これらの誤りがICAPクライアント/サーバトランザクションで理解できるだけであるので。
The modified response headers, if any, MUST be returned to the ICAP client using appropriate encapsulation as described in Section 4.4.
セクション4.4で説明されるように適切なカプセル化を使用して、もしあれば変更された応答ヘッダをICAPクライアントに返さなければなりません。
4.9.3 Examples
4.9.3 例
In Example 4, an ICAP client is requesting modification of an entity that was returned as a result of a client GET. The original client GET was to an origin server at "www.origin-server.com"; the ICAP server is at "icap.example.org".
Example4では、ICAPクライアントはクライアントGETの結果、返された実体の変更を要求しています。 発生源サーバにはオリジナルのクライアントGETが"www.origin-server.com"にありました。 ICAPサーバが"icap.example.org"にあります。
ICAP Response Modification Example 4 - ICAP Request ---------------------------------------------------------------- RESPMOD icap://icap.example.org/satisf ICAP/1.0 Host: icap.example.org Encapsulated: req-hdr=0, res-hdr=137, res-body=296
ICAP応答変更の例4--ICAP要求---------------------------------------------------------------- RESPMOD icap://icap.example.org/satisf ICAP/1.0Host: icap.example.org Encapsulated: req-hdr=0、res-hdr=137、res-ボディー=296
GET /origin-resource HTTP/1.1 Host: www.origin-server.com Accept: text/html, text/plain, image/gif Accept-Encoding: gzip, compress
発生源リソースHTTP/1.1が接待する/を手に入れてください: www.origin-server.com Accept: テキスト/明瞭で、gif Acceptをイメージ/コード化しているテキスト/html: gzip、湿布
HTTP/1.1 200 OK Date: Mon, 10 Jan 2000 09:52:22 GMT Server: Apache/1.3.6 (Unix) ETag: "63840-1ab7-378d415b" Content-Type: text/html Content-Length: 51
HTTP/1.1 200OK日付: グリニッジ標準時2000年1月10日月曜日9時52分22秒のサーバ: アパッチ/1.3.6(unix)ETag: 「63840-1 ab7-378d415b」コンテントタイプ: html Contentテキスト/長さ: 51
Elson & Cerpa Informational [Page 28] RFC 3507 ICAP April 2003
[28ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
33 This is data that was returned by an origin server. 0
33 これは発生源サーバ0時までに返されたデータです。
----------------------------------------------------------------
----------------------------------------------------------------
ICAP Response Modification Example 4 - ICAP Response ---------------------------------------------------------------- ICAP/1.0 200 OK Date: Mon, 10 Jan 2000 09:55:21 GMT Server: ICAP-Server-Software/1.0 Connection: close ISTag: "W3E4R7U9-L2E4-2" Encapsulated: res-hdr=0, res-body=222
ICAP応答変更の例4--ICAP応答---------------------------------------------------------------- ICAP/1.0 200OK日付: グリニッジ標準時2000年1月10日月曜日9時55分21秒のサーバ: ICAPサーバソフトウェア/1.0接続: ISTagを閉じてください: 「W3E4R7U9-L2E4-2インチは要約されました」 res-hdr=0、res-ボディー=222
HTTP/1.1 200 OK Date: Mon, 10 Jan 2000 09:55:21 GMT Via: 1.0 icap.example.org (ICAP Example RespMod Service 1.1) Server: Apache/1.3.6 (Unix) ETag: "63840-1ab7-378d415b" Content-Type: text/html Content-Length: 92
HTTP/1.1 200OK日付: 以下を通ってグリニッジ標準時2000年1月10日月曜日9時55分21秒 1.0icap.example.org(ICAP Example RespMod Service1.1)サーバ: アパッチ/1.3.6(unix)ETag: 「63840-1 ab7-378d415b」コンテントタイプ: html Contentテキスト/長さ: 92
5c This is data that was returned by an origin server, but with value added by an ICAP server. 0
5c、これ. 発生源サーバで返しましたが、ICAPサーバによる付加価値で返したデータは0です。
----------------------------------------------------------------
----------------------------------------------------------------
4.10 OPTIONS Method
4.10 オプションメソッド
The ICAP "OPTIONS" method is used by the ICAP client to retrieve configuration information from the ICAP server. In this method, the ICAP client sends a request addressed to a specific ICAP resource and receives back a response with options that are specific to the service named by the URI. All OPTIONS requests MAY also return options that are global to the server (i.e., apply to all services).
ICAP「オプション」メソッドは、ICAPサーバからの設定情報を検索するのにICAPクライアントによって使用されます。このメソッドで、ICAPクライアントは、特定のICAPリソースに扱われた要求を送って、URIによって指定されたサービスに特定のオプションで応答を受け返します。 また、すべてのOPTIONS要求がサーバにグローバルなオプションを返すかもしれません(すなわち、すべてのサービスに適用してください)。
4.10.1 OPTIONS Request
4.10.1 オプション要求
The OPTIONS method consists of a request-line, as described in Section 4.3.2, such as the following example:
OPTIONSメソッドは以下の.2のセクション4.3の例などで説明されるように要求系列から成ります:
OPTIONS icap://icap.server.net/sample-service ICAP/1.0 User-Agent: ICAP-client-XYZ/1.001
サンプルOPTIONS icap://icap.server.net/サービスICAP/1.0User-エージェント: ICAPクライアントXYZ/1.001
Elson & Cerpa Informational [Page 29] RFC 3507 ICAP April 2003
[29ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
Other headers are also allowed as described in Section 4.3.1 and Section 4.3.2 (for example, Host).
また、他のヘッダーはセクション4.3.1とセクション4.3.2(例えば、Host)で説明されるように許容されています。
4.10.2 OPTIONS Response
4.10.2 オプション応答
The OPTIONS response consists of a status line as described in section 4.3.3 followed by a series of header field names-value pairs optionally followed by an opt-body. Multiple values in the value field MUST be separated by commas. If an opt-body is present in the OPTIONS response, the Opt-body-type header describes the format of the opt-body.
OPTIONS応答が値を命名している組が任意に続いたヘッダーフィールドのシリーズがあとに続いていて、セクション4.3.3で説明されるように状況表示行から成る、ボディーを選びます。 コンマで値の分野の複数の値を切り離さなければなりません。 Optボディータイプヘッダーは、ボディーを選ぶのが、OPTIONS応答でプレゼントであると形式を説明します。ボディーを選びます。
The OPTIONS headers supported in this version of the protocol are:
プロトコルのこのバージョンで支えられたOPTIONSヘッダーは以下の通りです。
-- Methods:
-- メソッド:
The method that is supported by this service. This header MUST be
included in the OPTIONS response. The OPTIONS method MUST NOT be
in the Methods' list since it MUST be supported by all the ICAP
server implementations. Each service should have a distinct URI
and support only one method in addition to OPTIONS (see Section
6.4).
このサービスでサポートされるメソッド。 OPTIONS応答にこのヘッダーを含まなければなりません。 OPTIONSメソッドが、すべてのICAPサーバ実装でそれをサポートしなければならないので、Methodsのリストにあるはずがありません。 各サービスは、異なったURIを持って、OPTIONSに加えた1つのメソッドだけをサポートするべきです(セクション6.4を見てください)。
For example:
Methods: RESPMOD
例えば: メソッド: RESPMOD
-- Service:
-- サービス:
A text description of the vendor and product name. This header
MAY be included in the OPTIONS response.
ベンダーと製品名のテキスト記述。 このヘッダーはOPTIONS応答に含まれるかもしれません。
For example:
Service: XYZ Technology Server 1.0
例えば: サービス: XYZ技術サーバ1.0
-- ISTag:
-- ISTag:
See section 4.7 for details. This header MUST be included in the
OPTIONS response.
詳細に関してセクション4.7を見てください。 OPTIONS応答にこのヘッダーを含まなければなりません。
For example:
ISTag: "5BDEEEA9-12E4-2"
例えば: ISTag: 「5BDEEEA9-12E42インチ」
-- Encapsulated:
-- カプセル化される:
This header MUST be included in the OPTIONS response; see Section
4.4.
OPTIONS応答にこのヘッダーを含まなければなりません。 セクション4.4を見てください。
Elson & Cerpa Informational [Page 30] RFC 3507 ICAP April 2003
[30ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
For example:
Encapsulated: opt-body=0
例えば: カプセル化される: ボディー=を選んでいる0
-- Opt-body-type:
-- ボディータイプを選んでください:
A token identifying the format of the opt-body. (Valid opt-body
types are not defined by ICAP.) This header MUST be included in
the OPTIONS response ONLY if an opt-body type is present.
形式を特定するトークン、ボディーを選びます。 (有効なボディーを選んでいるタイプはICAPによって定義されません。) ボディーを選んでいるタイプが出席しているだけであるなら、OPTIONS応答にこのヘッダーを含まなければなりません。
For example:
Opt-body-type: XML-Policy-Table-1.0
例えば: ボディータイプを選んでください: XML方針テーブル1.0
-- Max-Connections:
-- マックス-コネクションズ:
The maximum number of ICAP connections the server is able to
support. This header MAY be included in the OPTIONS response.
サーバがサポートすることができるICAP接続の最大数。 このヘッダーはOPTIONS応答に含まれるかもしれません。
For example:
Max-Connections: 1500
例えば: マックス-コネクションズ: 1500
-- Options-TTL:
-- オプション-TTL:
The time (in seconds) for which this OPTIONS response is valid.
If none is specified, the OPTIONS response does not expire. This
header MAY be included in the OPTIONS response. The ICAP client
MAY reissue an OPTIONS request once the Options-TTL expires.
このOPTIONS応答が有効である時(秒の)。 なにも指定されないなら、OPTIONS応答は期限が切れません。 このヘッダーはOPTIONS応答に含まれるかもしれません。 Options-TTLがいったん期限が切れると、ICAPクライアントはOPTIONS要求を再発行するかもしれません。
For example:
Options-TTL: 3600
例えば: オプション-TTL: 3600
-- Date:
-- 日付:
The server's clock, specified as an RFC 1123 compliant date/time
string. This header MAY be included in the OPTIONS response.
RFC1123対応することの日付/時間ストリングとして指定されたサーバの時計。 このヘッダーはOPTIONS応答に含まれるかもしれません。
For example:
Date: Fri, 15 Jun 2001 04:33:55 GMT
例えば: 日付: グリニッジ標準時2001年6月15日金曜日4時33分55秒
-- Service-ID:
-- サービスID:
A short label identifying the ICAP service. It MAY be used in
attribute header names. This header MAY be included in the
OPTIONS response.
ICAPサービスを特定する脆いラベル。 それは属性ヘッダー名に使用されるかもしれません。 このヘッダーはOPTIONS応答に含まれるかもしれません。
For example:
Service-ID: xyztech
例えば: サービスID: xyztech
Elson & Cerpa Informational [Page 31] RFC 3507 ICAP April 2003
[31ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
-- Allow:
-- 許容します:
A directive declaring a list of optional ICAP features that this
server has implemented. This header MAY be included in the
OPTIONS response. In this document we define the value "204" to
indicate that the ICAP server supports a 204 response.
このサーバが実装した任意のICAPの特徴のリストを宣言する指示。 このヘッダーはOPTIONS応答に含まれるかもしれません。 本書では私たちは、ICAPサーバが204応答をサポートするのを示すために値「204」を定義します。
For example:
Allow: 204
例えば: 許容します: 204
-- Preview:
-- 以下を下見してください。
The number of bytes to be sent by the ICAP client during a
preview. This header MAY be included in the OPTIONS response.
プレビューの間にICAPクライアントによって送られるバイト数。 このヘッダーはOPTIONS応答に含まれるかもしれません。
For example:
Preview: 1024
例えば: 以下を下見してください。 1024
-- Transfer-Preview:
-- 転送プレビュー:
A list of file extensions that should be previewed to the ICAP
server before sending them in their entirety. This header MAY be
included in the OPTIONS response. Multiple file extensions values
should be separated by commas. The wildcard value "*" specifies
the default behavior for all the file extensions not specified in
any other Transfer-* header (see below).
それらを全体として送る前にICAPサーバに下見されるべきであるファイル拡張子のリスト。 このヘッダーはOPTIONS応答に含まれるかもしれません。 複数のファイル拡張子値がコンマによって切り離されるべきです。 ワイルドカード値の「*」はいかなる他の転送*ヘッダーでも指定されたというわけではないすべてのファイル拡張子のためのデフォルトの振舞いを指定します(以下を見てください)。
For example:
Transfer-Preview: *
例えば: 転送プレビュー: *
-- Transfer-Ignore:
-- 以下を転送で無視してください。
A list of file extensions that should NOT be sent to the ICAP
server. This header MAY be included in the OPTIONS response.
Multiple file extensions should be separated by commas.
. ICAPサーバへのこのヘッダーに送られるべきでないファイル拡張子のリストはOPTIONS応答に含まれるかもしれません。 複数のファイル拡張子がコンマによって切り離されるべきです。
For example:
Transfer-Ignore: html
例えば: 以下を転送で無視してください。 html
-- Transfer-Complete:
-- 転送完全:
A list of file extensions that should be sent in their entirety
(without preview) to the ICAP server. This header MAY be included
in the OPTIONS response. Multiple file extensions values should
be separated by commas.
ICAPサーバに全体として(プレビューなしで)送って. このヘッダーがOPTIONS応答に含まれるかもしれないということであるべきであるファイル拡張子のリスト。 複数のファイル拡張子値がコンマによって切り離されるべきです。
For example:
Transfer-Complete: asp, bat, exe, com, ole
例えば: 転送完全: エジプトコブラ、バット、exe、com、ole
Elson & Cerpa Informational [Page 32] RFC 3507 ICAP April 2003
[32ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
Note: If any of Transfer-* are sent, exactly one of them MUST contain the wildcard value "*" to specify the default. If no Transfer-* are sent, all responses will be sent in their entirety (without Preview).
以下に注意してください。 もしあれば、ちょうどそれらの1つは、Transfer-*を送って、デフォルトを指定するためにワイルドカード値の「*」を含まなければなりません。 Transfer-*を全く送らないと、すべての応答を全体として(Previewなしで)送るでしょう。
4.10.3 OPTIONS Examples
4.10.3 オプションの例
In example 5, an ICAP Client sends an OPTIONS Request to an ICAP Service named icap.server.net/sample-service in order to get configuration information for the service provided.
例5では、ICAP Clientはサービスのための設定情報を提供させるためにサンプルicap.server.net/サービスというICAP ServiceにOPTIONS Requestを送ります。
ICAP OPTIONS Example 5 - ICAP OPTIONS Request ---------------------------------------------------------------- OPTIONS icap://icap.server.net/sample-service ICAP/1.0 Host: icap.server.net User-Agent: BazookaDotCom-ICAP-Client-Library/2.3
ICAPは例5をゆだねます--ICAPは要求をゆだねます。---------------------------------------------------------------- サンプルOPTIONS icap://icap.server.net/サービスICAP/1.0Host: icap.server.net User-エージェント: BazookaDotCom-ICAPクライアント図書館/2.3
----------------------------------------------------------------
----------------------------------------------------------------
ICAP OPTIONS Example 5 - ICAP OPTIONS Response ---------------------------------------------------------------- ICAP/1.0 200 OK Date: Mon, 10 Jan 2000 09:55:21 GMT Methods: RESPMOD Service: FOO Tech Server 1.0 ISTag: "W3E4R7U9-L2E4-2" Encapsulated: null-body=0 Max-Connections: 1000 Options-TTL: 7200 Allow: 204 Preview: 2048 Transfer-Complete: asp, bat, exe, com Transfer-Ignore: html Transfer-Preview: *
ICAPは例5をゆだねます--ICAPは応答をゆだねます。---------------------------------------------------------------- ICAP/1.0 200OK日付: グリニッジ標準時2000年1月10日月曜日9時55分21秒のメソッド: RESPMODサービス: FOOの科学技術のサーバ1.0ISTag: 「W3E4R7U9-L2E4-2インチは要約されました」 ヌルボディーの=0マックス-コネクションズ: 1000オプション-TTL: 7200 許容します: 204プレビュー: 2048 転送完全: エジプトコブラ、バット、exeは以下をcom Transfer無視します。 html Transfer-プレビュー: *
----------------------------------------------------------------
----------------------------------------------------------------
5. Caching
5. キャッシュ
ICAP servers' responses MAY be cached by ICAP clients, just as any other surrogate might cache HTTP responses. Similar to HTTP, ICAP clients MAY always store a successful response (see sections 4.8.2 and 4.9.2) as a cache entry, and MAY return it without validation if it is fresh. ICAP servers use the caching directives described in HTTP/1.1 [4].
ICAPサーバの応答5月がICAPクライアントによってキャッシュされて、ちょうどいかなる他の代理もキャッシュするかもしれないようにHTTP応答をキャッシュしてください。 HTTPと同様です、ICAPクライアントがいつもうまくいっている応答を保存するかもしれない、(セクション4.8 .2と4.9を見てください、.2)、aはエントリーをキャッシュして、それが新鮮であるなら、合法化なしでそれを返すかもしれません。 ICAPサーバは指示がHTTP/1.1[4]で説明したキャッシュを使用します。
In Request Modification mode, the ICAP server MAY include caching directives in the ICAP header section of the ICAP response (NOT in the encapsulated HTTP request of the ICAP message body). In Response
Request Modificationモードでは、ICAPサーバは、ICAP応答(ICAPメッセージボディーのカプセル化されたHTTP要求でないのにおける)のICAPヘッダー部分で指示をキャッシュするのを含むかもしれません。 応答で
Elson & Cerpa Informational [Page 33] RFC 3507 ICAP April 2003
[33ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
Modification mode, the ICAP server MAY add or modify the HTTP caching directives located in the encapsulated HTTP response (NOT in the ICAP header section). Consequently, the ICAP client SHOULD look for caching directives in the ICAP headers in case of REQMOD, and in the encapsulated HTTP response in case of RESPMOD.
変更モード、ICAPサーバはカプセル化されたHTTP応答(ICAPヘッダー部分でないところの)で位置する指示をキャッシュするHTTPを、加えるか、または変更するかもしれません。 その結果、ICAPクライアントSHOULDは、RESPMODの場合にREQMODの場合のICAPヘッダー、およびカプセル化されたHTTP応答における指示をキャッシュするのを見ます。
In cases where an ICAP server returns a modified version of an object created by an origin server, such as in Response Modification mode, the expiration of the ICAP-modified object MUST NOT be longer than that of the origin object. In other words, ICAP servers MUST NOT extend the lifetime of origin server objects, but MAY shorten it.
ICAPサーバがResponse Modificationモードなどの発生源サーバによって作成されたオブジェクトの変更されたバージョンを返す場合では、それより長い間、ICAPによって変更されたオブジェクトの満了は発生源オブジェクトのものであるはずがありません。 言い換えれば、ICAPサーバは、発生源サーバオブジェクトの生涯を広げてはいけませんが、それを短くするかもしれません。
In cases where the ICAP server is the authoritative source of an ICAP response, such as in Request Modification mode, the ICAP server is not restricted in its expiration policy.
ICAPサーバがRequest ModificationモードなどのICAP応答の権威筋である場合では、ICAPサーバは満了方針で制限されません。
Note that the ISTag response-header may also be used to providing caching hints to clients; see Section 4.7.
また、ISTag応答ヘッダがクライアントにヒントをキャッシュしながら提供するのに慣れるかもしれないことに注意してください。 セクション4.7を見てください。
6. Implementation Notes
6. 実装注意
6.1 Vectoring Points
6.1 ベクトル決定ポイント
The definition of the ICAP protocol itself only describes two different adaptation channels: modification (and satisfaction) of requests, and modifications of replies. However, an ICAP client implementation is likely to actually distinguish among four different classes of adaptation:
ICAPプロトコル自体の定義は2個の異なった適合チャンネルしか説明しません: 要求の変更(そして、満足)、および回答の変更。 しかしながら、ICAPクライアント実装は実際に適合の4つの異なったクラスで区別しそうです:
1. Adaptation of client requests. This is adaptation done every
time a request arrives from a client. This is adaptation done
when a request is "on its way into the cache". Factors such as
the state of the objects currently cached will determine whether
or not this request actually gets forwarded to an origin server
(instead of, say, getting served off the cache's disk). An
example of this type of adaptation would be special access
control or authentication services that must be performed on a
per-client basis.
1. クライアント要求の適合。 これは要求がクライアントから到着するときはいつも、行われた適合です。 これは「要求はキャッシュに近づいているとき」行われた適合です。 現在キャッシュされているオブジェクトの状態などの要素は、この要求が実際に発生源サーバ(たとえば、キャッシュのディスクで役立たれることの代わりに)に送られるかどうか決定するでしょう。 このタイプの適合に関する例は、1クライアントあたり1個のベースに実行しなければならない特別なアクセスコントロールか認証サービスでしょう。
2. Adaptation of requests on their way to an origin server.
Although this type of adaptation is also an adaptation of
requests similar to (1), it describes requests that are "on their
way out of the cache"; i.e., if a request actually requires that
an origin server be contacted. These adaptation requests are not
necessarily specific to particular clients. An example would be
addition of "Accept:" headers for special devices; these
adaptations can potentially apply to many clients.
2. 適合、発生源サーバへの途中での要求. また、このタイプの適合は(1)と同様の要求の適合ですが、「キャッシュから近づいています」要求について説明します。 すなわち、要求が、実際に発生源サーバが連絡されるのを必要とするなら。 特定のクライアントには、これらの適合要求は必ず特定であるというわけではありません。 例は「受け入れてください」の追加でしょう。 特別なデバイスのためのヘッダー。 潜在的にこれらの適合は多くのクライアントに適用できます。
Elson & Cerpa Informational [Page 34] RFC 3507 ICAP April 2003
[34ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
3. Adaptations of responses coming from an origin server. This is
the adaptation of an object "on its way into the cache". In
other words, this is adaptation that a surrogate might want to
perform on an object before caching it. The adapted object may
subsequently served to many clients. An example of this type of
adaptation is virus checking: a surrogate will want to check an
incoming origin reply for viruses once, before allowing it into
the cache -- not every time the cached object is served to a
client.
3. 適合、発生源サーバからの応答到来では. これは「キャッシュに途中の」オブジェクトの適合です。 言い換えれば、これはそれをキャッシュする前に代理がオブジェクトに実行したがっているかもしれない適合です。 適合しているオブジェクトは次に、多くのクライアントにサービスされていた状態でそうするかもしれません。 このタイプの適合に関する例はウイルスの照合です: 代理はウイルスがないかどうか一度入って来る発生源回答をチェックしたくなるでしょう、キャッシュされたオブジェクトがクライアントにサービスされているたびにキャッシュにそれを許容する前に。
Adaptation of responses coming from the surrogate, heading back
to the client. Although this type of adaptation, like (3), is
the adaptation of a response, it is client-specific. Client
reply adaptation is adaptation that is required every time an
object is served to a client, even if all the replies come from
the same cached object off of disk. Ad insertion is a common
form of this kind of adaptation; e.g., if a popular (cached)
object that rarely changes needs a different ad inserted into it
every time it is served off disk to a client. Note that the
relationship between adaptations of type (3) and (4) is analogous
to the relationship between types (2) and (1).
クライアントに向かって戻って、代理から来る応答の適合。 (3)のように、このタイプの適合は応答の適合ですが、それはクライアント特有です。 クライアント回答適合はオブジェクトがクライアントにサービスされているときはいつも、必要である適合です、すべての回答が同じキャッシュされたオブジェクトからディスクから来ても。 広告挿入は一般的な形式のこの種類の適合です。 例えば、めったに変化しないポピュラーな(キャッシュされる)オブジェクトが、毎回異なった広告をそれに載せる必要があるなら、それはディスクでクライアントにサービスされています。 タイプ(3)と(4)の適合の間の関係がタイプ(2)と(1)の間の関係に類似していることに注意してください。
Although the distinction among these four adaptation points is critical for ICAP client implementations, the distinction is not significant for the ICAP protocol itself. From the point of view of an ICAP server, a request is a request -- the ICAP server doesn't care what policy led the ICAP client to generate the request. We therefore did not make these four channels explicit in ICAP for simplicity.
ICAPクライアント実装に、これらの4適合ポイントの中の区別は重要ですが、ICAPプロトコル自体には、区別は重要ではありません。 ICAPサーバの観点から、要求は要求です--ICAPサーバは、どんな方針が、ICAPクライアントが要求を生成するように導いたかを気にかけません。 したがって、私たちはこれらの4個のチャンネルをICAPで簡単さに明白にしませんでした。
6.2 Application Level Errors
6.2 アプリケーションレベル誤り
Section 4 described "on the wire" protocol errors that MUST be standardized across implementations to ensure interoperability. In this section, we describe errors that are communicated between ICAP software and the clients and servers on which they are implemented. Although such errors are implementation dependent and do not necessarily need to be standardized because they are "within the box", they are presented here as advice to future implementors based on past implementation experience.
セクション4は「ワイヤ」で相互運用性を確実にするために実装の向こう側に標準化しなければならないプロトコル誤りについて説明しました。 このセクションで、私たちはICAPソフトウェアとクライアントの間で伝えられる誤りとそれらが実装されるサーバについて説明します。 そのような誤りは、実装に依存していて、必ずそれらが「箱」にあるので標準化される必要があるというわけではありませんが、それらはアドバイスとしてここに過去の実装経験に基づく将来の作成者に提示されます。
Elson & Cerpa Informational [Page 35] RFC 3507 ICAP April 2003
[35ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
Error name Value ==================================================== ICAP_CANT_CONNECT 1000 ICAP_SERVER_RESPONSE_CLOSE 1001 ICAP_SERVER_RESPONSE_RESET 1002 ICAP_SERVER_UNKNOWN_CODE 1003 ICAP_SERVER_UNEXPECTED_CLOSE_204 1004 ICAP_SERVER_UNEXPECTED_CLOSE 1005
エラー名Value==================================================== ICAP_合言葉_は1004年の予期していなかった近い1000年の1001年の1002年の近いICAP_サーバのICAP_サーバ_未知の__応答_ICAP_サーバ_応答_リセットコード1003のICAP_サーバ_予期していなかった_ICAP_サーバ___204閉鎖1005を接続します。
1000 ICAP_CANT_CONNECT:
"Cannot connect to ICAP server".
1000 ICAP_合言葉_は接続します: 「ICAPサーバに接続できません。」
The ICAP server is not connected on the socket. Maybe the ICAP
server is dead or it is not connected on the socket.
ICAPサーバはソケットに接続されません。 多分、ICAPサーバが死んでいるか、またはそれはソケットに接続されません。
1001 ICAP_SERVER_RESPONSE_CLOSE:
"ICAP Server closed connection while reading response".
1001年のICAP_サーバ_応答_は閉じます: 「ICAP Serverは応答を読む間、接続を終えました。」
The ICAP server TCP-shutdowns the connection before the ICAP
client can send all the body data.
ICAPクライアントの前での接続がすべてのボディーデータを送ることができるICAPサーバTCP-閉鎖。
1002 ICAP_SERVER_RESPONSE_RESET:
"ICAP Server reset connection while reading response".
1002年のICAP_サーバ_応答_は以下をリセットします。 「ICAP Serverは応答を読んでいる間、接続をリセットしました。」
The ICAP server TCP-reset the connection before the ICAP client
can send all the body data.
ICAPクライアントがすべてのボディーデータを送ることができる前にICAPサーバは接続をTCPリセットしました。
1003 ICAP_SERVER_UNKNOWN_CODE:
"ICAP Server sent unknown response code".
1003年のICAP_サーバの_の未知の_コード: 「ICAP Serverは未知の応答コードを送りました。」
An unknown ICAP response code (see Section 4.x) was received by
the ICAP client.
未知のICAP応答コード(セクション4.xを見る)はICAPクライアントによって受け取られました。
1004 ICAP_SERVER_UNEXPECTED_CLOSE_204:
"ICAP Server closed connection on 204 without 'Connection: close'
header".
_の予期していなかった1004年のICAP_サーバ_は_204を閉じます: 「ICAP Serverは'接続なしで204に接続を引けた'、」 「''ヘッダーを閉じてください。」
An ICAP server MUST send the "Connection: close" header if
intends to close after the current transaction.
ICAPサーバが発信しなければならない、「接続:」 「近い」ヘッダー、経常取引の後に閉じるつもりです。
1005 ICAP_SERVER_UNEXPECTED_CLOSE:
"ICAP Server closed connection as ICAP client wrote body
preview".
_の予期していなかった1005年のICAP_サーバ_は閉じます: 「ICAPクライアントがボディープレビューを書いたとき、ICAP Serverは接続を終えました。」
Elson & Cerpa Informational [Page 36] RFC 3507 ICAP April 2003
[36ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
6.3 Use of Chunked Transfer-Encoding
6.3 Chunked転送コード化の使用
For simplicity, ICAP messages MUST use the "chunked" transfer- encoding within the encapsulated body section as defined in HTTP/1.1 [4]. This requires that ICAP client implementations convert incoming objects "on the fly" to chunked from whatever transfer-encoding on which they arrive. However, the transformation is simple:
簡単さのために、ICAPメッセージはHTTP/1.1[4]で定義されるようにカプセル化されたボディー部の中で"chunkedする"の転送コード化を使用しなければなりません。 これは、ICAPクライアント実装が「急いで」それらが到着するいかなる転送コード化からもchunkedされるのに入って来るオブジェクトを変換するのを必要とします。 しかしながら、変換は簡単です:
- For objects arriving using "Content-Length" headers, one big chunk
can be created of the same size as indicated in the Content-Length
header.
- 「コンテンツの長さ」ヘッダーを使用することで届くオブジェクトに関しては、Content-長さのヘッダーにみられるように同じサイズについて1つの大きい塊を作成できます。
- For objects arriving using a TCP close to signal the end of the
object, each incoming group of bytes read from the OS can be
converted into a chunk (by writing the length of the bytes read,
followed by the bytes themselves)
- オブジェクトの端に合図するのに近くでTCPを使用することで届くオブジェクトに関しては、OSから読まれたバイトのそれぞれの入って来るグループを塊に変換できます。(書くことによる読まれたバイトの長さバイト自体があとに続いていて、
- For objects arriving using chunked encoding, they can be
retransmitted as is (without re-chunking).
- chunkedコード化を使用することで届くオブジェクトに関しては、そのままで(再分魂化なしで)それらを再送できます。
6.4 Distinct URIs for Distinct Services
6.4 異なったサービスのための異なったURI
ICAP servers SHOULD assign unique URIs to each service they provide, even if such services might theoretically be differentiated based on their method. In other words, a REQMOD and RESPMOD service should never have the same URI, even if they do something that is conceptually the same.
ICAPサーバSHOULDはそれらが提供する各サービスにユニークなURIを割り当てます、そのようなサービスがそれらのメソッドに基づいて理論的に差別化されるかもしれなくても。 言い換えれば、REQMODとRESPMODサービスには、同じURIが決してあるべきではありません、彼らが概念的に何か同じことをしても。
This situation in ICAP is similar to that found in HTTP where it might, in theory, be possible to perform a GET or a POST to the same URI and expect two different results. This kind of overloading of URIs only causes confusion and should be avoided.
ICAPのこの状況は同じURIにGETかポストを実行して、2つの異なった結果を予想するのが理論上可能であるかもしれないHTTPで見つけられたそれと同様です。 この種類のURIの積みすぎだけが、混乱を引き起こして、避けられるべきです。
7. Security Considerations
7. セキュリティ問題
7.1 Authentication
7.1 認証
Authentication in ICAP is very similar to proxy authentication in HTTP as specified in RFC 2617. Specifically, the following rules apply:
ICAPでの認証はRFC2617の指定されるとしてのHTTPにおけるプロキシ認証と非常に同様です。 明確に、以下の規則は適用されます:
- WWW-Authenticate challenges and responses are for end-to-end
authentication between a client (user) and an origin server. As
any proxy, ICAP clients and ICAP servers MUST forward these
headers without modification.
- 挑戦をWWW認証してください。そうすれば、クライアント(ユーザ)と発生源サーバの間には、応答は終わりから終わりへの認証のためにあります。どんなプロキシとしても、ICAPクライアントとICAPサーバは変更なしでこれらのヘッダーを進めなければなりません。
Elson & Cerpa Informational [Page 37] RFC 3507 ICAP April 2003
[37ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
- If authentication is required between an ICAP client and ICAP
server, hop-by-hop Proxy Authentication as described in RFC 2617
MUST be used.
- 認証がICAPクライアントとICAPサーバの間で必要であるなら、ホップごとのRFC2617で説明されるProxy Authenticationを使用しなければなりません。
There are potential applications where a user (as opposed to ICAP client) might have rights to access an ICAP service. In this version of the protocol, we assume that ICAP clients and ICAP servers are under the same administrative domain, and contained in a single trust domain. Therefore, in these cases, we assume that it is sufficient for users to authenticate themselves to the ICAP client (which is a surrogate from the point of view from the user). This type of authentication will also be Proxy Authentication as described in RFC 2617.
潜在的利用がユーザ(ICAPクライアントと対照的に)がICAPサービスにアクセスする権利を持っているかもしれないところにあります。 プロトコルのこのバージョンでは、私たちは、ICAPクライアントとICAPサーバが同じ管理ドメインの下にあって、ただ一つの信頼ドメインに含まれていると思います。 したがって、これらの場合では、私たちは、ユーザがICAPクライアント(ユーザからの観点からの代理である)に自分たちを認証するのが、十分であると思います。 また、このタイプの認証はRFC2617で説明されるようにProxy Authenticationになるでしょう。
This standard explicitly excludes any method for a user to authenticate directly to an ICAP server; the ICAP client MUST be involved as described above.
この規格は明らかにユーザが直接ICAPサーバに認証するどんなメソッドも除きます。 ICAPクライアントは上で説明されるようにかかわっているに違いありません。
7.2 Encryption
7.2 暗号化
Users of ICAP should note well that ICAP messages are not encrypted for transit by default. In the absence of some other form of encryption at the link or network layers, eavesdroppers may be able to record the unencrypted transactions between ICAP clients and servers. As described in Section 4.3.1, the Upgrade header MAY be used to negotiate transport-layer security for an ICAP connection [5].
ICAPのユーザは、ICAPメッセージがトランジットのためにデフォルトで暗号化されないことによく注意するべきです。 リンクかネットワーク層における、ある他の形式の暗号化がないとき、立ち聞きする者はICAPクライアントとサーバの間の非暗号化されたトランザクションを記録できるかもしれません。 セクション4.3.1で説明されるように、UpgradeヘッダーはICAP接続[5]のためにトランスポート層セキュリティを交渉するのにおいて使用されているかもしれません。
Note also that end-to-end encryption between a client and origin server is likely to preclude the use of value-added services by intermediaries such as surrogates. An ICAP server that is unable to decrypt a client's messages will, of course, be unable to perform any transformations on it.
また、クライアントと発生源サーバの間の終端間暗号化が代理などの仲介者による付加価値が付いたサービスの使用を排除しそうに注意してください。 クライアントのメッセージを解読することができないICAPサーバはもちろんそれにどんな変換も実行できないでしょう。
7.3 Service Validation
7.3 サービス合法化
Normal HTTP surrogates, when operating correctly, should not affect the end-to-end semantics of messages that pass through them. This forms a well-defined criterion to validate that a surrogate is working correctly: a message should look the same before the surrogate as it does after the surrogate.
正しく作動するとき、普通のHTTP代理はそれらを通り抜けるメッセージの終わりから終わりへの意味論に影響するはずがありません。 これは有効にする代理が正しく扱っている明確な評価基準を形成します: メッセージは代理の後にするように代理の前で同じに見えるべきです。
In contrast, ICAP is meant to cause changes in the semantics of messages on their way from origin servers to users. The criteria for a correctly operating surrogate are no longer as easy to define. This will make validation of ICAP services significantly more difficult. Incorrect adaptations may lead to security vulnerabilities that were not present in the unadapted content.
対照的に、ICAPは発生源サーバからユーザへの途中でメッセージの意味論における変化を引き起こすことになっています。 正しく稼働している代理の評価基準はもう同じくらい定義しにくいです。 これで、ICAPサービスの合法化はかなり難しくなるでしょう。 不正確な適合は「非-適合させ」られた内容に存在していないセキュリティの脆弱性につながるかもしれません。
Elson & Cerpa Informational [Page 38] RFC 3507 ICAP April 2003
[38ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
8. Motivations and Design Alternatives
8. 動機とデザイン代替手段
This section describes some of our design decisions in more detail, and describes the ideas and motivations behind them. This section does not define protocol requirements, but hopefully sheds light on the requirements defined in previous sections. Nothing in this section carries the "force of law" or is part of the formal protocol specification.
このセクションは、さらに詳細に私たちのデザイン決定のいくつかについて説明して、それらの後ろで考えと動機について説明します。 このセクションは、プロトコル要件を定義しませんが、希望をいだいて前項で定義された要件を解明します。 このセクションの何はも、「法律効力」を運ぶか、正式なプロトコル仕様の一部ではありませんでも。
In general, our guiding principle was to make ICAP the simplest possible protocol that would do the job, and no simpler. Some features were rejected where alternative (non-protocol-based) solutions could be found. In addition, we have intentionally left a number of issues at the discretion of the implementor, where we believe that doing so does not compromise interoperability.
一般に、私たちの指導原理は、ICAPを仕事をする可能な限り簡単なプロトコルにするようにあって、より簡単ではありません。 いくつかの特徴が代替(非プロトコルベースの)のソリューションを見つけることができたところで拒絶されました。 さらに、私たちは故意に作成者の裁量における多くの問題を残しました。そこでは、私たちが、そうするのが相互運用性に感染しないと信じています。
8.1 To Be HTTP, or Not To Be
8.1、HTTPであるかHTTPでない
ICAP was initially designed as an application-layer protocol built to run on top of HTTP. This was desirable for a number of reasons. HTTP is well-understood in the community and has enjoyed significant investments in software infrastructure (clients, servers, parsers, etc.). Our initial designs focused on leveraging that existing work; we hoped that it would be possible to implement ICAP services simply, using CGI scripts run by existing web servers.
ICAPは初めは、HTTPの上で稼働するために築き上げられた応用層プロトコルとして設計されました。 これは様々な意味で望ましかったです。 HTTPは、共同体でよく理解されていて、ソフトインフラ(クライアント、サーバ、パーサなど)で重要な投資を持っていました。 私たちのその存在を利用するのに集中している初期のデザインは働いています。 既存のウェブサーバーによって実行されたCGIスクリプトを使用して、単にICAPにサービスを実装するのが可能であることを願っていました。
However, the devil (as always) proved to be in the details. Certain features that we considered important were impossible to implement with HTTP. For example, ICAP clients can stop and wait for a "100 Continue" message in the midst of a message-body; HTTP clients may only wait between the header and body. In addition, certain transformations of HTTP messages by surrogates are legal (and harmless for HTTP), but caused problems with ICAP's "header-in- header" encapsulation and other features.
しかしながら、悪魔は、(いつものように)詳細にいると判明しました。 私たちが重要であると考えたある特徴はHTTPで実装するのが不可能でした。 例えば、ICAPクライアントは、メッセージ本体の中で「100は続く」というメッセージを止めて、待つことができます。 HTTPクライアントはヘッダーとボディーの間で待つだけであるかもしれません。 代理によるHTTPメッセージのある変換はさらに、法的、そして、(HTTPに無害)であり、ICAPのものに関する問題を引き起こされる、「」 カプセル化ともう一方が特集する中のヘッダーヘッダー。
Ultimately, we decided that the tangle of workarounds required to fit ICAP into HTTP was more complex and confusing than moving away from HTTP and defining a new (but similar) protocol.
結局、私たちは、HTTPにICAPに合うのに必要である回避策のもつれがHTTPから遠くに移行して、新しくて(同様)のプロトコルを定義するより複雑であって、紛らわしいと決めました。
8.2 Mandatory Use of Chunking
8.2 分魂化の義務的な使用
Chunking is mandatory in ICAP encapsulated bodies for three reasons. First, efficiency is important, and the chunked encoding allows both the client and server to keep the transport-layer connection open for later reuse. Second, ICAP servers (and their developers) should be encouraged to produce "incremental" responses where possible, to reduce the latency perceived by users. Chunked encoding is the only way to support this type of implementation. Finally, by
分魂化はボディーであるとカプセル化されたICAPで3つの理由に義務的です。 まず最初に、効率は重要です、そして、chunkedコード化は後の再利用において開くようにトランスポート層接続を保つためにクライアントとサーバを両方に許容します。 2番目に、ICAPサーバ(そして、彼らの開発者)は、「増加」の応答を可能であるところに起こして、ユーザによって知覚されたレイテンシを減少させるよう奨励されるべきです。 Chunkedコード化はこのタイプの実装をサポートする唯一の方法です。 by
Elson & Cerpa Informational [Page 39] RFC 3507 ICAP April 2003
[39ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
standardizing on a single encapsulation mechanism, we avoid the complexity that would be required in client and server software to support multiple mechanisms. This simplifies ICAP, particularly in the "body preview" feature described in Section 4.5.
ただ一つのカプセル化メカニズムの上の標準化、私たちは複数のメカニズムをサポートするのにクライアントとサーバソフトウェアで必要である複雑さを避けます。これはICAPを簡素化します、特にセクション4.5で説明された「ボディープレビュー」の特徴で。
While chunking of encapsulated bodies is mandatory, encapsulated headers are not chunked. There are two reasons for this decision. First, in cases where a chunked HTTP message body is being encapsulated in an ICAP message, the ICAP client (HTTP server) can copy it directly from the HTTP client to the ICAP server without un- chunking and then re-chunking it. Second, many header-parser implementations have difficulty dealing with headers that come in multiple chunks. Earlier drafts of this document mandated that a chunk boundary not come within a header. For clarity, chunking of encapsulated headers has simply been disallowed.
カプセル化されたボディーの分魂化が義務的である間、カプセル化されたヘッダーはchunkedされません。 この決定の2つの理由があります。 最初に、chunked HTTPメッセージ本体がICAPメッセージでカプセル化されている場合では、ICAPクライアント(HTTPサーバ)は不-分魂化と次に、再分魂化なしでそれを直接HTTPクライアントからICAPサーバまでコピーできます。それ。 2番目に、多くのヘッダーパーサ実装が複数の塊に入るヘッダーに対処するのに苦労します。 この草稿は、前に塊境界がヘッダーに含まれないのを強制したと記録します。 明快において、カプセル化されたヘッダーの分魂化は単に禁じられました。
8.3 Use of the null-body directive in the Encapsulated header
8.3 Encapsulatedヘッダーにおけるヌルボディー指示の使用
There is a disadvantage to not using the chunked transfer-encoding for encapsulated header part of an ICAP message. Specifically, parsers do not know in advance how much header data is coming (e.g., for buffer allocation). ICAP does not allow chunking in the header part for reasons described in Section 8.2. To compensate, the "null-body" directive allows the final header's length to be determined, despite it not being chunked.
ICAPメッセージのカプセル化されたヘッダー部分にchunked転送コード化を使用しないことへの難点があります。 明確に、パーサは、あらかじめ、どのくらいのヘッダー・データが来るかを(例えば、バッファ配分のために)知りません。 ICAPはセクション8.2で説明された理由によるヘッダー部分に分魂化を許容しません。 代償するために、「ヌルボディー」指示は、それにもかかわらず、chunkedされないで、最終的なヘッダーの長さが決定しているのを許容します。
9. References
9. 参照
[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
August 1998.
[1]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文と意味論」、RFC2396、8月1998日
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[3] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[4] 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.
[4] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[5] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
RFC 2817, May 2000.
「HTTP/1.1インチ、RFC2817、2000年5月中にTLSにアップグレードする」[5]Khare、R.、およびS.ローレンス。
Elson & Cerpa Informational [Page 40] RFC 3507 ICAP April 2003
[40ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
10. Contributors
10. 貢献者
ICAP is based on an original idea by John Martin and Peter Danzig. Many individuals and organizations have contributed to the development of ICAP, including the following contributors (past and present):
ジョン・マーチンとピーター・ダンツィグのICAPは着想に基づいています。 多くの個人と組織は以下の貢献者(過去の、そして、現在の)を含むICAPの開発に貢献しました:
Lee Duggs Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
リーDuggsネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)
Phone: (408) 822-6000 EMail: lee.duggs@netapp.com
以下に電話をしてください。 (408) 822-6000 メールしてください: lee.duggs@netapp.com
Paul Eastham Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
ポールEasthamネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)
Phone: (408) 822-6000 EMail: eastham@netapp.com
以下に電話をしてください。 (408) 822-6000 メールしてください: eastham@netapp.com
Debbie Futcher Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
デビーFutcherネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)
Phone: (408) 822-6000 EMail: deborah.futcher@netapp.com
以下に電話をしてください。 (408) 822-6000 メールしてください: deborah.futcher@netapp.com
Don Gillies Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
ドン従者ネットアプライアンスのInc.495の東Javaサニーベルカリフォルニア94089博士(米国)
Phone: (408) 822-6000 EMail: gillies@netapp.com
以下に電話をしてください。 (408) 822-6000 メールしてください: gillies@netapp.com
Steven La Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
スティーブンLaネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)
Phone: (408) 822-6000 EMail: steven.la@netapp.com
以下に電話をしてください。 (408) 822-6000 メールしてください: steven.la@netapp.com
Elson & Cerpa Informational [Page 41] RFC 3507 ICAP April 2003
[41ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
John Martin Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
ジョンマーチンネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)
Phone: (408) 822-6000 EMail: jmartin@netapp.com
以下に電話をしてください。 (408) 822-6000 メールしてください: jmartin@netapp.com
Jeff Merrick Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
ジェフメリックネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)
Phone: (408) 822-6000 EMail: jeffrey.merrick@netapp.com
以下に電話をしてください。 (408) 822-6000 メールしてください: jeffrey.merrick@netapp.com
John Schuster Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
ジョンシュスターネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)
Phone: (408) 822-6000 EMail: john.schuster@netapp.com
以下に電話をしてください。 (408) 822-6000 メールしてください: john.schuster@netapp.com
Edward Sharp Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
サニーベル博士、鋭いネットアプライアンスInc.495の東Javaカリフォルニア94089米国のエドワード
Phone: (408) 822-6000 EMail: edward.sharp@netapp.com
以下に電話をしてください。 (408) 822-6000 メールしてください: edward.sharp@netapp.com
Peter Danzig Akamai Technologies 1400 Fashion Island Blvd San Mateo, CA 94404 USA
ピーターダンツィグアカマイ・テクノロジーズ1400ファッション島のBlvdカリフォルニア94404サン・マテオ(米国)
Phone: (650) 372-5757 EMail: danzig@akamai.com
以下に電話をしてください。 (650) 372-5757 メールしてください: danzig@akamai.com
Mark Nottingham Akamai Technologies 1400 Fashion Island Blvd San Mateo, CA 94404 USA
マークノッティンガムアカマイ・テクノロジーズ1400ファッション島のBlvdカリフォルニア94404サン・マテオ(米国)
Phone: (650) 372-5757 EMail: mnot@akamai.com
以下に電話をしてください。 (650) 372-5757 メールしてください: mnot@akamai.com
Elson & Cerpa Informational [Page 42] RFC 3507 ICAP April 2003
[42ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
Nitin Sharma Akamai Technologies 1400 Fashion Island Blvd San Mateo, CA 94404 USA
Nitinシャルマアカマイ・テクノロジーズ1400ファッション島のBlvdカリフォルニア94404サン・マテオ(米国)
Phone: (650) 372-5757 EMail: nitin@akamai.com
以下に電話をしてください。 (650) 372-5757 メールしてください: nitin@akamai.com
Hilarie Orman Novell, Inc. 122 East 1700 South Provo, UT 84606 USA
東1700の南ユタ84606Hilarie OrmanノベルInc.122プロボ(米国)
Phone: (801) 861-7021 EMail: horman@novell.com
以下に電話をしてください。 (801) 861-7021 メールしてください: horman@novell.com
Craig Blitz Novell, Inc. 122 East 1700 South Provo, UT 84606 USA
東1700の南ユタ84606クレイグ電撃ノベルInc.122プロボ(米国)
Phone: (801) 861-7021 EMail: cblitz@novell.com
以下に電話をしてください。 (801) 861-7021 メールしてください: cblitz@novell.com
Gary Tomlinson Novell, Inc. 122 East 1700 South Provo, UT 84606 USA
東1700の南ユタ84606ゲーリートムリンスンノベルInc.122プロボ(米国)
Phone: (801) 861-7021 EMail: garyt@novell.com
以下に電話をしてください。 (801) 861-7021 メールしてください: garyt@novell.com
Andre Beck Bell Laboratories / Lucent Technologies 101 Crawfords Corner Road Holmdel, New Jersey 07733-3030
Crawfordsコーナー道路Holmdel、アンドレべックベル研究所/ルーセントテクノロジーズ101ニュージャージー07733-3030
Phone: (732) 332-5983 EMail: abeck@bell-labs.com
以下に電話をしてください。 (732) 332-5983 メールしてください: abeck@bell-labs.com
Markus Hofmann Bell Laboratories / Lucent Technologies 101 Crawfords Corner Road Holmdel, New Jersey 07733-3030
Crawfordsコーナー道路Holmdel、マーカスホフマンベル研究所/ルーセントテクノロジーズ101ニュージャージー07733-3030
Phone: (732) 332-5983 EMail: hofmann@bell-labs.com
以下に電話をしてください。 (732) 332-5983 メールしてください: hofmann@bell-labs.com
Elson & Cerpa Informational [Page 43] RFC 3507 ICAP April 2003
[43ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
David Bryant CacheFlow, Inc. 650 Almanor Avenue Sunnyvale, California 94086
デヴィッドブライアントCacheFlow Inc.650Almanor Avenueサニーベル、カリフォルニア 94086
Phone: (888) 462-3568 EMail: david.bryant@cacheflow.com
以下に電話をしてください。 (888) 462-3568 メールしてください: david.bryant@cacheflow.com
Elson & Cerpa Informational [Page 44] RFC 3507 ICAP April 2003
[44ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
Appendix A BNF Grammar for ICAP Messages
付録はICAPメッセージのためのBNF文法です。
This grammar is specified in terms of the augmented Backus-Naur Form (BNF) similar to that used by the HTTP/1.1 specification (See Section 2.1 of [4]). Implementors will need to be familiar with the notation in order to understand this specification.
HTTP/1.1仕様で使用されるそれと同様の増大しているBN記法(BNF)でこの文法は指定されます。([4])のセクション2.1を見てください。 作成者は、この仕様を理解するために記法によく知られる必要があるでしょう。
Many header values (where noted) have exactly the same grammar and semantics as in HTTP/1.1. We do not reproduce those grammars here.
多くのヘッダー値(有名であるところ)には、まさに同じ文法と意味論がHTTP/1.1のようにあります。 私たちはここでそれらの文法を再生させません。
ICAP-Version = "ICAP/1.0"
ICAP-バージョン=「ICAP/1インチ」
ICAP-Message = Request | Response
ICAP-メッセージ=要求| 応答
Request = Request-Line
*(Request-Header CRLF)
CRLF
[ Request-Body ]
=要求線*(要求ヘッダーCRLF)CRLFを要求してください。[要求本体]
Request-Line = Method SP ICAP_URI SP ICAP-Version CRLF
メソッドSP ICAP_ユリSP ICAP-バージョン要求線=CRLF
Method = "REQMOD" ; Section 4.8
| "RESPMOD" ; Section 4.9
| "OPTIONS" ; Section 4.10
| Extension-Method ; Section 4.3.2
メソッドは"REQMOD"と等しいです。 セクション4.8| "RESPMOD"。 セクション4.9| 「オプション」。 セクション4.10| 拡大メソッド。 セクション4.3 .2
Extension-Method = token
拡大メソッドはトークンと等しいです。
ICAP_URI = Scheme ":" Net_Path [ "?" Query ] ; Section 4.2
「ICAP_URI=体系」:、」 ネットの_経路[“?"質問]。 セクション4.2
Scheme = "icap"
体系="icap"
Net_Path = "//" Authority [ Abs_Path ]
「ネット_経路は」 //と等しい」という権威[腹筋_経路]
Authority = [ userinfo "@" ] host [ ":" port ]
権威=[userinfo"@"]ホスト[「:」 ポート]
Request-Header = Request-Fields ":" [ Generic-Field-Value ]
「要求ヘッダー=要求分野」:、」 [ジェネリック分野価値]
Request-Fields = Request-Field-Name
| Common-Field-Name
要求分野は要求フィールド名と等しいです。| 一般的なフィールド名
; Header fields specific to requests
Request-Field-Name = "Authorization" ; Section 4.3.2
| "Allow" ; Section 4.3.2
| "From" ; Section 4.3.2
| "Host" ; Section 4.3.2
| "Referer" ; Section 4.3.2
; 要求Request分野名に特定のヘッダーフィールドは「承認」と等しいです。 セクション4.3 .2| 「許容します」。 セクション4.3 .2| "From"。 セクション4.3 .2| 「ホスト」。 セクション4.3 .2| "Referer"。 セクション4.3 .2
Elson & Cerpa Informational [Page 45] RFC 3507 ICAP April 2003
[45ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
| "User-Agent" ; Section 4.3.2
| "Preview" ; Section 4.5
| 「ユーザエージェント」。 セクション4.3 .2| 「プレビュー」。 セクション4.5
; Header fields common to both requests and responses
Common-Field-Name = "Cache-Control" ; Section 4.3.1
| "Connection" ; Section 4.3.1
| "Date" ; Section 4.3.1
| "Expires" ; Section 4.3.1
| "Pragma" ; Section 4.3.1
| "Trailer" ; Section 4.3.1
| "Upgrade" ; Section 4.3.1
| "Encapsulated" ; Section 4.4
| Extension-Field-Name ; Section 4.3
; 要求と応答の両方に共通のヘッダーフィールドCommon分野名は「キャッシュ制御」と等しいです。 セクション4.3 .1| 「接続」。 セクション4.3 .1| 「デートしてください」。 セクション4.3 .1| 「期限が切れます」。 セクション4.3 .1| "Pragma"。 セクション4.3 .1| 「トレーラ」。 セクション4.3 .1| 「アップグレードしてください」。 セクション4.3 .1| 「要約します」。 セクション4.4| 拡大フィールド名。 セクション4.3
Extension-Field-Name = "X-" token
拡大分野名は「X」トークンと等しいです。
Generic-Field-Value = *( Generic-Field-Content | LWS )
Generic-Field-Content = <the OCTETs making up the field-value
and consisting of either *TEXT or
combinations of token, separators,
and quoted-string>
ジェネリック分野価値は分野値を作って、トークン、分離符、および引用文字列>の*TEXTか組み合わせのどちらかから成る*(ジェネリック分野内容| LWS)ジェネリック分野内容=<OCTETsと等しいです。
Request-Body = *OCTET ; See Sections 4.4 and 4.5 for semantics
要求本体は*八重奏と等しいです。 意味論に関してセクション4.4と4.5を見てください。
Response = Status-Line
*(Response-Header CRLF)
CRLF
[ Response-Body ]
応答=状況表示行*(応答ヘッダCRLF)のCRLF[応答本体]
Status-Line = ICAP-Version SP Status-Code SP Reason-Phrase CRLF
状況表示行=ICAP-バージョンSPステータスコードSP理由句のCRLF
Status-Code = "100" ; Section 4.5
| "101" ; Section 10.1.2 of [4]
| "200" ; Section 10.2.1 of [4]
| "201" ; Section 10.2.2 of [4]
| "202" ; Section 10.2.3 of [4]
| "203" ; Section 10.2.4 of [4]
| "204" ; Section 4.6
| "205" ; Section 10.2.6 of [4]
| "206" ; Section 10.2.7 of [4]
| "300" ; Section 10.3.1 of [4]
| "301" ; Section 10.3.2 of [4]
| "302" ; Section 10.3.3 of [4]
| "303" ; Section 10.3.4 of [4]
| "304" ; Section 10.3.5 of [4]
| "305" ; Section 10.3.6 of [4]
| "306" ; Section 10.3.7 of [4]
| "307" ; Section 10.3.8 of [4]
ステータスコード=「100」。 セクション4.5| "101" ; [4]について10.1に.2を区分してください。| "200" ; [4]について10.2に.1を区分してください。| "201" ; [4]について10.2に.2を区分してください。| "202" ; [4]について10.2に.3を区分してください。| "203" ; [4]について10.2に.4を区分してください。| "204" ; セクション4.6| "205" ; [4]について10.2に.6を区分してください。| "206" ; [4]について10.2に.7を区分してください。| "300" ; [4]について10.3に.1を区分してください。| "301" ; [4]について10.3に.2を区分してください。| "302" ; [4]について10.3に.3を区分してください。| "303" ; [4]について10.3に.4を区分してください。| "304" ; [4]について10.3に.5を区分してください。| "305" ; [4]について10.3に.6を区分してください。| "306" ; [4]について10.3に.7を区分してください。| "307" ; セクション10.3.8[4]
Elson & Cerpa Informational [Page 46] RFC 3507 ICAP April 2003
[46ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
| "400" ; Section 4.3.3
| "401" ; Section 10.4.2 of [4]
| "402" ; Section 10.4.3 of [4]
| "403" ; Section 10.4.4 of [4]
| "404" ; Section 4.3.3
| "405" ; Section 4.3.3
| "406" ; Section 10.4.7 of [4]
| "407" ; Section 10.4.8 of [4]
| "408" ; Section 4.3.3
| "409" ; Section 10.4.10 of [4]
| "410" ; Section 10.4.11 of [4]
| "411" ; Section 10.4.12 of [4]
| "412" ; Section 10.4.13 of [4]
| "413" ; Section 10.4.14 of [4]
| "414" ; Section 10.4.15 of [4]
| "415" ; Section 10.4.16 of [4]
| "416" ; Section 10.4.17 of [4]
| "417" ; Section 10.4.18 of [4]
| "500" ; Section 4.3.3
| "501" ; Section 4.3.3
| "502" ; Section 4.3.3
| "503" ; Section 4.3.3
| "504" ; Section 10.5.5 of [4]
| "505" ; Section 4.3.3
| Extension-Code
| "400" ; セクション4.3 .3| "401" ; [4]について10.4に.2を区分してください。| "402" ; [4]について10.4に.3を区分してください。| "403" ; [4]について10.4に.4を区分してください。| "404" ; セクション4.3 .3| "405" ; セクション4.3 .3| "406" ; [4]について10.4に.7を区分してください。| "407" ; [4]について10.4に.8を区分してください。| "408" ; セクション4.3 .3| "409" ; [4]について10.4に.10を区分してください。| "410" ; [4]について10.4に.11を区分してください。| "411" ; [4]について10.4に.12を区分してください。| "412" ; [4]について10.4に.13を区分してください。| "413" ; [4]について10.4に.14を区分してください。| "414" ; [4]について10.4に.15を区分してください。| "415" ; [4]について10.4に.16を区分してください。| "416" ; [4]について10.4に.17を区分してください。| "417" ; [4]について10.4に.18を区分してください。| "500" ; セクション4.3 .3| "501" ; セクション4.3 .3| "502" ; セクション4.3 .3| "503" ; セクション4.3 .3| "504" ; [4]について10.5に.5を区分してください。| "505" ; セクション4.3 .3| 拡張コード
Extension-Code = 3DIGIT
拡張コード=3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
CR、LF>を除いた理由句の=*<TEXT
Response-Header = Response-Fields ":" [ Generic-Field-Value ]
「応答ヘッダは応答分野と等しい」:、」 [ジェネリック分野価値]
Response-Fields = Response-Field-Name
| Common-Field-Name
応答分野は応答フィールド名と等しいです。| 一般的なフィールド名
Response-Field-Name = "Server" ; Section 4.3.3
| "ISTag" ; Section 4.7
応答フィールド名は「サーバ」と等しいです。 セクション4.3 .3| "ISTag"。 セクション4.7
Response-Body = *OCTET ; See Sections 4.4 and 4.5 for semantics
応答本体は*八重奏と等しいです。 意味論に関してセクション4.4と4.5を見てください。
Elson & Cerpa Informational [Page 47] RFC 3507 ICAP April 2003
[47ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
Authors' Addresses
作者のアドレス
Jeremy Elson University of California Los Angeles Department of Computer Science 3440 Boelter Hall Los Angeles CA 90095
コンピュータサイエンス3440Boelterホールロサンゼルスカリフォルニア 90095人のジェレミーエルソンカリフォルニア大学ロサンゼルス校部
Phone: (310) 206-3925 EMail: jelson@cs.ucla.edu
以下に電話をしてください。 (310) 206-3925 メールしてください: jelson@cs.ucla.edu
Alberto Cerpa University of California Los Angeles Department of Computer Science 3440 Boelter Hall Los Angeles CA 90095
コンピュータサイエンス3440Boelterホールロサンゼルスカリフォルニア 90095人のアルベルトCerpaカリフォルニア大学ロサンゼルス校部
Phone: (310) 206-3925 EMail: cerpa@cs.ucla.edu
以下に電話をしてください。 (310) 206-3925 メールしてください: cerpa@cs.ucla.edu
ICAP discussion currently takes place at
icap-discussions@yahoogroups.com.
For more information, see
http://groups.yahoo.com/group/icap-discussions/.
ICAP議論は現在、 icap-discussions@yahoogroups.com で行われます。 詳しくは、 http://groups.yahoo.com/group/icap-discussions/ を見てください。
Elson & Cerpa Informational [Page 48] RFC 3507 ICAP April 2003
[48ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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機能のための基金は現在、インターネット協会によって提供されます。
Elson & Cerpa Informational [Page 49]
エルソンとCerpa情報です。[49ページ]
一覧
スポンサーリンク
