"request modificaiton" (reqmod) モードでは、ICAPクライアントはHTTPリクエストをICAPサーバーに送る。 ICAPサーバーは以下をしてもよい(may)。

1. リクエストの修正したバージョンを送り返す。ICAPクライアントはそれから、元のサーバーにコンタクトして修正されたリクエストを処理するか、別のICAPサーバーで更に修正するために、修正されたリクエストをパイプラインしてもよい。
2. HTTPレスポンスをリクエストに対して返す。これはエラーを返す時に使える。
3. エラーを返す。

ICAPクライアントはこれら三つのレスポンスタイプを全て扱えなくてはならない。しかし、エラーの扱いについては多少の自由が与えられている。エラーをすぐに返す、リトライする、など。

コンテントフィルタリングのアプリケーション例を使って、この方法を説明する。 元のサーバー上にあるウェブページに対するクライアントの要求を受けた代理(surrogate)について考えてみる。

ICAPクライアントとして働くこの代理は、クライアントの要求をICAPサーバーに送り、そこでURIベースのコンテントフィルタリングを行う。 要求されたURIへのアクセスが許可されるなら、その要求はICAPクライアントに修正なしで戻される。しかしICAPサーバーが、要求されたリソースへのアクセスを許可しないなら、サーバーは以下のいずれかをしても良い:

1. リクエストを修正し、元のURIの代わりにエラーメッセージを含むページをポイントする
2. HTTPエラーを示す、カプセル化されたHTTPレスポンスを返す

この方法は、様々な種類のアプリケーションで使うことができる。 典型的なデータの流れは以下のようになる。

origin-server
    | /|\
    |  |
 5  |  |  4
    |  |
   \|/ |              2
ICAP-client    -------------->   ICAP-resource
(surrogate)    <--------------   on ICAP-server
    | /|\             3
    |  |
 6  |  |  1
    |  |
   \|/ |
   client

1. クライアントはICAPクライアント(=代理)に、オリジンサーバー上にあるオブジェクトへのリクエストを行う。
2. 代理はそのリクエストをICAPサーバーに送る
3. ICAPサーバーは、リクエストに対するそのICAPリソースのサービスを実行し、修正されたリクエストを送るか、リクエストに対するレスポンスをICAPクライアントに返す。

もしステップ3においてリクエストを戻したら、

1. 代理はそのリクエスト(元々のクライアントリクエストとは異なるかもしれない)をオリジンサーバーに送る
2. オリジンサーバーはリクエストに対するレスポンスを返す
3. 代理はそのリプライ(ICAPサーバーまたはオリジンサーバーからの)をクライアントに返す

ウイルススキャンで言うと、例えばエンドユーザーのPCがファイルサーバーにファイルをアップロードする時にスキャンするモードです。ファイルサーバーにウイルスが入らないようにする。

"response modificaiton" (respmod)モードでは、ICAPクライアントはHTTPレスポンスをICAPサーバーに送る。(ICAPクライアントが送るレスポンスは、普通はオリジンサーバーによって生成されたものである) ICAPサーバーはそれから以下をしても良い:

1. 修正版のレスポンスを返す
2. エラーを返す

レスポンス修正方式は、HTTPレスポンスをクライアントに渡す前に行う事後処理(post-processing)を意図している。例として、特殊デバイスに表示するためのHTMLフォーマッティングや、言語翻訳、ウイルスチェック等がある。典型的なデータの流れは以下のようになる。

origin-server
    | /|\
    |  |
 3  |  |  2
    |  |
   \|/ |            4
ICAP-client    -------------->   ICAP-resource
(surrogate)    <--------------   on ICAP-server
    | /|\            5
    |  |
 6  |  |  1
    |  |
   \|/ |
   client

1. クライアントはICAPクライアント(=代理)に、オリジンサーバー上にあるオブジェクトへのリクエストを行う。
2. 代理はそのリクエストをオリジンサーバーに送る
3. オリジンサーバーはリクエストに対するレスポンスを返す
4. 代理はオリジンサーバーのリプライをICAPサーバーに送る
5. ICAPサーバーは、オリジンサーバーのリプライに対してそのICAPリソースのサービスを実行し、修正された可能性のあるリプライをICAPクライアントに返す
6. 代理はそのリプライ(ICAPサーバーまたはオリジンサーバーからの)をクライアントに返す

