Network Working Group J. Elson
Request for Comments: 3507 A. Cerpa
Category: Informational UCLA
April 2003
Internet Content Adaptation Protocol (ICAP)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
オープン・プラガブルサービス（OPES）ワーキンググループは、ICAPとしての機能と同じを実行することを意図したプロトコルの標準トラックプロトコル仕様を生成するために結成されました。 ICAPが普及すでに使用されているので、IESGは、情報提供文書としてICAPの仕様を公開することによって、既存の利用状況を文書化することが適切であると考えています。 IESGはまた、ICAPは、RFC 3238の公表前に開発されたので、その文書で説明した建築や政策の問題に対処していないことを指摘しています。
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、インターネットコンテンツへの適応性プロトコルは、HTTPサービスのための単純なオブジェクトベースのコンテンツベクタリングを提供することを目的としたプロトコルです。 ICAPは、本質的には、HTTPメッセージの「リモートプロシージャコール」を実行するための軽量プロトコルです。これは、ICAPクライアントは、変換または他の処理（「適応」）のいくつかの並べ替えのためにICAPサーバにHTTPメッセージを渡すことができます。サーバーは、メッセージに対して変換サービスを実行し、通常は修正メッセージで、クライアントに応答を送り返します。一般的に、適応したメッセージは、HTTP要求またはHTTP応答のいずれかです。
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
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
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.
インターネットの成長に伴い、そのスケーラブルなインターネットサービスの必要性がありません。人気のWebサーバは、増え続ける帯域幅で接続しているユーザーの数百万にコンテンツを配信するように求められます。すべてのクライアントの要求のすべての側面を担当しているの集中、モノリシックサーバのモデルは、その耐用年数の終わりに達しているようです。
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、インターネットコンテンツへの適応性プロトコルは、HTTPサービスのための単純なオブジェクトベースのコンテンツベクタリングを提供することを目的としたプロトコルです。 ICAPは、本質的には、HTTPメッセージの「リモートプロシージャコール」を実行するための軽量プロトコルです。これは、ICAPクライアントは、変換または他の処理（「適応」）のいくつかの並べ替えのためにICAPサーバにHTTPメッセージを渡すことができます。サーバーは、メッセージに対して変換サービスを実行し、通常は修正メッセージで、クライアントに応答を送り返します。適応したメッセージは、HTTP要求またはHTTP応答のいずれであってもよいです。変換は、他の非HTTPコンテンツに可能かもしれないが、彼らはこのドキュメントの範囲を超えています。
This type of Remote Procedure Call (RPC) is useful in a number of ways. For example:
リモートプロシージャコール（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含有量の単純な変換ではなく、オリジンサーバからのオブジェクトの更新されたコピーを必要とするネットワークのエッジ付近に行うことができます。例えば、コンテンツプロバイダは、異なる広告とページが表示されるたびに、人気のあるWebページを提供する場合があります。現在、コンテンツプロバイダは、非キャッシュ可能などのページをマーキングし、ユーザーのクッキーを追跡することによって、このポリシーを実装します。これは、オリジンサーバとネットワーク上の追加の負荷を課します。私たちのアーキテクチャでは、ページには、ネットワークのエッジ付近で一度キャッシュすることができます。これらのエッジキャッシュはその後、近くの広告挿入サーバにページがクライアントに提供されるたびに、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ファイアウォールまたはサロゲートは、ICAPクライアントとして機能し、（子供が見るWebコンテンツのペアレンタルコントロールを可能にするシステムでは、例えば）要求内のURIが許可されていることを確認するチェックサービスへの発信要求を送信することができます。この場合には、応答によって返されたオブジェクトをしないように適合されている*要求*です。
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は、オリジンサーバ、代理、またはネットワーク自体の負荷を軽減または配布を支援しています。いくつかのケースでは、ICAPは、基礎となるコンテンツのより大きなキャッシュ性を可能にする、ネットワークのエッジ付近の変換を容易にします。他の例では、このようなオリジンサーバや代理などのデバイスは、他のマシン上に高価な操作を配布することによって彼らの負荷を軽減することができます。全ての場合において、ICAPは、コンテンツ配信や代理で付加価値サービスの他に、より大きな柔軟性を可能にするためにコンテンツ適応のための標準インタフェースを作成しました。
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.
この時点で、ポリシーフレームワークの非存在下では、変換のみ、コンテンツプロバイダまたはユーザ（または両方）の明示的な同意を得てメッセージに対して実行されるべきであることを強く推奨されていることに注意してください。重要。いずれかの同意なしに、変換サービスの展開は予測できない結果、最高の状態で、につながります。これらの問題の多くの議論については、セクション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トランザクションインタフェースと相補的な標準ポリシー定義のインタフェースを可能にすることができます。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。
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通信の基本単位、[4] HTTP / 1.1のセクション4で定義されたシンタックスに一致オクテットの構造配列からなる、接続を介して送信されます。
request: An HTTP request message, as defined in Section 5 of HTTP/1.1 [4].
要求：HTTP / 1.1のセクション5で定義されるようにHTTPリクエストメッセージ、[4]。
response: An HTTP response message, as defined in Section 6 of HTTP/1.1 [4].
応答：HTTP / 1.1のセクション6で定義されるようにHTTPレスポンスメッセージ、[4]。
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の3.2節で定義されるように、URIによって識別することができるネットワーク・データ・オブジェクトまたはサービス[4]。リソースが複数の表現（例えば、複数の言語、データフォーマット、サイズ、解像度）で利用可能であるか、または他の方法で変えることができます。
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.
オリジンサーバ：与えられたリソースが存在するか、作成されるサーバー。
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レスポンスのキャッシュ可能性を決定するための規則は、[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.
代理：オリジンサーバと同じ場所に配置ゲートウェイ、またはネットワーク内の別のポイントで、代わって操作する権限を委譲し、通常、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]でキャッシュ制御ディレクティブを含むいくつかのプロトコル要件の変更を可能にします。このような修飾は、完全に指定されていません。
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サービスを指します。
ICAP server: Similar to an HTTP server as described above, except that the application services ICAP requests.
ICAPサーバ：HTTPサーバと同様にアプリケーションサービスのICAP要求する以外は、上記のように。
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クライアントは、常にユーザーに代わって代理演技が多いですが、ありません。
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の意味を説明する前に、我々は、第1のプロトコルの主な機能と予想される用途の一般的な概要を提供します。前述したように、ICAPは、HTTPリクエスト（3.1節）の変更、およびHTTPレスポンス（3.2節）の変更に焦点を当てています。
In "request modification" (reqmod) mode, an ICAP client sends an HTTP request to an ICAP server. The ICAP server may then:
「要求の変更」（REQMOD）モードでは、ICAPクライアントは、ICAPサーバにHTTPリクエストを送信します。 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レスポンスを送り返します。これは、エラーが発生した場合には、ユーザーに有益な情報を提供するために使用される（例えば、「あなたが見ることができませんページを表示するリクエストを送信しました」）。
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:
コンテンツフィルタリング：私たちは、サンプルアプリケーションでこの方法を説明します。オリジンサーバ上のWebページのためのクライアントからの要求を受けた代理を考えてみましょう。代理は、ICAPクライアントとして機能し、URIベースのコンテンツフィルタリングを実行ICAPサーバへのクライアントの要求を送信します。要求されたURIへのアクセスが許可されている場合、要求は変更されていないICAPクライアントに返されます。 ICAPサーバは要求されたリソースへのアクセスを禁止することを選択した場合しかし、それはどちらかの可能性があります。
1) Modify the request so that it points to a page containing an error message instead of the original URI.
それは代わりに、元の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.
この方法は、他の様々な用途に使用することができます。例えば、匿名化、受け入れの修正：などのヘッダは特殊なデバイス要件を処理するために、と。
Typical data flow:
典型的なデータフロー：
origin-server
| /|\
| |
5 | | 4
| |
\|/ | 2
ICAP-client --------------> ICAP-resource
(surrogate) <-------------- on ICAP-server
| /|\ 3
| |
6 | | 1
| |
\|/ |
client
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:
ステップ3は、要求を返された場合：
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サーバまたはオリジンサーバのいずれかから）返事を送ります。
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
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クライアントに戻す可能性の修正応答を送信します。
6. The surrogate sends the reply, possibly modified from the original origin server's reply, to the client.
6.代理は、クライアントに、おそらくオリジナルのオリジンサーバの応答から変更され、応答を送信します。
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上で動作するアプリケーションプロトコルです。これは、ICAPメッセージは、HTTPのサロゲートによって転送することができないこと、例えば、意味しています。 HTTPの上に直接構築しないために私たちの理由は8.1節で議論されています。
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メッセージは、サーバーからクライアントへのクライアントからサーバーへの要求と応答で構成されています。すなわち、スタートライン（要求ラインまたはステータスラインのいずれか）、（また、「ヘッダー」として知られている）ヘッダ・フィールドの数、空 - 要求および応答は、[3] RFC 2822の一般的なメッセージフォーマットを使用しますヘッダフィールドの終わり、およびメッセージ本体を示す線（すなわち、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のように、単一のトランスポート接続は、（おそらく必要があります）複数の要求/応答のペアのために再使用されるかもしれません。 ICAPにそうするための規則は、[4]のセクション8.1.2.2に記載されたものと同じです。具体的には、要求が一度にトランスポート接続上の唯一の未処理の要求を可能にすることにより、応答とマッチングされています。複数の並列接続は、HTTPのように使用されるかもしれません。
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の構文およびセマンティクスに関する明確な情報については、「統一資源識別子（URI）：一般的な構文とセマンティクス、」RFC 2396 [1]は、第3項は、ICAPによって定義されたURIの構造はおおよそ次のとおりです。
ICAP_URI = Scheme ":" Net_Path [ "?" Query ]
ICAP_URI =スキーム "：" Net_Path [ "？"クエリ]
Scheme = "icap"
Schemeは= "ICAP"
Net_Path = "//" Authority [ Abs_Path ]
Net_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ポートが与えられた空またはされていない場合、ポート1344が想定され、RFC 2396で定義されているものに新しいスキーム「ICAP」を追加します。例ICAP URIラインは次のようになります。
icap://icap.example.net:2000/services/icap-service-1
ケア：//icap.example.net：2000 /サービス/介護サービス-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/serviceモード= =フランス語翻訳＆LANG
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-」命名規則（「X-拡張-ヘッダ：foo」を）従わなければなりません。この文書で定義されている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].
フィールド値：各ヘッダフィールドは、コロン（「」）が続く名前で構成されています。フィールド名は大文字と小文字を区別しません。 ICAPは、ルールは、[4]のセクション4.2に記載して続きます。
The headers of all ICAP messages MAY include the following directives, defined in ICAP the same as they are in HTTP:
彼らはHTTPであるように、すべてのICAPメッセージのヘッダーはICAP同じで定義された次のディレクティブを含むことができます：
Cache-Control Connection Date Expires Pragma Trailer Upgrade
Cache-Control接続の日付は、プラグマトレーラーのアップグレード期限
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].
アップグレードヘッダ[4]にHTTP / 1.1について記載したとおりに、ICAP接続でトランスポート・レイヤ・セキュリティを交渉するために使用されるかもしれません。
The ICAP-specific headers defined are:
定義されたICAP固有のヘッダは以下のとおりです。
Encapsulated (See Section 4.4)
カプセル化された（4.4節を参照してください）
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.0」です。
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 - 要求変更（4.8節）RESPMODのため - レスポンス変更（4.9節）OPTIONSのための - 設定（4.10節）について学びます
The OPTIONS method MUST be implemented by all ICAP servers. All other methods are optional and MAY be implemented.
OPTIONSメソッドは、すべてのICAPサーバによって実装されなければなりません。他のすべてのメソッドはオプションであり、実施することができます。
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クライアントはサポートされている方法の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/translateモード=フランス語ICAP / 1.0
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:
リクエスト固有のヘッダの数は、対応するHTTPリクエストヘッダ（[4]のセクション5.3）と同じセマンティクス以下、ICAP要求で許可されています。これらは：
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
許可は（[4]のセクション14.22を参照）ホスト（これはHTTP / 1.1であるようにICAPで必要）リファラーはユーザーエージェント（[4]のセクション14.36を参照）から、（4.6節を参照のこと）を許可します
In addition to HTTP-like headers, there are also request headers unique to ICAP defined:
HTTPのようなヘッダに加えて、定義されたICAPに固有のヘッダが要求されています。
Preview (see Section 4.5)
プレビュー（4.5節を参照してください）
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 200 OK
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によって定義されたステータスコード（セクション6.1.1との10 [4]）、そうでない場合は、この文書に示されている場合を除き。 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サービスが見つかりません。
405 - Method not allowed for service (e.g., RESPMOD requested for service that supports only REQMOD).
405 - サービスのために許可されていない方法（例えば、RESPMODのみREQMODをサポートするサービスのために要求されました）。
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サーバのエラー、。
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プロキシおよびプロキシです。
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:
応答固有ヘッダは、対応するHTTPレスポンスヘッダ（[4]のセクション6.2）と同じセマンティクス以下、ICAP要求で許可されています。これは：
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節を参照してください）
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サーバではなく、広告を挿入できることを知っている場合は、ページに広告を挿入しないこともできます。
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.
そのようなヘッダを（使用する場合）、「X-ICAP」で始まる必要があります：このICAP仕様はHTTPクライアントとサーバ間の通信に使用される方法HTTP強制することはできませんが、私たちは大会を示唆して行います。そのアプリケーション固有のヘッダーと一緒にヘッダ：ICAPサービスとHTTPクライアントは、最小限の「1.0 X-ICAP-バージョン」が含まれるべきです。
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サーバへの要求、応答、および要求/応答ペアのベクトル化を可能にするために、カプセル化ICAPメッセージボディにHTTPメッセージセクションの任意の数をパッケージの軽量な手段です。
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メッセージボディ（カプセル化メッセージ）に興味深いメッセージ部分（カプセル化されたセクション）を連結することによって達成されます。カプセル化されたセクションは、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.
カプセル化されたボディは転送コーディング[4]のセクション3.6.1に記載の「チャンク」を使用して転送されなければなりません。しかし、カプセル化されたヘッダは、チャンクしてはなりません。換言すれば、ICAPメッセージボディは、ボディがカプセル化された本体部に、カプセル化ヘッダから通過する際にチャンクを非チャンクされることから切り替わります。 （セクション4.8.3および4.9.3での例を参照してください。）。この決定の背後にある動機は、セクション8.2に記載されています。
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-Lengthヘッダとの整合性の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_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)
encapsulated_header： "カプセル化：" encapsulated_list encapsulated_list：encapsulated_entity | encapsulated_entity "" encapsulated_listのencapsulated_entity：reqhdr | reshdr | reqbody | resbody | optbody reqhdr = "reqhdr" "="（10進整数）reshdr = "reshdr" "="（10進整数）reqbody = { "reqbody" | "ヌル体"} "="（10進整数）resbody = { "resbody" | "ヌル体"} "="（10進整数）optbody = { "optbody" | 「ヌル体」}「=」（10進整数）
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:
構文の制限を超えたカプセル化ヘッダの意味上の制限があります。カプセル化された部品が封入メッセージボディに表示される順序は、部品がカプセル化ヘッダで指定される順序と同じでなければなりません。つまり、カプセル化された行に記載されているオフセットは単調に増加しなければなりません。加えて、カプセル化ヘッダの法的形態は、（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要求encapsulated_list：[reqhdr] reqbody REQMOD応答encapsulated_list：{[reqhdr] reqbody} | {[reshdr] resbody} RESPMOD要求encapsulated_list：[reqhdr] [reshdr] resbody RESPMOD応答encapsulated_list：[reshdr] resbodyオプションは応答encapsulated_list：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:
法律上のカプセル化ヘッダの例：
/* 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 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 response: ICAP server returned a modified request,
* with body */
Encapsulated: req-hdr=0, req-body=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 or REQMOD response: header and body returned */
Encapsulated: res-hdr=0, res-body=749
/* OPTIONS response when there IS an options body */
Encapsulated: opt-body=0
/* OPTIONS response when there IS NOT an options body */
Encapsulated: null-body=0
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.
カプセル化ヘッダはライン・バイ・ライン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（[4]のセクション13.5.1を参照）、エンドツーエンドのヘッダ間の区別を行い、ホップバイホップヘッダー。ホップバイホップヘッダは、単一のトランスポート層接続のために意味があるのに対し、エンドツーエンドのヘッダは、メッセージの最終的な受信者に意味があります。ホップバイホップヘッダは等々キープアライブ、接続が含まれる、と。すべてのエンド・ツー・エンドのHTTPヘッダをカプセル化する必要があり、すべてのホップバイホップヘッダをカプセル化してはなりません。
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).
カプセルに上記の制限にもかかわらず、ホップバイホッププロキシ認証およびプロキシ認証ヘッダは、ICAPヘッダ部（非カプセル化されたメッセージ）にICAPサーバに転送されなければなりません。これは、ICAPクライアントはまた、HTTPの代理である場合にはICAPクライアントに送信された可能性があるクライアントの資格情報の伝播を可能にします。これは明示的に述べているHTTP / 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.
カプセル化されたメッセージは、HTTP代理を通って移動しているかのようにカプセル化されたメッセージのViaヘッダは、ICAPサーバによって変更する必要があります。 ICAPサーバによって追加したViaヘッダは、ICAP / 1.0などのプロトコルを指定しなければなりません。
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 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:
ICAP REQMODまたはICAPサーバにICAPクライアントによって送信されたRESPMOD要求は、「プレビュー」を含むことができます。この機能は、ICAPサーバは、それは要求メッセージの残りを受けるの初期の代わりにトランザクションのオプトアウトしたいかどうかを判断、トランザクションの開始を確認することができます。次のような状況で、様々なパフォーマンスが大幅に改善をもたらすことができるプレビュー：
- 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ファイル単独で入力し、「テキスト」は、実際にグラフィックスデータであることが判明した場合には十分ではありません）。ファイルの前でマジックナンバーは、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時間以上の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サーバは、リソースごとに特定のICAPアプリケーションのために必要とされているどのように多くのプレビューのバイト数を指定する（4.10節を参照）OPTIONSメソッドを使用する必要があります。クライアントは、少なくとも4096バイトのプレビューを提供できなければなりません。プレビュー有用で示された任意のICAPリソースを使用する場合、クライアントはさらに、プレビューを提供すべきです。 （この指示は、OPTIONSメソッド、またはいくつかの他の「アウトオブバンド」構成を介して提供されるかもしれない。）クライアントは、サーバが受け入れるで示されているよりも大きなプレビューを提供するべきではありません。
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:
プレビューの長さを示す、その要求ヘッダーのヘッダー：プレビューを行うため、ICAPクライアントは、「プレビュー」を追加しなければなりません。 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).
- プレビュー（おそらく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.
プレビューが送られた後、クライアントが停止し、続行する前にICAPサーバからの中間の応答を待ちます。このメカニズムは、ストップアンドウェイトポイントは、メッセージ本体内とすることができることを除いて、HTTPで見つかった「100-続行」機能に似ています。対照的に、HTTPは点はヘッダとボディとの間の境界でなければならないことを要求します。
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ヘッダーから成るプレビューを達成するために、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サーバにICAP要求のカプセル化されたボディにオリジンサーバデータの4096のバイトを送信しようとしていることを示します。 ICAPクライアントがサロゲートのように振る舞っているとオリジンサーバの応答の合計の長さを見つけるために先に見ていないので、実際の転送は少なくてもよいことに注意することが重要です。全体ICAPカプセル化されたヘッダ部（S）がカプセル化されたHTTPボディの最大4096バイトに続いて、送信されます。チャンクボディターミネーター「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サーバからの応答を待ちます。応答は、次のいずれかを指定します。
- 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応答、オリジナルの要求であったもの法によって。 REQMODとRESPMOD応答の形式については、セクション4.8.2と4.9.2を参照してください。
- 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」のシンボルで検出されたが、以下に説明する）場合は、ICAPサーバは続行100に応じてはいけません。
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 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.
ICAPクライアントがプレビューを実行しているとき、それはまだ最終的にそれがHTTPサーバーに中継された到着HTTPメッセージで利用できるようになりますどのように多くのバイトを知らないかもしれません。したがって、ICAPは1つが予期せずプレビュー処理中に到着した場合ICAPクライアントがICAPサーバに「EOF」を示すための方法を定義します。ヘッダのみHTTP応答がICAPクライアントに到着する場合、これは特に有用で最適化（すなわち、身体のゼロバイト）。唯一の1往復は、完全な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-Lengthヘッダを使用していないので、バイトがオリジンサーバから到着されますどのように多くの身体はまだ知りません。リクエストヘッダ：ICAPクライアントは、それが「1024プレビュー」を使用して1024バイトのプレビューを送信されますICAPサーバに通知します。 HTTPオリジンサーバは、その後（すなわち、それは0バイトの体を提供します）任意のデータを送信する前にICAPクライアントへの接続を閉じた場合は、次のように、そのゼロバイトの原点応答のための対応するゼロバイトのプレビューが表示されます：
\r\n 0; ieof\r\n\r\n
\ Rを\ n 0; 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コンテンツなしメッセージで応じなければなりません。それは、この場合には、100続行応答を送ってはいけません。 （原点応答が1バイト以上であった場合はこれとは対照的に、「ieof」は登場しなかったでしょう。その場合には、ICAPサーバは、100-続行して変更した応答、または204コンテンツなしに応答することができます。）
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
200 \ R \ n <512バイトのデータ> \ R \ nは200 \ R \ n <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-継続で応答）場合には、これらのチャンクは、ワイヤ上に表示されます：
200\r\n <512 bytes of data>\r\n 200\r\n <512 bytes of data>\r\n 0\r\n
200 \ R \ n <512バイトのデータ> \ R \ nは200 \ R \ n <512バイトのデータ> \ Rを\ n 0 \の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 \ nの0 \ 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.
プレビューを提供する際に、ICAPクライアントは、それが「204コンテンツなし」の応答を尊重できるように、一時的にメッセージのプレビュー部分をバッファリングするためにコミットしていることに注意してください。メッセージの残りは必ずしもバッファリングされていません。それは、100-続行した後、ICAPサーバに別のソースから直接パイプライン化される可能性があります。
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.
そのリクエストヘッダには、オブジェクトが変更を必要としない場合は、サーバーが「204コンテンツなし」の応答でメッセージに返信する可能性があることを示す：ICAPクライアントは、「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.
前のセクションで説明したように、このルールの唯一の例外は、メッセージプレビューの場合です。ヘッダ：この場合、元の要求は「204を許可する」を持っていなかった場合でも、ICAPサーバは、メッセージのプレビューに対応して204コンテンツなしメッセージで応答することができます。
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 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.
ISTag（「ICAPサービスタグ」）レスポンスヘッダフィールドは、ICAPサーバはサービスの現在の状態を表すICAPクライアントにサービス固有の「クッキー」を送信するための方法を提供します。これは、例えば、サービスのソフトウェアのバージョンまたは構成の表現であってもよい（NULL文字を含まない）データの32バイト最大英数字文字列です。 ISTagは、前回のICAPサーバの応答がまだそれらをキャッシュできるICAPクライアントによって新鮮考えることができることを検証します。 ICAPサーバ上の変更は、以前の応答を無効にした場合、ICAPサーバは、そののISTagを変更することにより、ICAPクライアントのキャッシュの部分を無効にすることができます。 ISTagは、ICAPサーバからのすべてのICAP応答に含まれなければなりません。
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は、特定のエンティティ（オブジェクト）のためのバリデータであるが、の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-1c02798"
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クライアントは、ICAPサーバにHTTPリクエストを送信します。 ICAPサーバは、要求、HTTP応答、または全く変更が必要とされないこと（クライアントが示している場合、それは204の応答をサポートする）表示の修正バージョンを返します。
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リクエストを含まなければなりません。そのホップバイホップヘッダは、カプセル化されていない以外はヘッダとボディは、（もしあれば）の両方が、カプセル化されなければなりません。
The response from the ICAP server back to the ICAP client may take one of four forms:
バックICAPクライアントにICAPサーバからの応答は4つの形式のいずれかを取ることがあります。
- An error indication,
- エラー表示、
- A 204 indicating that the ICAP client's request requires no adaptation (see Section 4.6 for limitations of this response),
- 204（この応答の制限のために、セクション4.6を参照）ICAPクライアントの要求は全く適応を必要としないことを示します
- 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応答がエラー（例えば、403禁止）である場合、そのリクエスト変更要求のみの場合に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クライアントは、要求の通常の実行を継続する必要があります。 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クライアントMAYは、（例えば）、下流のクライアントやユーザーにエラーを返すことは、クライアントから到着したとして非適応要求を実行、または再適応を再試行してください。
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クライアントに返さなければなりません。
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」配列であることを前提としています。
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
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"
GET / HTTP / 1.1ホスト：www.origin-server.com受け入れ：text / htmlのを、text / plainのエンコードを受け入れる：クッキーを圧縮：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
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"
GET /修正パスHTTP / 1.1ホスト：www.origin-server.comビア：1.0 icap-server.net（ICAP例REQMODサービス1.1）を受け入れ：text / htmlのを、text / plainの、画像/ gif形式のAccept-エンコード：gzipで、圧縮した場合 - なし - マッチ：「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).
第二の例は、この場合、修飾されている要求はなくGETのPOSTであることを除いて、最初のと同様です。カプセル化されたコンテンツの長さ引数はPOSTメッセージの修正身体を反映するように変更されていることに注意してください。それは（図示せず）チャンク使用するため、外側のICAPメッセージは、Content-Lengthヘッダを必要としません。
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の例では、カプセル化ヘッダは、要求と応答の両方のために、転送ヘッダと転送本体との間の分割を示します。
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
POST /origin-resource/form.pl HTTP/1.1 Host: www.origin-server.com Accept: text/html, text/plain Accept-Encoding: compress Pragma: no-cache
POST /origin-resource/form.pl HTTP / 1.1ホスト：www.origin-server.com受け入れ：text / htmlで、text / plainの受け入れ-エンコード：プラグマを圧縮します。no-キャッシュを
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
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
POST /origin-resource/form.pl HTTP / 1.1ホスト：www.origin-server.comビア：1.0 icap-server.net（ICAP例REQMODサービス1.1）を受け入れ：text / htmlのを、text / plainの、画像/ gifの受け入れ-encoding：GZIP、プラグマを圧縮します。no-キャッシュのContent-Length：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.
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
GET /naughty-content HTTP/1.1 Host: www.naughty-site.com Accept: text/html, text/plain Accept-Encoding: compress
GET /いたずら-コンテンツHTTP / 1.1ホスト：www.naughty-site.com受け入れ：text / htmlで、text / plainの受け入れ-エンコード：圧縮
----------------------------------------------------------------
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
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日午後04時02分10秒GMTサーバ：Apacheの/ 1.3.12（Unixの）のLast-Modified：木、2000年11月2日13時51分37秒GMTのETagを：「63600-1989- 3a017169" のContent-Length：58 Content-Typeの：text / htmlの
3a Sorry, you are not allowed to access that naughty content. 0
図3（a）申し訳ありませんが、あなたはそのいたずらなコンテンツにアクセスすることを許可されていません。 0
----------------------------------------------------------------
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レスポンスを送信し、。修飾法を要求するために同様の、ICAPサーバからの応答は、適応HTTP応答、エラー、または全く適応が必要とされないことを示す204応答コードとすることができます。
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.
セクション4.4に記載のカプセル化を使用して、修正するHTTPレスポンスのヘッダとボディは、ICAP本体に含まれなければなりません。利用可能な場合、元のクライアント要求のヘッダも含まれるべきです。他の方法と同様に、カプセル化されたメッセージのホップバイホップヘッダは転送されてはいけません。カプセル化ヘッダは、これらの4つの部分のそれぞれの先頭のバイト・オフセットを指定する必要があります。
The response from the ICAP server looks just like a reply in the Request Modification method (Section 4.8); that is,
ICAPサーバからの応答は、単に要求変更方法（4.8節）での回答のように見えます。あれは、
- An error indication,
- エラー表示、
- 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.
- ICAPクライアントの要求は何の適応を必要としないことを示すHTTPレスポンス204。
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クライアントは応答の通常の実行を継続する必要があります。 ICAPクライアントは、応答（例えば、そのキャッシュ可能性）についてさらに意思決定を行うために、応答のメッセージヘッダのヘッダを再検討するかもしれません。
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クライアント/サーバーのトランザクションで意味をなすので、エラーを示す他の戻りコードの場合、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クライアントに返さなければなりません。
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".
実施例4では、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
GET /origin-resource HTTP/1.1 Host: www.origin-server.com Accept: text/html, text/plain, image/gif Accept-Encoding: gzip, compress
原点リソースHTTP / GET / 1.1ホスト：www.origin-server.com受け入れ：text / htmlで、text / plainの、画像/ gif形式は受け入れエンコード：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 200 OK日：月、2000年1月10日9時52分22秒GMTサーバ：Apacheの/ 1.3.6（UNIX）のETag： "63840-1ab7-378d415b" のContent-Type：text / htmlでのコンテンツの長さ：51
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
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 200 OK日：月、2000年1月10日午前9時55分21秒GMT経由：1.0 icap.example.org（ICAP例RESPMODサービス1.1）サーバー：Apacheの/ 1.3.6（UNIX）のETag：「63840-1ab7- 378d415b」のContent-Type：text / htmlでのコンテンツの長さ：92
5c This is data that was returned by an origin server, but with value added by an ICAP server. 0
図5cこれは、オリジンサーバから返されたデータであるが、ICAPサーバによって付加価値を有します。 0
----------------------------------------------------------------
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「OPTIONS」方法は、ICAPサーバから設定情報を取得するために、ICAPクライアントによって使用されます。この方法では、ICAPクライアントは、要求が特定のICAPリソース宛に送信し、URIで指定されたサービスに固有のオプションを使用して応答をバック受け取ります。すべてのオプションの要求は、サーバー（つまり、すべてのサービスに適用されます）へのグローバルなオプションを返すことがあります。
The OPTIONS method consists of a request-line, as described in Section 4.3.2, such as the following example:
例えば、次の例のように、セクション4.3.2に記載したようにOPTIONSメソッドは、リクエストラインで構成されています。
OPTIONS icap://icap.server.net/sample-service ICAP/1.0 User-Agent: ICAP-client-XYZ/1.001
OPTIONSのICAP：//icap.server.net/sample-service ICAP / 1.0のUser-Agent：ICAPクライアント-XYZ / 1.001
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（例えば、ホスト）に記載されているように他のヘッダもまた許容されます。
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.
随意オプト体続くヘッダフィールド名と値のペアの系列に続くセクション4.3.3に記載したようにOPTIONS応答は、ステータスラインで構成されています。値フィールドの複数の値をカンマで区切る必要があります。 OPT-体はOPTIONS応答中に存在する場合、オプト体型ヘッダは、OPT-本体のフォーマットを記述する。
The OPTIONS headers supported in this version of the protocol are:
プロトコルのこのバージョンでサポートされているオプションヘッダは、次のとおりです。
-- 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応答に含まれなければなりません。それは、すべてのICAPサーバの実装によってサポートされなければならないので、OPTIONSメソッドは、メソッドリスト中であってはなりません。各サービスは、明確なURIを持っているし、OPTIONS（セクション6.4を参照）に加えて、1つの方法だけをサポートする必要があります。
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-12E4-2"
-- Encapsulated:
- カプセル化：
This header MUST be included in the OPTIONS response; see Section 4.4.
このヘッダは、OPTIONS応答に含まれなければなりません。 4.4節を参照してください。
For example: Encapsulated: opt-body=0
たとえば、次のようにカプセル化された：OPT-ボディ= 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.
オプト本体のフォーマットを識別するトークン。 （有効OPT-体タイプはICAPによって定義されていない。）このヘッダは、OPT-ボディタイプが存在する場合にのみ、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応答に含まれるかもしれません。オプション-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.
RFC 1123に準拠した日付/時刻文字列として指定されたサーバのクロック、。このヘッダは、OPTIONS応答に含まれるかもしれません。
For example: Date: Fri, 15 Jun 2001 04:33:55 GMT
たとえば、次の日：金、2001年6月15日午前四時33分55秒GMT
-- 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
-- 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応答に含まれるかもしれません。複数のファイル拡張子の値は、カンマで区切る必要があります。ワイルドカード値「*」は、任意の他のTransfer- *ヘッダーで指定されていないすべてのファイル拡張子のデフォルトの動作を（下記参照）を指定します。
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
たとえば、次の転送 - コンプリート：ASP、バット、EXE、COM、OLE
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).
注意：Transfer- *のいずれかが送信される場合は、正確に一つそれらのデフォルトを指定するには、「*」ワイルドカード値を含まなければなりません。何Transfer- *が送信されない場合は、すべての応答が（プレビューなし）、それらの全体が送信されます。
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クライアントは、提供されるサービスの構成情報を取得するために、ICAPサービスの名前icap.server.net/sample-serviceにOPTIONSリクエストを送信します。
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 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 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サーバの回答は、他の代理は、HTTPレスポンスをキャッシュするかもしれないと同じように、ICAPクライアントによってキャッシュされる場合があります。 HTTPと同様に、ICAPクライアントは常に成功応答を保存するキャッシュエントリとして（セクション4.8.2と4.9.2を参照）、およびそれが新鮮であれば、検証せずにそれを返す場合があります。 ICAPサーバは、[4] HTTP / 1.1に記載のキャッシュディレクティブを使用します。
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
リクエスト変更モードでは、ICAPサーバ（NOT ICAPメッセージ本体のカプセル化されたHTTPリクエストで）ICAP応答のICAPヘッダ部内のキャッシュ指令を含むかもしれません。に応じて
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サーバを追加または（NOT ICAPヘッダ部内の）カプセル化されたHTTPレスポンスに位置するHTTPキャッシュディレクティブを変更することができます。その結果、ICAPクライアントがREQMODの場合、およびRESPMODの場合、カプセル化されたHTTPレスポンスにICAPヘッダ内のディレクティブをキャッシュするはずです。
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サーバは、応答修正モードと同様に、オリジンサーバによって作成されたオブジェクトの変更されたバージョンを返す場合には、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サーバは、リクエスト変更モードと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節を参照してください。
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適応。これは、適応要求がクライアントから到着するたびに実行されます。これは、要求は「キャッシュに向かう途中で、」あるときに行わ適応したものです。こうした現在キャッシュされたオブジェクトの状態などの要因が、この要求は、実際に（代わりにキャッシュのディスクをオフに役立ったばかり、と言うの）オリジンサーバに転送されますかどうかを決定します。適応のこのタイプの例では、クライアントごとに実行されなければならない特別なアクセス制御や認証サービスになります。
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）と同様の要求を適応したものですが、それは「キャッシュのうち自分の道に」ある要求を記述する。すなわち、要求が実際にオリジンサーバが連絡されている必要があります。これらの適応要求は必ずしも特定のクライアントに固有のものではありません。例では、「同意する：」の追加となり、特別なデバイスのヘッダー。これらの適応は、潜在的に多くのクライアントに適用することができます。
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).
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クライアント実装のために重要ではあるが、区別がICAPプロトコル自体のために重要ではありません。 ICAPサーバの観点から、リクエストが要求される - ICAPサーバは、ポリシーが要求を生成するために、ICAPクライアントを率いて何気にしません。したがって、我々は、簡単のためにICAPこれらの4つのチャンネルを明示しませんでした。
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ソフトウェアおよびそれらが実装されているクライアントとサーバ間で通信されるエラーについて説明します。このようなエラーは、実装依存であり、彼らがあるため、必ずしも統一する必要はありませんが、「箱の中」、彼らは過去の実装経験に基づいて将来の実装者へのアドバイスとして、ここで提示されています。
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
1000 ICAP_CANT_CONNECT: "Cannot connect to ICAP server".
1000年ICAP_CANT_CONNECT：「ICAPサーバーに接続できません」。
The ICAP server is not connected on the socket. Maybe the ICAP
server is dead or it is not connected on the socket.
1001 ICAP_SERVER_RESPONSE_CLOSE: "ICAP Server closed connection while reading response".
1001 ICAP_SERVER_RESPONSE_CLOSE：「応答を読みながらICAPサーバーが接続を閉じました」。
The ICAP server TCP-shutdowns the connection before the ICAP
client can send all the body data.
1002 ICAP_SERVER_RESPONSE_RESET: "ICAP Server reset connection while reading response".
1002 ICAP_SERVER_RESPONSE_RESET：「応答を読みながらICAPサーバーが接続をリセット」。
The ICAP server TCP-reset the connection before the ICAP client
can send all the body data.
1003 ICAP_SERVER_UNKNOWN_CODE: "ICAP Server sent unknown response code".
1003 ICAP_SERVER_UNKNOWN_CODE： "ICAP Serverは、未知の応答コードを送りました"。
An unknown ICAP response code (see Section 4.x) was received by
the ICAP client.
1004 ICAP_SERVER_UNEXPECTED_CLOSE_204: "ICAP Server closed connection on 204 without 'Connection: close' header".
1004 ICAP_SERVER_UNEXPECTED_CLOSE_204：「：ヘッダICAPサーバは、 『密接』なしに204の接続を閉じました」。
An ICAP server MUST send the "Connection: close" header if
intends to close after the current transaction.
1005 ICAP_SERVER_UNEXPECTED_CLOSE: "ICAP Server closed connection as ICAP client wrote body preview".
1005 ICAP_SERVER_UNEXPECTED_CLOSE：「ICAPサーバはICAPクライアントがボディプレビューを書いたように、接続を閉じて」。
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:
HTTPで定義されるように簡単にするために、ICAPメッセージはカプセル化された本体部内の「チャンク」転送符号化を使用しなければなりません/ 1.1 [4]。これは、彼らが到着する上でどのような転送エンコーディングからチャンクするICAPクライアント実装は、「オンザフライ」の着信オブジェクトを変換する必要があります。しかし、変換は簡単です：
- 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-Lengthヘッダに示されるように、「コンテンツ長」ヘッダを使用して到着オブジェクトの場合、一つの大きなチャンクは同じサイズで作成することができます。
- 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).
- チャンクエンコーディングを使用して到着オブジェクトの場合、それらは、（再チャンキングなしで）であるように再送信することができます。
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サーバは、このようなサービスは、理論的には彼らの方法に基づいて区別されるかもしれない場合でも、それらが提供する各サービスにユニークな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やPOSTを実行し、二つの異なる結果を期待することは可能かもしれないHTTPで見られるものと同様です。 URIのオーバーロードのこの種の唯一の混乱を引き起こし、避けるべきです。
Authentication in ICAP is very similar to proxy authentication in HTTP as specified in RFC 2617. Specifically, the following rules apply:
具体的には、RFC 2617で指定されるようにICAPにおける認証は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サーバは、変更せずにこれらのヘッダを転送する必要があります。
- If authentication is required between an ICAP client and ICAP server, hop-by-hop Proxy Authentication as described in RFC 2617 MUST be used.
- RFC 2617に記載されているように認証がICAPクライアントとICAPサーバ、ホップバイホッププロキシ認証の間に必要とされる場合に使用しなければなりません。
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クライアントに自分自身を認証することが十分であることを前提としています。 RFC 2617で説明したようにこのタイプの認証はまた、プロキシ認証になります。
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クライアントは、上記のように関与しなければなりません。
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で説明したように、アップグレードヘッダは、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サーバは、当然のことながら、その上の任意の変換を実行することができません。
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サービスの検証が著しく困難になります。不正な改造は非適応コンテンツ中に存在していなかったセキュリティの脆弱性につながる可能性があります。
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に仕事をするだろう最も簡単なプロトコル、および無簡素を作ることでした。代替（非プロトコルベース）のソリューションを見つけることができる場所をいくつかの機能が拒否されました。加えて、我々は意図的に、我々はそうすることが、相互運用性を損なわないことを信じて、実装の裁量で多くの問題を残しています。
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は、コミュニティではよく理解されており、ソフトウェア・インフラストラクチャ（クライアント、サーバ、パーサなど）に大きな投資を享受しています。私たちの最初のデザインは、既存の作業を活用に焦点を当てました。我々は、既存のWebサーバで実行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から離れると、新たな（しかし似た）プロトコルを定義するよりも複雑で混乱だったことを決めました。
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 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カプセル化されたボディで必須です。まず、効率が重要であり、チャンクエンコーディングは、クライアントとサーバーの両方が、後で再利用するためのオープントランスポート層の接続を維持することができます。第二に、ICAPサーバ（およびその開発者）は、ユーザによって知覚される待ち時間を短縮するために、可能な場合は、「増分」の応答を生成するために奨励されるべきです。チャンクエンコーディングは、このタイプの実装をサポートする唯一の方法です。最後に、単一カプセル化メカニズムに標準化することにより、我々は、複数のメカニズムをサポートするために、クライアントとサーバーソフトウェアに必要とされるであろう複雑さを避けます。これは特に、セクション4.5に記載された「身体プレビュー」機能では、ICAPを簡素化します。
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.
カプセル化された遺体のチャンキングは必須ですが、カプセル化されたヘッダは、チャンク化されていません。この決定には2つの理由があります。まず、チャンクHTTPメッセージ本体がICAPメッセージ内にカプセル化されている場合には、ICAPクライアント（HTTPサーバ）非チャンク及びそれを再チャンク化することなく、ICAPサーバにHTTPクライアントから直接コピーすることができます。第二に、多くのヘッダ・パーサの実装は困難複数のチャンクで来るのヘッダーを扱っています。このドキュメントの以前のドラフトは、チャンクの境界がヘッダ内に入るではないことを義務付け。明確にするために、カプセル化ヘッダのチャンクは、単純に禁止されています。
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メッセージのカプセル化されたヘッダ部分にチャンク転送符号化を使用していないという欠点があります。具体的には、パーサはヘッダデータ（例えば、バッファ割り当てのために）来ているどのくらい事前にわかりません。 ICAPは、8.2節で説明した理由により、ヘッダ部にチャンクはできません。補償するために、「ヌル体」指令は、それがチャンクされていないにも関わらず、最終的なヘッダの長さを決定することを可能にします。
[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、 "統一資源識別子（URI）：一般的な構文とセマンティクス"、RFC 2396、1998年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[3]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、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.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[5] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[5] Khare、R.およびS.ローレンス、 "HTTP内TLSへのアップグレード/ 1.1"、RFC 2817、2000年5月。
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ネットワーク・アプライアンス株式会社495東ジャワ博士はカリフォルニア州サニーベール94089 USA
Phone: (408) 822-6000 EMail: lee.duggs@netapp.com
電話：（408）822-6000 Eメール：lee.duggs@netapp.com
Paul Eastham Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
ポール・イーストハムネットワーク・アプライアンス株式会社495東ジャワ博士はカリフォルニア州サニーベール94089 USA
Phone: (408) 822-6000 EMail: eastham@netapp.com
電話：（408）822-6000 Eメール：eastham@netapp.com
Debbie Futcher Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
デビーFutcherネットワーク・アプライアンス株式会社495東ジャワ博士はカリフォルニア州サニーベール94089 USA
Phone: (408) 822-6000 EMail: deborah.futcher@netapp.com
電話：（408）822-6000 Eメール：deborah.futcher@netapp.com
Don Gillies Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
ドン・ギリーズネットワーク・アプライアンス株式会社495東ジャワ博士はカリフォルニア州サニーベール94089 USA
Phone: (408) 822-6000 EMail: gillies@netapp.com
電話：（408）822-6000 Eメール：gillies@netapp.com
Steven La Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
スティーブン・ラ・ネットワーク・アプライアンス株式会社495東ジャワ博士はカリフォルニア州サニーベール94089 USA
Phone: (408) 822-6000 EMail: steven.la@netapp.com
電話：（408）822-6000 Eメール：steven.la@netapp.com
John Martin Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
ジョン・マーティンネットワーク・アプライアンス株式会社495東ジャワ博士はカリフォルニア州サニーベール94089 USA
Phone: (408) 822-6000 EMail: jmartin@netapp.com
電話：（408）822-6000 Eメール：jmartin@netapp.com
Jeff Merrick Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
ジェフ・メリックネットワーク・アプライアンス株式会社495東ジャワ博士はカリフォルニア州サニーベール94089 USA
Phone: (408) 822-6000 EMail: jeffrey.merrick@netapp.com
電話：（408）822-6000 Eメール：jeffrey.merrick@netapp.com
John Schuster Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
ジョン・シュスターネットワーク・アプライアンス株式会社495東ジャワ博士はカリフォルニア州サニーベール94089 USA
Phone: (408) 822-6000 EMail: john.schuster@netapp.com
電話：（408）822-6000 Eメール：john.schuster@netapp.com
Edward Sharp Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
エドワードシャープネットワーク・アプライアンス株式会社495東ジャワ博士はカリフォルニア州サニーベール94089 USA
Phone: (408) 822-6000 EMail: edward.sharp@netapp.com
電話：（408）822-6000 Eメール：edward.sharp@netapp.com
Peter Danzig Akamai Technologies 1400 Fashion Island Blvd San Mateo, CA 94404 USA
ピーター・ダンツィヒアカマイ・テクノロジーズ1400ファッションアイランドブルバードサンマテオ、CA 94404 USA
Phone: (650) 372-5757 EMail: danzig@akamai.com
電話：（650）372-5757 Eメール：danzig@akamai.com
Mark Nottingham Akamai Technologies 1400 Fashion Island Blvd San Mateo, CA 94404 USA
マーク・ノッティンガムアカマイ・テクノロジーズ1400ファッションアイランドブルバードサンマテオ、CA 94404 USA
Phone: (650) 372-5757 EMail: mnot@akamai.com
電話：（650）372-5757 Eメール：mnot@akamai.com
Nitin Sharma Akamai Technologies 1400 Fashion Island Blvd San Mateo, CA 94404 USA
ニティン・シャルマアカマイ・テクノロジーズ1400ファッションアイランドブルバードサンマテオ、CA 94404 USA
Phone: (650) 372-5757 EMail: nitin@akamai.com
電話：（650）372-5757 Eメール：nitin@akamai.com
Hilarie Orman Novell, Inc. 122 East 1700 South Provo, UT 84606 USA
ヒラリーオーマンノベル株式会社122東1700年南プロボ、UT 84606 USA
Phone: (801) 861-7021 EMail: horman@novell.com
電話：（801）861-7021 Eメール：horman@novell.com
Craig Blitz Novell, Inc. 122 East 1700 South Provo, UT 84606 USA
クレイグ・ブリッツノベル株式会社122東1700年南プロボ、UT 84606 USA
Phone: (801) 861-7021 EMail: cblitz@novell.com
電話：（801）861-7021 Eメール：cblitz@novell.com
Gary Tomlinson Novell, Inc. 122 East 1700 South Provo, UT 84606 USA
ゲイリー・トムリンソンノベル株式会社122東1700年南プロボ、UT 84606 USA
Phone: (801) 861-7021 EMail: garyt@novell.com
電話：（801）861-7021 Eメール：garyt@novell.com
Andre Beck Bell Laboratories / Lucent Technologies 101 Crawfords Corner Road Holmdel, New Jersey 07733-3030
アンドレ・ベックベル研究所/ルーセント・テクノロジーズ101 Crawfordsコーナー道路ホルムデル、ニュージャージー州07733から3030
Phone: (732) 332-5983 EMail: abeck@bell-labs.com
電話：（732）332-5983 Eメール：abeck@bell-labs.com
Markus Hofmann Bell Laboratories / Lucent Technologies 101 Crawfords Corner Road Holmdel, New Jersey 07733-3030
マーカス・ホフマンベル研究所/ルーセント・テクノロジーズ101 Crawfordsコーナー道路ホルムデル、ニュージャージー州07733から3030
Phone: (732) 332-5983 EMail: hofmann@bell-labs.com
電話：（732）332-5983 Eメール：hofmann@bell-labs.com
David Bryant CacheFlow, Inc. 650 Almanor Avenue Sunnyvale, California 94086
デビッド・ブライアントCacheFlow、Inc.の650 Almanorアベニューサニーベール、カリフォルニア94086
Phone: (888) 462-3568 EMail: david.bryant@cacheflow.com
電話：（888）462-3568 Eメール：david.bryant@cacheflow.com
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仕様で使用されるものと同様の拡張バッカスナウア記法（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.0"
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_URI 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節| 「OPTIONS」。 4.10 |拡張-方法。 4.3.2
Extension-Method = token
拡張-方法=トークン
ICAP_URI = Scheme ":" Net_Path [ "?" Query ] ; Section 4.2
ICAP_URI =スキーム "：" Net_Path [ "？"クエリ]; 4.2節
Scheme = "icap"
Schemeは= "ICAP"
Net_Path = "//" Authority [ Abs_Path ]
Net_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
;リクエストリクエスト・フィールド名=「許可」に固有のヘッダフィールド。 4.3.2 | 「許可」。 4.3.2 | 「から」。 4.3.2 | "ホスト" ; 4.3.2 | 「リファラー」。 4.3.2
| "User-Agent" ; Section 4.3.2
| "Preview" ; Section 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
;要求と応答コモン・フィールド名=「のCache-Control」の両方に共通のヘッダーフィールド。 4.3.1 | 「接続」; 4.3.1 | 「日付」。 4.3.1 | 「有効期限」。 4.3.1 | 「プラグマ」。 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>
ジェネリック・フィールド値= *（ジェネリック・フィールド・コンテンツ| LWS）ジェネリック・フィールド・コンテンツ= <オクテットは、フィールド値を構成すると、* TEXTまたはトークン、セパレーターの組み合わせのいずれかからなると引用符で囲まれた文字列>
Request-Body = *OCTET ; See Sections 4.4 and 4.5 for semantics
リクエスト・ボディ= * OCTET。セマンティクスのためのセクション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」。 [4]のセクション10.3.8
| "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
Extension-Code = 3DIGIT
拡張-コード= 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
理由-フレーズ= * <TEXT、除くCR、LF>
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
レスポンス・ボディ= * OCTET。セマンティクスのためのセクション4.4と4.5を参照してください。
Authors' Addresses
著者のアドレス
Jeremy Elson University of California Los Angeles Department of Computer Science 3440 Boelter Hall Los Angeles CA 90095
カリフォルニア州ロサンゼルスのジェレミー・エルソン大学コンピュータサイエンス学部3440 BoelterホールロサンゼルスCA 90095
Phone: (310) 206-3925 EMail: jelson@cs.ucla.edu
電話：（310）206-3925 Eメール：jelson@cs.ucla.edu
Alberto Cerpa University of California Los Angeles Department of Computer Science 3440 Boelter Hall Los Angeles CA 90095
カリフォルニア州ロサンゼルスのアルベルトCerpa大学コンピュータサイエンス学部3440 BoelterホールロサンゼルスCA 90095
Phone: (310) 206-3925 EMail: cerpa@cs.ucla.edu
電話：（310）206-3925 Eメール：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/を参照してください。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。