[要約] RFC 3507は、インターネットコンテンツ適応プロトコル（ICAP）に関する仕様です。ICAPは、プロキシサーバーとコンテンツサーバー間でコンテンツの変換や分析を行うためのプロトコルです。このRFCの目的は、ICAPの機能と動作を定義し、インターネット上のコンテンツの適応性を向上させることです。
Network Working Group J. Elson
Request for Comments: 3507 A. Cerpa
Category: Informational UCLA
April 2003
Internet Content Adaptation Protocol (ICAP)
インターネットコンテンツ適応プロトコル（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.
Copyright（c）The Internet Society（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.
Open Pluggable Services（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クライアントは、何らかの変換または他の処理（「適応」）のために、HTTPメッセージをICAPサーバーに渡すことができます。サーバーはメッセージで変換サービスを実行し、通常は修正されたメッセージを使用してクライアントに応答を送信します。通常、適応されたメッセージは、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クライアントは、何らかの変換または他の処理（「適応」）のために、HTTPメッセージをICAPサーバーに渡すことができます。サーバーはメッセージで変換サービスを実行し、通常は修正されたメッセージを使用してクライアントに応答を送信します。適応されたメッセージは、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ページを別の広告で提供したい場合があります。現在、コンテンツプロバイダーは、キャッシュ不可能で追跡されているユーザーCookieなどのページをマークすることにより、このポリシーを実装しています。これにより、Origin Serverとネットワークに追加の負荷が課されます。私たちのアーキテクチャでは、ネットワークの端の近くでページをキャッシュすることができます。これらのエッジキャッシュは、ページがクライアントに提供されるたびに、近くの広告挿入サーバーに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).
コンテンツプロバイダーからの協力（コンテンツ配信ネットワークのように）、またはクライアントのネットワークプロバイダーが提供する付加価値サービス（代理など）として、他のそのような変換が可能です。これらの種類の変換の例は、Webページの異なる人間言語または特別な物理デバイス（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 SurrogatesまたはOriginサーバーは、代わりに他のサーバーに作業を出荷することにより、高価な操作の実行を避けることができます。これにより、複数のマシンに負荷を分配するのに役立ちます。たとえば、サロゲート（キャッシュプロキシなど）を介して実行可能なプログラムをダウンロードしようとするユーザーを検討してください。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クライアントとして機能し、リクエストのURIが許可されるようにチェックするサービスに発信リクエストを送信できます（たとえば、子供が表示するWebコンテンツの親の制御を可能にするシステム）。この場合、応答によって返されるオブジェクトではなく、適応されているのは *要求 *です。
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は、Origin Server、Surrogates、またはネットワーク自体の負荷を削減または配布するのに役立ちます。場合によっては、ICAPはネットワークの端近くの変換を促進し、基礎となるコンテンツのより大きなキャッシュ性を可能にします。他の例では、Origin ServerやSurrogatesなどのデバイスは、高価な操作を他のマシンに分配することで負荷を減らすことができます。すべての場合において、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によって定義されたこのワイヤプロトコルは、2番目の部分なしでは使用されていません。それが動作する付随するアプリケーションフレームワークです。より困難なポリシーの問題は、現在の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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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/1.1 [4]のセクション4で定義され、接続を介して送信された構文に一致するオクテットの構造化されたシーケンスで構成されるHTTP通信の基本単位。
request: An HTTP request message, as defined in Section 5 of HTTP/1.1 [4].
リクエスト：HTTP/1.1 [4]のセクション5で定義されているHTTP要求メッセージ。
response: An HTTP response message, as defined in Section 6 of HTTP/1.1 [4].
応答：HTTP/1.1 [4]のセクション6で定義されているHTTP応答メッセージ。
resource: A network data object or service that can be identified by a URI, as defined in Section 3.2 of HTTP/1.1 [4]. Resources may be available in multiple representations (e.g., multiple languages, data formats, size, resolutions) or vary in other ways.
リソース：HTTP/1.1 [4]のセクション3.2で定義されているように、URIによって識別できるネットワークデータオブジェクトまたはサービス。リソースは、複数の表現（複数の言語、データ形式、サイズ、解像度など）で利用できるか、他の方法で異なります。
client: A program that establishes connections for the purpose of sending requests.
クライアント：リクエストを送信する目的で接続を確立するプログラム。
server: An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, surrogate, gateway, or tunnel, switching behavior based on the nature of each request.
サーバー：応答を送信してリクエストをサービスするために接続を受け入れるアプリケーションプログラム。特定のプログラムは、クライアントとサーバーの両方になることができる場合があります。これらの用語の使用とは、プログラムの機能全般ではなく、特定の接続に対してプログラムによって実行される役割のみを指します。同様に、すべてのサーバーは、各リクエストの性質に基づいて、オリジンサーバー、サロゲート、ゲートウェイ、またはトンネルとして機能する場合があります。
origin server: The server on which a given resource resides or is to be created.
Origin Server：特定のリソースが存在するサーバー、または作成されるサーバー。
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.
Surrogate：Origin Serverと共同で、またはネットワーク内の異なるポイントで共同住宅が行われ、1つ以上のOriginサーバーの代わりに、通常は緊密な協力に取り組む権限を委任しました。通常、応答は内部キャッシュから配信されます。Surrogatesは、Origin ServerまたはOrigin Serverの代表者の別のサーバーからキャッシュエントリを導き出すことができます。場合によっては、代理人がそのような要求をトンネルすることがあります。
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.
Origin ServersとSurrogatesの間に密接な協力が存在する場合、[4]のキャッシュ制御指令を含むいくつかのプロトコル要件の変更が可能になります。このような変更はまだ完全に指定されていません。
Devices commonly known as "reverse proxies" and "(origin) server accelerators" are both more properly defined as surrogates.
一般的に「リバースプロキシ」と「（Origin）サーバーアクセラレータ」と呼ばれるデバイスは、どちらもサロゲートとしてより適切に定義されています。
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 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のセマンティクスを詳細に説明する前に、最初にプロトコルの主要な機能と予想される使用の一般的な概要を説明します。前述のように、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:
「Request Modification」（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クライアントは、Origin Serverに連絡して変更された要求を実行できます。または、さらに変更するために別の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: 1) Modify the request so that it points to a page containing an error message instead of the original URI.
アプリケーションの例：コンテンツフィルタリングを使用して、この方法を説明します。Origin Server上のWebページのクライアントからリクエストを受信する代理を検討してください。ICAPクライアントとして機能するSurrogateは、URIベースのコンテンツフィルタリングを実行するICAPサーバーにクライアントの要求を送信します。要求されたURIへのアクセスが許可されている場合、リクエストは変更されていないICAPクライアントに返されます。ただし、ICAPサーバーが要求されたリソースへのアクセスを許可することを選択した場合、1）リクエストを変更して、元のURIの代わりにエラーメッセージを含むページを指すように変更します。
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. クライアントは、Origin Server上のオブジェクトのICAP対応サロゲート（ICAPクライアント）にリクエストを行います。
2. The surrogate sends the request to the ICAP server.
2. Surrogateはリクエストを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. Surrogateは、元のクライアントリクエストとは異なるリクエストをOrigin Serverに送信します。
5. The origin server responds to request.
5. Origin Serverはリクエストに応答します。
6. The surrogate sends the reply (from either the ICAP server or the origin server) to the client.
6. サロゲートは、（ICAPサーバーまたはOrigin Serverから）応答をクライアントに送信します。
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クライアントから送信された応答は、通常、Origin Serverによって生成されました。）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. クライアントは、Origin Server上のオブジェクトのICAP対応サロゲート（ICAPクライアント）にリクエストを行います。
2. The surrogate sends the request to the origin server.
2. サロゲートは、リクエストをOrigin Serverに送信します。
3. The origin server responds to request.
3. Origin Serverはリクエストに応答します。
4. The ICAP-capable surrogate sends the origin server's reply to the ICAP server.
4. ICAP対応のサロゲートは、Origin Serverの返信を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サーバーは、Origin Serverの返信でICAPリソースのサービスを実行し、変更された可能性のある返信をICAPクライアントに送信します。
6. The surrogate sends the reply, possibly modified from the original origin server's reply, to the client.
6. 代理人は、元のOrigin Serverの返信から、おそらくクライアントに変更された返信を送信します。
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 Surrogatesによって転送できないことを意味します。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メッセージは、クライアントからサーバーへのリクエストと、サーバーからクライアントへの応答で構成されています。リクエストと応答は、RFC 2822 [3]の汎用メッセージ形式を使用します。つまり、起動ライン（リクエスト行またはステータス行のいずれか）、多くのヘッダーフィールド（「ヘッダー」とも呼ばれます）、空ですヘッダーフィールドの端を示す線（つまり、CRLFに先行するものがないライン）とメッセージボディ。
The header lines of an ICAP message specify the ICAP resource being requested as well as other meta-data such as cache control information. The message body of an ICAP request contains the (encapsulated) HTTP messages that are being modified.
ICAPメッセージのヘッダーラインは、要求されているICAPリソースと、キャッシュ制御情報などの他のメタデータを指定します。ICAPリクエストのメッセージ本文には、変更されている（カプセル化された）HTTPメッセージが含まれています。
As in HTTP/1.1, a single transport connection MAY (perhaps even SHOULD) be re-used for multiple request/response pairs. The rules for doing so in ICAP are the same as described in Section 8.1.2.2 of [4]. Specifically, requests are matched up with responses by allowing only one outstanding request on a transport connection at a time. Multiple parallel connections MAY be used as in HTTP.
HTTP/1.1のように、単一の輸送接続が複数のリクエスト/応答ペアに対して再利用される可能性があります（おそらくすべきです）。ICAPで行うためのルールは、[4]のセクション8.1.2.2で説明されているものと同じです。具体的には、リクエストは、一度に輸送接続に1つの未払いのリクエストのみを許可することにより、応答と一致します。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 = Scheme ":" Net_Path [ "?" Query ]
icap_uri = scheme "：" net_path ["？"クエリ]
Scheme = "icap"
Net_Path = "//" Authority [ Abs_Path ]
net_path = "//" authority [abs_path]
Authority = [ userinfo "@" ] host [ ":" port ]
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は、RFC 2396で定義されているものに新しいスキーム「ICAP」を追加します。ポートが空または指定されていない場合、ポート1344が想定されます。ICAP URIラインの例は次のようになるかもしれません：
icap://icap.example.net:2000/services/icap-service-1
icap：//icap.example.net：2000/services/icap-service-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サービスに合格してサービスの性質を変更したいという議論は、標準「？」 - HTTPで使用される属性値ペアのエンコードを使用して、ICAP-URIの一部として渡される場合があります。例えば：
icap://icap.net/service?mode=translate&lang=french
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-Extension-Header：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:
すべてのICAPメッセージのヘッダーには、ICAPで定義された次のディレクティブが含まれている場合があります。
Cache-Control Connection Date Expires Pragma Trailer Upgrade
キャッシュコントロール接続日は、プラグマトレーラーのアップグレードが期限切れになります
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 -Response Modification（セクション4.9）オプション - 構成について学ぶ（セクション4.10）
The OPTIONS method MUST be implemented by all ICAP servers. All other methods are optional and MAY be implemented.
オプションメソッドは、すべての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サーバーのリストを照会する必要があります。セクション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？mode = french 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:
ICAPリクエストでは、対応するHTTP要求ヘッダーと同じセマンティクスに従って、多くのリクエスト固有のヘッダーが許可されています（[4]のセクション5.3）。これらは：
Authorization Allow (see Section 4.6) From (see Section 14.22 of [4]) Host (REQUIRED in ICAP as it is in HTTP/1.1) Referer (see Section 14.36 of [4]) User-Agent
許可許可（[4]のセクション14.22を参照）ホスト（http/1.1にあるようにICAPで要求される）リファラー（[4]のセクション14.36を参照）user-agentの許可許可（セクション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（[4]のセクション6.1.1および10）で定義されたステータスコードと一致します。ただし、このドキュメントに特に示されている場合を除きます。N.B.100（セクション4.5）および204（セクション4.6）。
ICAP error codes that differ from their HTTP counterparts are:
HTTPのカウンターパートとは異なるICAPエラーコードは次のとおりです。
100 - Continue after ICAP Preview (Section 4.5).
100 -ICAPプレビュー（セクション4.5）の後に続行します。
204 - No modifications needed (Section 4.6).
204-変更は必要ありません（セクション4.6）。
400 - Bad request.
400不正な要求。
404 - ICAP Service not found.
404 -ICAPサービスが見つかりません。
405 - Method not allowed for service (e.g., RESPMOD requested for service that supports only REQMOD).
405-サービスには許可されていない方法（例：RECMODのみをサポートするサービスを要求しました）。
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-実装されていないメソッド。この応答は、オプションの実装が必須であるため、オプションリクエストに対して違法です。
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のResponse-Headerフィールドにより、サーバーは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 SurrogateがOrigin ServerにHTTP要求を行う場合、SurrogateのICAP機能のOrigin Serverにアドバイスすることがしばしば役立ちます。Origin Serverは、この情報を使用して応答をそれに応じて変更できます。たとえば、Origin Serverは、下流の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.
このICAP仕様は、HTTPクライアントとサーバー間の通信にHTTPがどのように使用されるかを義務付けることはできませんが、慣習を提案します。そのようなヘッダー（使用する場合）は「X-ICAP」で開始する必要があります。ICAPサービスを備えたHTTPクライアントには、「X-ICAP-version：1.0」ヘッダーとアプリケーション固有のヘッダーを最小限に含める必要があります。
The ICAP encapsulation model is a lightweight means of packaging any number of HTTP message sections into an encapsulating ICAP message-body, in order to allow the vectoring of requests, responses, and request/response pairs to an ICAP server.
ICAPカプセル化モデルは、リクエスト、応答、およびICAPサーバーへの要求/応答ペアのベクトル化を可能にするために、任意の数のHTTPメッセージセクションをカプセル化ICAPメッセージボディにパッケージ化する軽量の手段です。
This is accomplished by concatenating interesting message parts (encapsulatED sections) into a single ICAP message-body (the encapsulatING message). The encapsulated sections may be the headers or bodies of HTTP messages.
これは、興味深いメッセージパーツ（カプセル化されたセクション）を単一のICAPメッセージボディ（カプセル化メッセージ）に連結することによって達成されます。カプセル化されたセクションは、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
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のコンテンツレングスヘッダーとの一貫性のために10進表記です。
The special entity "null-body" indicates there is no encapsulated body in the ICAP message.
特別なエンティティ「null-body」は、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)
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 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
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と矛盾していないことに注意してください。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サロゲートを通過しているかのように、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クライアントからICAPサーバーに送信されたICAP REQMODまたは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.
- Virus-Checkersは、ファイルの種類、ファイル名拡張子、およびファイルの最初の数バイトを見るだけで、ファイルの大部分を「クリーン」として認定できます。残りのファイルのみをウイルスチェック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サーバーがすべてのGIF87ファイルをGIF89ファイルにトランスコードする場合、ファイルの最初の数本のボディバイトを調べることで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サーバーは、オプションメソッド（セクション4.10を参照）を使用して、リソースごとに特定のICAPアプリケーションに必要なプレビュー数を指定する必要があります。クライアントは、少なくとも4096バイトのプレビューを提供できる必要があります。さらに、プレビューが便利であることを示すICAPリソースを使用する場合、クライアントはプレビューを提供する必要があります。（この表示は、オプションメソッドまたは他の「バンド外」構成を介して提供される場合があります。）クライアントは、サーバーが受け入れる意思があることを示すよりも大きなプレビューを提供すべきではありません。
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リクエストのカプセル化されたボディに4096バイトのOrigin ServerデータをICAPサーバーに送信しようとすることを示します。ICAPクライアントは代理のように行動しており、Origin Serverの応答の全長を見つけるために前進していないため、実際の転送が少ない可能性があることに注意することが重要です。ICAPカプセル化されたヘッダーセクション全体が送信され、その後、カプセル化された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は、ICAPクライアントがプレビュープロセス中に予期せずに到着した場合、「EOF」をICAPサーバーに示す方法を定義します。これは、ヘッダーのみのHTTP応答がICAPクライアント（つまり、ボディのゼロバイト）に到着する場合、特に有用な最適化です。ICAPサーバーの完全な応答には、1回の丸い旅行のみが必要です。
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.
「IEOF」のHTTPチャンクエクステンションを定義して、ICAPチャンクが最後のチャンクであることを示します（[4]を参照）。ICAPサーバーは、Chunkデータを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:
たとえば、Origin ServerからHTTP応答ヘッダーを受信したばかりのICAPクライアントを検討し、ICAP RESPMODトランザクションをICAPサーバーに開始します。サーバーがコンテンツレングスヘッダーを使用していないため、Origin Serverから到着するボディバイトの数はまだわかりません。ICAPクライアントは、「プレビュー：1024」リクエストヘッダーを使用して1024バイトのプレビューを送信することをICAPサーバーに通知します。HTTP Origin Serverがデータを送信する前に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コントンの応答を送信してはなりません。（対照的に、Origin Responseが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または変更された応答>（IEOFのために100が禁止され続けます）
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 <no 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.
ICAPクライアントには、要求ヘッダーに「許可：204」を含めることができます。これには、オブジェクトが変更を必要としない場合、サーバーが「204コンテンツなし」応答でメッセージに返信できることを示します。
If an ICAP server receives a request that does not have "Allow: 204", it MUST NOT reply with a 204. In this case, an ICAP server MUST return the entire message back to the client, even though it is identical to the message it received.
ICAPサーバーが「許可：204」がないリクエストを受信した場合、204に返信してはなりません。この場合、ICAPサーバーはメッセージと同じですが、メッセージ全体をクライアントに戻す必要があります。受け取った。
The ONLY EXCEPTION to this rule is in the case of a message preview, as described in the previous section. If this is the case, an ICAP server can respond with a 204 No Content message in response to a message preview EVEN if the original request did not have the "Allow: 204" header.
このルールの唯一の例外は、前のセクションで説明されているように、メッセージプレビューの場合です。この場合、ICAPサーバーは、元のリクエストに「Allow：204」ヘッダーがなかった場合でも、メッセージプレビューに応答して204 NOコンテンツメッセージで応答できます。
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 Service Tag"）Response-Headerフィールドは、ICAPサーバーがサービス固有の「Cookie」をサービスの現在の状態を表すICAPクライアントに送信する方法を提供します。これは、たとえば、ソフトウェアバージョンまたはサービスの構成の表現である可能性がある、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：" quoted-string
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),
- ICAPクライアントのリクエストには適応が不要であることを示す204（この応答の制限については、セクション4.6を参照）、
- 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クライアントがサロゲートである場合、これにはキャッシュからオブジェクトを提供するか、変更されたリクエストをOrigin Serverに転送することが含まれます。注2XX ICAP応答がカプセル化されたHTTPエラー応答を含めるために有効であり、ICAPクライアントがダウンストリームクライアントに返す必要があります。
For other return codes that indicate an error, the ICAP client MAY (for example) return the error to the downstream client or user, execute the unadapted request as it arrived from the client, or re-try the adaptation again.
エラーを示す他のリターンコードの場合、ICAPクライアントは（たとえば）下流のクライアントまたはユーザーにエラーを返すか、クライアントから到着したときに適用されていない要求を実行するか、適応を再試行することができます。
The modified request headers, if any, MUST be returned to the ICAP client using appropriate encapsulation as described in Section 4.4.
セクション4.4で説明されているように、適切なカプセル化を使用して、変更された要求ヘッダーをICAPクライアントに返す必要があります。
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サーバーは、いくつかのヘッダーを変更し、元のリクエストからCookieを削除します。
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"
----------------------------------------------------------------
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"
----------------------------------------------------------------
The second example is similar to the first, except that the request being modified in this case is a POST instead of a GET. Note that the encapsulated Content-Length argument has been modified to reflect the modified body of the POST message. The outer ICAP message does not need a Content-Length header because it uses chunking (not shown).
2番目の例は、最初の例に似ていますが、この場合に変更されているリクエストは、GETの代わりに投稿です。カプセル化されたコンテンツレングスの引数は、投稿メッセージの変更された本文を反映するように変更されていることに注意してください。外側のICAPメッセージには、チャンクを使用するため、コンテンツ長ヘッダーは必要ありません（図示せず）。
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
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
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
----------------------------------------------------------------
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
3a Sorry, you are not allowed to access that naughty content. 0
3a申し訳ありませんが、そのいたずらなコンテンツにアクセスすることは許可されていません。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サーバーにOrigin Serverの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クライアントは、クライアントの取得の結果として返されたエンティティの変更を要求しています。元のクライアントの取得は、「www.origin-server.com」のOrigin Serverでした。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/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
33
This is data that was returned by an origin server.
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
5c This is data that was returned by an origin server, but with value added by an ICAP server. 0
5cこれは、Origin Serverによって返されたデータですが、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「オプション」メソッドは、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 icap://icap.server.net/sample-service ICAP/1.0 User-Agent: ICAP-client-XYZ/1.001 Other headers are also allowed as described in Section 4.3.1 and Section 4.3.2 (for example, Host).
オプションICAP：//icap.server.net/sample-service icap/1.0ユーザーエージェント：icap-client-xyz/1.001その他のヘッダーもセクション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で説明されているようにステータスラインで構成され、その後に一連のヘッダーフィールド名値ペアがオプションでオプトボディが続きます。値フィールドの複数の値は、コンマで分離する必要があります。Opt-Bodyがオプション応答に存在する場合、Opt-BodyタイプのヘッダーはOpt-Bodyの形式を説明します。
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).
このサービスでサポートされている方法。このヘッダーはオプション応答に含める必要があります。オプションメソッドは、すべてのICAPサーバーの実装でサポートする必要があるため、メソッドのリストに載ってはなりません。各サービスには異なるURIがあり、オプションに加えて1つの方法のみをサポートする必要があります（セクション6.4を参照）。
For example: Methods: RESPMOD
例：メソッド：respmod
-- Service:
- サービス：
A text description of the vendor and product name. This header MAY be included in the OPTIONS response.
ベンダーと製品名のテキスト説明。このヘッダーは、オプションの応答に含まれる場合があります。
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を参照してください。このヘッダーはオプション応答に含める必要があります。
For example: ISTag: "5BDEEEA9-12E4-2"
例：ISTAG： "5bdeeea9-12e4-2"
-- Encapsulated:
- カプセル化：
This header MUST be included in the OPTIONS response; see Section 4.4.
このヘッダーはオプション応答に含める必要があります。セクション4.4を参照してください。
For example: Encapsulated: opt-body=0
例：カプセル化：opt-body = 0
-- Opt-body-type:
- オプトボディタイプ：
A token identifying the format of the opt-body. (Valid opt-body types are not defined by ICAP.) This header MUST be included in the OPTIONS response ONLY if an opt-body type is present.
オプトボディの形式を識別するトークン。（有効なオプトボディタイプはICAPで定義されていません。）このヘッダーは、Opt-Bodyタイプが存在する場合にのみ、オプション応答に含める必要があります。
For example: Opt-body-type: XML-Policy-Table-1.0
例：opt-body-type：xml-policy-table-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接続の最大数。このヘッダーは、オプションの応答に含まれる場合があります。
For example: Max-Connections: 1500
例：最大接続：1500
-- Options-TTL:
-Options-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.
このオプション応答が有効な時間（秒単位）。何も指定されていない場合、オプションの応答は期限切れになりません。このヘッダーは、オプションの応答に含まれる場合があります。ICAPクライアントは、OptionSTTLの有効期限が切れたら、オプションリクエストを再発行できます。
For example: Options-TTL: 3600
例：Options-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準拠の日付/時刻文字列として指定されたサーバーのクロック。このヘッダーは、オプションの応答に含まれる場合があります。
For example:
Date: Fri, 15 Jun 2001 04:33:55 GMT
-- Service-ID:
-Service-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サービスを識別する短いラベル。属性ヘッダー名で使用できます。このヘッダーは、オプションの応答に含まれる場合があります。
For example: Service-ID: xyztech
例：service-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機能のリストを宣言する指令。このヘッダーは、オプションの応答に含まれる場合があります。このドキュメントでは、値「204」を定義して、ICAPサーバーが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クライアントによって送信されるバイト数。このヘッダーは、オプションの応答に含まれる場合があります。
For example: Preview: 1024
例：プレビュー：1024
-- Transfer-Preview:
- 転送-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サーバー全体を送信する前に、ICAPサーバーにプレビューする必要があるファイル拡張子のリスト。このヘッダーは、オプションの応答に含まれる場合があります。複数のファイル拡張値をコンマで区切る必要があります。ワイルドカード値 "*"は、他の転送 - *ヘッダーで指定されていないすべてのファイル拡張機能のデフォルト動作を指定します（以下を参照）。
For example: Transfer-Preview: *
例：転送-Preview： *
-- Transfer-Ignore:
- 転送igrore：
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サーバーに送信されないファイル拡張子のリスト。このヘッダーは、オプションの応答に含まれる場合があります。複数のファイル拡張子をコンマで分離する必要があります。
For example: Transfer-Ignore: html
例：Transfer-Ignore：HTML
-- Transfer-Complete:
- 転送-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サーバーに送信されるファイル拡張子のリスト。このヘッダーは、オプションの応答に含まれる場合があります。複数のファイル拡張値をコンマで区切る必要があります。
For example: Transfer-Complete: asp, bat, exe, com, ole
例：Transfer-Complete：ASP、BAT、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).
注：転送のいずれかが送信された場合、そのうちの1つは、デフォルトを指定するためにワイルドカード値「*」を含める必要があります。転送が送信されない場合、すべての応答が完全に送信されます（プレビューなし）。
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.server.net/sample-serviceという名前のICAPサービスにオプションリクエストを送信します。
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サーバーは、HTTP/1.1 [4]で説明されているキャッシュ指令を使用します。
In Request Modification mode, the ICAP server MAY include caching directives in the ICAP header section of the ICAP response (NOT in the encapsulated HTTP request of the ICAP message body). In Response 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サーバーには、ICAP応答のICAPヘッダーセクションにキャッシュディレクティブを含めることができます（ICAPメッセージ本文のカプセル化HTTP要求ではありません）。応答変更モードでは、ICAPサーバーは、カプセル化されたHTTP応答にあるHTTPキャッシングディレクティブを追加または変更する場合があります（ICAPヘッダーセクションではありません）。したがって、ICAPクライアントは、REQMODの場合はICAPヘッダーのキャッシュディレクティブ、およびRESPMODの場合のカプセル化HTTP応答を探す必要があります。
In cases where an ICAP server returns a modified version of an object created by an origin server, such as in Response Modification mode, the expiration of the ICAP-modified object MUST NOT be longer than that of the origin object. In other words, ICAP servers MUST NOT extend the lifetime of origin server objects, but MAY shorten it.
ICAPサーバーが、応答変更モードなどのOrigin Serverによって作成されたオブジェクトの変更されたバージョンを返す場合、ICAP修正オブジェクトの有効期限はOriginオブジェクトのそれよりも長くてはなりません。言い換えれば、ICAPサーバーはOrigin Serverオブジェクトの寿命を延長してはなりませんが、短縮する場合があります。
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 Response-Headerは、クライアントにキャッシュヒントを提供するためにも使用される場合があることに注意してください。セクション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. Origin Serverへの途中でのリクエストの適応。このタイプの適応は（1）と同様のリクエストの適応でもありますが、「キャッシュから出ている」リクエストを説明しています。つまり、リクエストが実際にOriginサーバーに連絡する必要がある場合。これらの適応要求は、必ずしも特定のクライアントに固有のものではありません。例は、「Accept：」特別なデバイスのヘッダーを追加することです。これらの適応は、多くのクライアントに適用される可能性があります。
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. Origin Serverからの応答の適応。これは、「キャッシュへの途中」のオブジェクトの適応です。言い換えれば、これは代理人がキャッシュする前にオブジェクトで実行したいと思うかもしれない適応です。適応されたオブジェクトは、その後多くのクライアントに提供される場合があります。このタイプの適応の例は、ウイルスのチェックです。代理人は、キャッシュに入れる前に、キャッシュされたオブジェクトがクライアントに提供されるたびに、キャッシュに入れる前に、ウイルスの入っている起源の返信を一度チェックしたいと思うでしょう。
Adaptation of responses coming from the surrogate, heading back to the client. Although this type of adaptation, like (3), is the adaptation of a response, it is client-specific. Client reply adaptation is adaptation that is required every time an object is served to a client, even if all the replies come from the same cached object off of disk. Ad insertion is a common form of this kind of adaptation; e.g., if a popular (cached) object that rarely changes needs a different ad inserted into it every time it is served off disk to a client. Note that the relationship between adaptations of type (3) and (4) is analogous to the relationship between types (2) and (1).
代理から来る応答の適応、クライアントに戻ります。（3）のように、このタイプの適応は応答の適応ですが、クライアント固有です。クライアントの返信適応は、すべての返信がディスクから同じキャッシュされたオブジェクトから来た場合でも、オブジェクトがクライアントに提供されるたびに必要な適応です。広告挿入は、この種の適応の一般的な形式です。たとえば、めったに変更されない人気のある（キャッシュされた）オブジェクトが、クライアントにディスクから提供されるたびに、異なる広告を挿入する必要があります。タイプ（3）と（4）の適応との関係は、タイプ（2）と（1）の関係に類似していることに注意してください。
Although the distinction among these four adaptation points is critical for ICAP client implementations, the distinction is not significant for the ICAP protocol itself. From the point of view of an ICAP server, a request is a request -- the ICAP server doesn't care what policy led the ICAP client to generate the request. We therefore did not make these four channels explicit in ICAP for simplicity.
これらの4つの適応ポイント間の区別は、ICAPクライアントの実装にとって重要ですが、ICAPプロトコル自体にとって区別は重要ではありません。ICAPサーバーの観点から見ると、リクエストはリクエストです。ICAPサーバーは、ICAPクライアントがリクエストを生成するためにどのポリシーが導いたかを気にしません。したがって、これらの4つのチャネルを簡単にするためにICAPで明示的にしませんでした。
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.
ICAPサーバーはソケットに接続されていません。たぶん、ICAPサーバーが死んでいるか、ソケットに接続されていないでしょう。
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.
ICAPサーバーTCP-Shutdownは、ICAPクライアントがすべてのボディデータを送信できる前に接続を整理します。
1002 ICAP_SERVER_RESPONSE_RESET: "ICAP Server reset connection while reading response".
1002 ICAP_SERVER_RESPONSE_RESET：「RESPONDの読み取り中にICAPサーバーリセット接続」。
The ICAP server TCP-reset the connection before the ICAP client can send all the body data.
ICAPサーバーTCP-RESET ICAPクライアントがすべてのボディデータを送信する前に接続をリセットします。
1003 ICAP_SERVER_UNKNOWN_CODE: "ICAP Server sent unknown response code".
1003 ICAP_SERVER_UNKNOWN_CODE：「ICAPサーバーが不明な応答コードを送信した」。
An unknown ICAP response code (see Section 4.x) was received by the ICAP client.
未知のICAP応答コード（セクション4.xを参照）がICAPクライアントによって受信されました。
1004 ICAP_SERVER_UNEXPECTED_CLOSE_204: "ICAP Server closed connection on 204 without 'Connection: close' header".
1004 ICAP_SERVER_UNEXPECTED_CLOSE_204： "ICAPサーバーは、接続なしで204で接続を閉じました：閉じるヘッダー"。
An ICAP server MUST send the "Connection: close" header if intends to close after the current transaction.
ICAPサーバーは、現在のトランザクション後に閉じる予定がある場合は、「接続：閉じる」ヘッダーを送信する必要があります。
1005 ICAP_SERVER_UNEXPECTED_CLOSE: "ICAP Server closed connection as ICAP client wrote body preview".
1005 ICAP_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:
簡単にするために、ICAPメッセージは、HTTP/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.
- 「コンテンツ長」ヘッダーを使用して到着するオブジェクトの場合、コンテンツ長ヘッダーに示されているのと同じサイズの1つの大きなチャンクを作成できます。
- For objects arriving using a TCP close to signal the end of the object, each incoming group of bytes read from the OS can be converted into a chunk (by writing the length of the bytes read, followed by the bytes themselves)
- オブジェクトの端を信号に近づけてTCPを使用して到着するオブジェクトの場合、OSから読み取られたバイトの各グループをチャンクに変換できます（読み取られたバイトの長さを書き、バイト自体が続きます）
- For objects arriving using chunked encoding, they can be retransmitted as is (without re-chunking).
- チャンクされたエンコードを使用して到着するオブジェクトの場合、それらはそのまま再送信することができます（再チャンキングなし）。
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のこの状況は、HTTPで見られる状況と同様です。理論的には、同じURIにGETまたは投稿を実行し、2つの異なる結果を期待することができます。この種のURIの過負荷は混乱を引き起こすだけでなく、避けるべきです。
Authentication in ICAP is very similar to proxy authentication in HTTP as specified in RFC 2617. Specifically, the following rules apply:
ICAPの認証は、RFC 2617で指定されている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-authenticateの課題と応答は、クライアント（ユーザー）とOrigin Serverの間のエンドツーエンド認証のためのものです。プロキシ、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.
- ICAPクライアントとICAPサーバー間で認証が必要な場合は、RFC 2617で説明されているホップバイホッププロキシ認証を使用する必要があります。
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.
また、クライアントサーバーとOrigin Server間のエンドツーエンドの暗号化は、Surrogatesなどの仲介者による付加価値サービスの使用を排除する可能性が高いことに注意してください。もちろん、クライアントのメッセージを復号化できない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は、Originサーバーからユーザーに向かう途中のメッセージのセマンティクスの変更を引き起こすことを目的としています。正しく動作する代理の基準は、もはや定義しやすいものではありません。これにより、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クライアントは、メッセージボディの真っin中に「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.
最終的に、ICAPをHTTPに適合させるために必要な回避策のもつれは、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.
Chunkingは、3つの理由で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つの理由があります。第一に、chunked HTTPメッセージ本文がICAPメッセージにカプセル化されている場合、ICAPクライアント（HTTPサーバー）は、チャンキングなしでそれをHTTPクライアントからICAPサーバーに直接コピーしてからチャンクします。第二に、多くのHeader-Parserの実装は、複数のチャンクがあるヘッダーに対処するのが困難です。この文書の以前のドラフトは、チャンクの境界がヘッダー内にないことを義務付けていました。明確にするために、カプセル化されたヘッダーのチャンキングは単に許可されていません。
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で説明されている理由により、ヘッダーパートでチャンキングを許可しません。補償するために、「null-body」指令は、充電されていないにもかかわらず、最終的なヘッダーの長さを決定できるようにします。
[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", RFC 2396, August 1998.
[1] Berners-Lee、T.、Fielding、R。and 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[3] Resnick、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[5] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[5] Khare、R。およびS. Lawrence、「HTTP/1.1内のTLSへのアップグレード」、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は、John MartinとPeter Danzigのオリジナルアイデアに基づいています。多くの個人や組織は、次の貢献者（過去と現在）を含むICAPの開発に貢献しています。
Lee Duggs Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
Lee Duggs Network Appliance、Inc。495 East Java Dr. Sunnyvale、CA 94089 USA
Phone: (408) 822-6000 EMail: lee.duggs@netapp.com
電話：（408）822-6000メール：lee.duggs@netapp.com
Paul Eastham Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
Paul Eastham Network Appliance、Inc。495 East Java Dr. Sunnyvale、CA 94089 USA
Phone: (408) 822-6000 EMail: eastham@netapp.com
電話：（408）822-6000メール：easham@netapp.com
Debbie Futcher Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
Debbie Futcher Network Appliance、Inc。495 East Java Dr. Sunnyvale、CA 94089 USA
Phone: (408) 822-6000 EMail: deborah.futcher@netapp.com
電話：（408）822-6000メール：deborah.futcher@netapp.com
Don Gillies Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
Don Gillies Network Appliance、Inc。495 East Java Dr. Sunnyvale、CA 94089 USA
Phone: (408) 822-6000 EMail: gillies@netapp.com
電話：（408）822-6000メール：gillies@netapp.com
Steven La Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
Steven LA Network Appliance、Inc。495 East Java Dr. Sunnyvale、CA 94089 USA
Phone: (408) 822-6000 EMail: steven.la@netapp.com John Martin Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
電話：（408）822-6000メール：steven.la@netapp.com John Martin Network Appliance、Inc。495 East Java Dr. Sunnyvale、CA 94089 USA
Phone: (408) 822-6000 EMail: jmartin@netapp.com
電話：（408）822-6000メール：jmartin@netapp.com
Jeff Merrick Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
Jeff Merrick Network Appliance、Inc。495 East Java Dr. Sunnyvale、CA 94089 USA
Phone: (408) 822-6000 EMail: jeffrey.merrick@netapp.com
電話：（408）822-6000メール：jeffrey.merrick@netapp.com
John Schuster Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
John Schuster Network Appliance、Inc。495 East Java Dr. Sunnyvale、CA 94089 USA
Phone: (408) 822-6000 EMail: john.schuster@netapp.com
電話：（408）822-6000メール：john.schuster@netapp.com
Edward Sharp Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
Edward Sharp Network Appliance、Inc。495 East Java Dr. Sunnyvale、CA 94089 USA
Phone: (408) 822-6000 EMail: edward.sharp@netapp.com
電話：（408）822-6000メール：edward.sharp@netapp.com
Peter Danzig Akamai Technologies 1400 Fashion Island Blvd San Mateo, CA 94404 USA
Peter Danzig Akamai Technologies 1400 Fashion Island Blvd San Mateo、CA 94404 USA
Phone: (650) 372-5757 EMail: danzig@akamai.com
電話：（650）372-5757メール：danzig@akamai.com
Mark Nottingham Akamai Technologies 1400 Fashion Island Blvd San Mateo, CA 94404 USA
マークノッティンガムアカマイテクノロジーズ1400ファッションアイランドブルバードサンマテオ、カリフォルニア94404 USA
Phone: (650) 372-5757 EMail: mnot@akamai.com Nitin Sharma Akamai Technologies 1400 Fashion Island Blvd San Mateo, CA 94404 USA
電話：（650）372-5757メール：mnot@akamai.com Nitin Sharma Akamai Technologies 1400 Fashion Island Blvd San Mateo、CA 94404 USA
Phone: (650) 372-5757 EMail: nitin@akamai.com
電話：（650）372-5757メール：nitin@akamai.com
Hilarie Orman Novell, Inc. 122 East 1700 South Provo, UT 84606 USA
Hilalie Orman Novell、Inc。122 East 1700 South Provo、UT 84606 USA
Phone: (801) 861-7021 EMail: horman@novell.com
電話：（801）861-7021メール：horman@novell.com
Craig Blitz Novell, Inc. 122 East 1700 South Provo, UT 84606 USA
Craig Blitz Novell、Inc。122 East 1700 South Provo、UT 84606 USA
Phone: (801) 861-7021 EMail: cblitz@novell.com
電話：（801）861-7021メール：cblitz@novell.com
Gary Tomlinson Novell, Inc. 122 East 1700 South Provo, UT 84606 USA
ゲイリー・トムリンソン・ノベル・インク122イースト1700サウス・プロボ、UT 84606 USA
Phone: (801) 861-7021 EMail: garyt@novell.com
電話：（801）861-7021メール：garyt@novell.com
Andre Beck Bell Laboratories / Lucent Technologies 101 Crawfords Corner Road Holmdel, New Jersey 07733-3030
Andre Beck Bell Laboratories / Lucent Technologies 101 Crawfords Corner Road Holmdel、ニュージャージー07733-3030
Phone: (732) 332-5983 EMail: abeck@bell-labs.com
電話：（732）332-5983メール：abeck@bell-labs.com
Markus Hofmann Bell Laboratories / Lucent Technologies 101 Crawfords Corner Road Holmdel, New Jersey 07733-3030
Markus Hofmann Bell Laboratories / Lucent Technologies 101 Crawfords Corner Road Holmdel、ニュージャージー07733-3030
Phone: (732) 332-5983 EMail: hofmann@bell-labs.com David Bryant CacheFlow, Inc. 650 Almanor Avenue Sunnyvale, California 94086
電話：（732）332-5983メール：hofmann@bell-labs.com David Bryant Cacheflow、Inc。650 Almanor Avenue Sunnyvale、California 94086
Phone: (888) 462-3568 EMail: david.bryant@cacheflow.com
電話：（888）462-3568メール：david.bryant@cacheflow.com
Appendix A BNF Grammar for ICAP Messages
付録A 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-version = "icap/1.0"
ICAP-Message = Request | Response
icap-message = request |応答
Request = Request-Line *(Request-Header CRLF) CRLF [ Request-Body ]
request = request-line *（request-header crlf）crlf [request-body]
Request-Line = Method SP ICAP_URI SP ICAP-Version CRLF
Method = "REQMOD" ; Section 4.8
| "RESPMOD" ; Section 4.9
| "OPTIONS" ; Section 4.10
| Extension-Method ; Section 4.3.2
Extension-Method = token
ICAP_URI = Scheme ":" Net_Path [ "?" Query ] ; Section 4.2
Scheme = "icap"
Net_Path = "//" Authority [ Abs_Path ]
net_path = "//" authority [abs_path]
Authority = [ userinfo "@" ] host [ ":" port ]
Request-Header = Request-Fields ":" [ Generic-Field-Value ]
request-header = request-fields "：" [generic-field-value]
Request-Fields = Request-Field-Name | Common-Field-Name
request-fields = request-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
| "User-Agent" ; Section 4.3.2 | "Preview" ; Section 4.5
|"ユーザーエージェント" ;セクション4.3.2 |「プレビュー」;セクション4.5
; Header fields common to both requests and responses
Common-Field-Name = "Cache-Control" ; Section 4.3.1
| "Connection" ; Section 4.3.1
| "Date" ; Section 4.3.1
| "Expires" ; Section 4.3.1
| "Pragma" ; Section 4.3.1
| "Trailer" ; Section 4.3.1
| "Upgrade" ; Section 4.3.1
| "Encapsulated" ; Section 4.4
| Extension-Field-Name ; Section 4.3
Extension-Field-Name = "X-" token
extension-field-name = "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>
Request-Body = *OCTET ; See Sections 4.4 and 4.5 for semantics
Response = Status-Line *(Response-Header CRLF) CRLF [ Response-Body ]
Response = status-line *（Response-Header CRLF）CRLF [Response-Body]
Status-Line = ICAP-Version SP Status-Code SP Reason-Phrase CRLF
Status-Line = ICAP-Version SPステータスコードSP REASON-PHRASE 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]
| "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
Reason-Phrase = *<TEXT, excluding CR, LF>
Response-Header = Response-Fields ":" [ Generic-Field-Value ]
Response-Header = Response-Fields "：" [generic-field-value]
Response-Fields = Response-Field-Name | Common-Field-Name
Response-Fields = Response-Field-Name |コモンフィールド名
Response-Field-Name = "Server" ; Section 4.3.3 | "ISTag" ; Section 4.7
Response-field-name = "server";セクション4.3.3 |「ISTAG」;セクション4.7
Response-Body = *OCTET ; See Sections 4.4 and 4.5 for semantics
Authors' Addresses
著者のアドレス
Jeremy Elson University of California Los Angeles Department of Computer Science 3440 Boelter Hall Los Angeles CA 90095
カリフォルニア州エルソン大学ロサンゼルスコンピュータサイエンス科3440ボルトルホールロサンゼルスCA 90095
Phone: (310) 206-3925 EMail: jelson@cs.ucla.edu
電話：（310）206-3925メール：jelson@cs.ucla.edu
Alberto Cerpa University of California Los Angeles Department of Computer Science 3440 Boelter Hall Los Angeles CA 90095
カリフォルニア大学ロサンゼルス大学コンピュータサイエンス科3440ボルターホールロサンゼルスCA 90095
Phone: (310) 206-3925 EMail: cerpa@cs.ucla.edu
電話：（310）206-3925メール：cerpa@cs.ucla.edu
ICAP discussion currently takes place at icap-discussions@yahoogroups.com. For more information, see http://groups.yahoo.com/group/icap-discussions/.
ICAPディスカッションは現在、icap discussions@yahoogroups.comで行われています。詳細については、http：//groups.yahoo.com/group/icap-discussions/を参照してください。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。