こちらのモードは、ファイルサーバーにすでにウイルス付きのファイルが入ってしまっている時に、エンドユーザーのPCにそれをダウンロードできないように、水際で食い止めるのが目的。ウイルス定義ファイルの更新が間に合わないときなど、サーバーへのウイルス潜入がありえます。

ICAPはHTTP/1.1にセマンティクスも使用法もよく似た、リクエスト/レスポンスプロトコルである。似ているが、ICAPはHTTPでは無く、HTTP上で動くアプリケーションプロトコルでも無い。例えばこれはつまり、HTTP surrogateがICAPメッセージをフォワードできないことを意味する。

ICAPはトランスポートプロトコルとしてTCP/IPを使う。デフォルトポートは1344であるが、他のポートを使っても良い。TCPフローは、ICAPクライアントが、受け身でリスニングしているICAPサーバーにinitiateする。

ICAPメッセージは、クライアントからサーバーへのリクエストと、サーバーからクライアントへのレスポンスからなる。リクエストとレスポンスは RFC 2822の一般的なメッセージフォーマットを使う。つまり、スタート行(リクエスト行またはステータス行)、ヘッダーフィールドの数("headers"としても知られる)、ヘッダーフィールドの終わりを示す空行、そしてメッセージボディーからなる。

ICAPメッセージのヘッダー行は、リクエストされているICAPリソースや、キャッシュ制御情報のようなメタデータを指定する。ICAPリクエストのメッセージボディーは、修正されようとしている(カプセル化された)HTTPメッセージを保持する。

HTTP/1.1の場合と同様、一つのトランスポートコネクションが、複数のリクエスト/レスポンスペアに対して再利用されてもよい。そのルールを具体的に言うと、複数のリクエストは、ある時点において、一つのトランスポートコネクション上にoutstandingなリクエストを一つしか許さないことで、レスポンスと対応づけられる。HTTPと同様に、複数の並列コネクションを使っても良い。

HTTPとよく似ているけどHTTPではなく、HTTP上で動く何かでもない。

全てのICAPリクエストはICAP URIを使って、サーバーから要求するICAPリソースを指定する。これは、完全なホスト名と要求するリソースのパスを両方指定する、絶対URIでなくてはならない。URIについてはRFC 2396参照。ICAPによって規定されるURIは、

icap://icap.example.net:2000/services/icap-service-1

のようになる。ICAPサーバーは全てのホスト名を認識できる必要がある。これはエイリアス、ローカルのvariations、数字表記するIPアドレスなど。

サービスの性質を変えるために、ICAPクライアントがICAPサーバーに渡したい引数は、ICAP-URIの一部として、HTTPで使われる標準的な"?"-エンコードされた引数-値のペアとして渡しても良い。例えば:

icap://icap.net/servies?mode=translate&lang=french

なるほど。HTTPのURIと同じパターンです。http/httpsの代わりにicapと書く。

以下のセクションでICAPメッセージで有効なヘッダーを定義する。 最初にリクエストとレスポンスに共通のヘッダーを説明する。リクエスト限定、レスポンス限定のヘッダーを次いで説明する。

ユーザー定義ヘッダー拡張を使っても良い。インターネットメールフォーマットで確立され、後にHTTPが採用した前例に適合するために、全てのユーザー定義ヘッダーは"X-"のnaming convention ("X-Extension-Header: Foo")に従う必要がある。ICAPの実装はどの"X-"ヘッダーを無視してもよい。

各ヘッダーフィールドは、name + ":" + フィールド値からなる。フィールド名は大文字、小文字の区別をしない。

”X-"ヘッダーまでHTTPと同じ。

RESPMOD icap://icap.example.net/translate?mode=french ICAP/1.0

ICAP/1.0 200 OK