RFC3507 日本語訳

3507 Internet Content Adaptation Protocol (ICAP). J. Elson, A. Cerpa. April 2003. (Format: TXT=98772 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                           J. Elson
Request for Comments: 3507                                      A. Cerpa
Category: Informational                                             UCLA
                                                              April 2003

コメントを求めるワーキンググループJ.エルソンの要求をネットワークでつないでください: 3507年のA.Cerpaカテゴリ: 情報のUCLA2003年4月

              Internet Content Adaptation Protocol (ICAP)

インターネット内容適合プロトコル(ICAP)

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

IESG Note

IESG注意

   The Open Pluggable Services (OPES) working group has been chartered
   to produce a standards track protocol specification for a protocol
   intended to perform the same of functions as ICAP.  However, since
   ICAP is already in widespread use the IESG believes it is appropriate
   to document existing usage by publishing the ICAP specification as an
   informational document.  The IESG also notes that ICAP was developed
   before the publication of RFC 3238 and therefore does not address the
   architectural and policy issues described in that document.

オープンPluggable Services(作品)ワーキンググループは、ICAPとして機能の同じくらいを実行することを意図するプロトコルのための標準化過程プロトコル仕様を作り出すためにチャーターされました。 しかしながら、ICAPが普及使用既に中であるので、IESGは、情報のドキュメントとしてICAP仕様を発表することによって既存の用法を記録するのが適切であると信じています。 IESGもICAPがRFC3238の公表の前に開発されたことに注意して、したがって、そのドキュメントで説明された建築するのと方針問題を扱いません。

Abstract

要約

   ICAP, the Internet Content Adaption Protocol, is a protocol aimed at
   providing simple object-based content vectoring for HTTP services.
   ICAP is, in essence, a lightweight protocol for executing a "remote
   procedure call" on HTTP messages.  It allows ICAP clients to pass
   HTTP messages to ICAP servers for some sort of transformation or
   other processing ("adaptation").  The server executes its
   transformation service on messages and sends back responses to the
   client, usually with modified messages.  Typically, the adapted
   messages are either HTTP requests or HTTP responses.

ICAP(インターネットContent Adaptionプロトコル)はHTTPサービスのための簡単なオブジェクトベースの満足しているベクトル決定を提供するのが目的とされたプロトコルです。 本質では、ICAPは、HTTPメッセージで「遠隔手続き呼び出し」を実行するための軽量のプロトコルです。 それで、ICAPクライアントはある種の変換か他の処理(「適合」)のためのICAPサーバにHTTPメッセージを通過できます。 サーバは、メッセージで変換サービスを実行して、クライアントと、通常変更されたメッセージで応答を返送します。 適合しているメッセージは、通常、HTTP要求かHTTP応答のどちらかです。

Elson & Cerpa                Informational                      [Page 1]

RFC 3507                          ICAP                        April 2003

[1ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

Table of Contents

目次

   1.   Introduction............................................3
   2.   Terminology.............................................5
   3.   ICAP Overall Operation..................................8
        3.1   Request Modification..............................8
        3.2   Response Modification............................10
   4.   Protocol Semantics.....................................11
        4.1   General Operation................................11
        4.2   ICAP URIs........................................11
        4.3   ICAP Headers.....................................12
              4.3.1   Headers Common to Requests and
                      Responses................................12
              4.3.2   Request Headers..........................13
              4.3.3   Response Headers.........................14
              4.3.4   ICAP-Related Headers in HTTP
                      Messages.................................15
        4.4   ICAP Bodies: Encapsulation of HTTP
              Messages.........................................16
              4.4.1   Expected Encapsulated Sections...........16
              4.4.2   Encapsulated HTTP Headers................18
        4.5   Message Preview..................................18
        4.6   "204 No Content" Responses outside of
              Previews.........................................22
        4.7   ISTag Response Header............................22
        4.8   Request Modification Mode........................23
              4.8.1   Request..................................23
              4.8.2   Response.................................24
              4.8.3   Examples.................................24
        4.9   Response Modification Mode.......................27
              4.9.1   Request..................................27
              4.9.2   Response.................................27
              4.9.3   Examples.................................28
        4.10  OPTIONS Method...................................29
              4.10.1  OPTIONS request..........................29
              4.10.2  OPTIONS response.........................30
              4.10.3  OPTIONS examples.........................33
   5.   Caching................................................33
   6.   Implementation Notes...................................34
        6.1   Vectoring Points.................................34
        6.2   Application Level Errors.........................35
        6.3   Use of Chunked Transfer-Encoding.................37
        6.4   Distinct URIs for Distinct Services..............37
   7.   Security Considerations................................37
        7.1   Authentication...................................37
        7.2   Encryption.......................................38
        7.3   Service Validation...............................38
   8.   Motivations and Design Alternatives....................39

1. 序論…3 2. 用語…5 3. ICAPの総合的な操作…8 3.1 変更を要求してください…8 3.2 応答変更…10 4. 意味論について議定書の中で述べてください…11 4.1 一般操作…11 4.2 ICAP URI…11 4.3 ICAPヘッダー…12 4.3 要求と応答に共通の.1個のヘッダー…12 4.3 .2 ヘッダーを要求してください…13 4.3 .3 応答ヘッダー…14 4.3 HTTPメッセージの.4個のICAP関連のヘッダー…15 4.4 ICAPボディー: HTTPメッセージのカプセル化…16 4.4 .1 カプセル化されたセクションは予想しました…16 4.4 .2はHTTPヘッダをカプセル化しました…18 4.5メッセージプレビュー…18 4.6 Previewsの外の「204いいえ内容」Responses…22 4.7 ISTag応答ヘッダ…22 4.8 変更モードを要求してください…23 4.8 .1 要求します。23 4.8 .2応答…24 4.8 .3の例…24 4.9 応答変更モード…27 4.9 .1 要求します。27 4.9 .2応答…27 4.9 .3の例…28 4.10 オプションメソッド…29 4.10.1 OPTIONS要求…29 4.10.2 OPTIONS応答…30 4.10.3 OPTIONSの例…33 5. キャッシュします。33 6. 実装注意…34 6.1ベクトル決定は指します…34 6.2 アプリケーションレベル誤り…35 6.3 Chunked転送コード化の使用…37 異なったサービスのための6.4の異なったURI…37 7. セキュリティ問題…37 7.1認証…37 7.2暗号化…38 7.3 合法化を修理してください…38 8. 動機とデザイン代替手段…39

Elson & Cerpa                Informational                      [Page 2]

RFC 3507                          ICAP                        April 2003

[2ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

        8.1   To Be HTTP, or Not to Be.........................39
        8.2   Mandatory Use of Chunking........................39
        8.3   Use of the null-body directive in the
              Encapsulated header..............................40
   9.   References.............................................40
   10.  Contributors...........................................41
   Appendix A   BNF Grammar for ICAP Messages..................45
   Authors' Addresses..........................................48
   Full Copyright Statement....................................49

または、8.1 HTTPになるように少しもそうしません…。39 8.2 分魂化の義務的な使用…39 8.3 Encapsulatedヘッダーにおけるヌルボディー指示の使用…40 9. 参照…40 10. 貢献者…41 ICAPのための付録A BNF文法は通信します…45人の作者のアドレス…48 完全な著作権宣言文…49

1.  Introduction

1. 序論

   As the Internet grows, so does the need for scalable Internet
   services.  Popular web servers are asked to deliver content to
   hundreds of millions of users connected at ever-increasing
   bandwidths.  The model of centralized, monolithic servers that are
   responsible for all aspects of every client's request seems to be
   reaching the end of its useful life.

インターネットが発展するので、スケーラブルなインターネットのサービスの必要性もそうします。 ポピュラーなウェブサーバーが絶えず増加する帯域幅で接された何億人ものユーザに内容を提供するように頼まれます。 すべてのクライアントの要求の全面に原因となる集結されて、一枚岩的なサーバのモデルは、役に立つ寿命の端に達しているように思えます。

   To keep up with the growth in the number of clients, there has been a
   move towards architectures that scale better through the use of
   replication, distribution, and caching.  On the content provider
   side, replication and load-balancing techniques allow the burden of
   client requests to be spread out over a myriad of servers.  Content
   providers have also begun to deploy geographically diverse content
   distribution networks that bring origin-servers closer to the "edge"
   of the network where clients are attached.  These networks of
   distributed origin-servers or "surrogates" allow the content provider
   to distribute their content whilst retaining control over the
   integrity of that content.  The distributed nature of this type of
   deployment and the proximity of a given surrogate to the end-user
   enables the content provider to offer additional services to a user
   which might be based, for example, on geography where this would have
   been difficult with a single, centralized service.

クライアントの数における成長について行くために、移動は、より一層模写、分配、およびキャッシュの使用でそのスケールにアーキテクチャに向かっています。 コンテンツプロバイダー側、模写、および負荷分散では、テクニックはサーバの無数の上に広げられるというクライアント要求の負担を許します。 また、コンテンツプロバイダーは、さまざまの満足している分配がクライアントが付属しているネットワークの「縁」の、より近くに発生源サーバをもたらすネットワークであると地理的に配布し始めました。 分配された発生源サーバか「代理」のこれらのネットワークで、コンテンツプロバイダーはその内容の保全のコントロールを保有している間、彼らの内容を分配できます。 このタイプの展開の分配された本質とエンドユーザの与えられた代理の近接は、コンテンツプロバイダーがユーザに対する例えばこれが単一の、そして、集結されたサービスによって難しい地理学に基づくかもしれない追加サービスを提供するのを可能にします。

   ICAP, the Internet Content Adaption Protocol, is a protocol aimed at
   providing simple object-based content vectoring for HTTP services.
   ICAP is, in essence, a lightweight protocol for executing a "remote
   procedure call" on HTTP messages.  It allows ICAP clients to pass
   HTTP messages to ICAP servers for some sort of transformation or
   other processing ("adaptation").  The server executes its
   transformation service on messages and sends back responses to the
   client, usually with modified messages.  The adapted messages may be
   either HTTP requests or HTTP responses.  Though transformations may
   be possible on other non-HTTP content, they are beyond the scope of
   this document.

ICAP(インターネットContent Adaptionプロトコル)はHTTPサービスのための簡単なオブジェクトベースの満足しているベクトル決定を提供するのが目的とされたプロトコルです。 本質では、ICAPは、HTTPメッセージで「遠隔手続き呼び出し」を実行するための軽量のプロトコルです。 それで、ICAPクライアントはある種の変換か他の処理(「適合」)のためのICAPサーバにHTTPメッセージを通過できます。 サーバは、メッセージで変換サービスを実行して、クライアントと、通常変更されたメッセージで応答を返送します。 適合しているメッセージは、HTTP要求かHTTP応答のどちらかであるかもしれません。 変換は他の非HTTP内容で可能であるかもしれませんが、それらはこのドキュメントの範囲を超えています。

Elson & Cerpa                Informational                      [Page 3]

RFC 3507                          ICAP                        April 2003

[3ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   This type of Remote Procedure Call (RPC) is useful in a number of
   ways.  For example:

Remote Procedure Call(RPC)のこのタイプは多くの方法で役に立ちます。 例えば:

   o  Simple transformations of content can be performed near the edge
      of the network instead of requiring an updated copy of an object
      from an origin server.  For example, a content provider might want
      to provide a popular web page with a different advertisement every
      time the page is viewed.  Currently, content providers implement
      this policy by marking such pages as non-cachable and tracking
      user cookies.  This imposes additional load on the origin server
      and the network.  In our architecture, the page could be cached
      once near the edges of the network.  These edge caches can then
      use an ICAP call to a nearby ad-insertion server every time the
      page is served to a client.

o 発生源サーバからオブジェクトのアップデートされたコピーを必要とすることの代わりにネットワークの縁の近くで内容の簡単な変換を実行できます。例えば、ページが見られるときはいつも、コンテンツプロバイダーは、異なった広告をポピュラーなウェブページに提供したがっているかもしれません。 現在、そのようなページが同じくらい非キャッシュ可能であって追跡しているユーザクッキーであるとマークすることによって、コンテンツプロバイダーはこの政策を実施します。 これは発生源サーバとネットワークに追加負荷を課します。 私たちのアーキテクチャでは、ネットワークの縁の近くでページを一度キャッシュできました。 そして、ページがクライアントにサービスされているときはいつも、これらの縁のキャッシュは近い広告挿入サーバにICAP呼び出しを使用できます。

      Other such transformations by edge servers are possible, either
      with cooperation from the content provider (as in a content
      distribution network), or as a value-added service provided by a
      client's network provider (as in a surrogate).  Examples of these
      kinds of transformations are translation of web pages to different
      human languages or to different formats that are appropriate for
      special physical devices (e.g., PDA-based or cell-phone-based
      browsers).

エッジサーバによる他のそのような変換はコンテンツプロバイダー(満足している流通機構のように)からの協力、または、クライアントのネットワーク内の提供者によって提供された付加価値が付いたサービスとして可能です(代理のように)。 これらの種類の変換に関する例は異なった人間の言語、または、異なった形式への特別なフィジカル・デバイス(例えば、PDAベースの、または、セル電話ベースのブラウザ)に、適切なウェブページの翻訳です。

   o  Surrogates or origin servers can avoid performing expensive
      operations by shipping the work off to other servers instead.
      This helps distribute load across multiple machines.  For example,
      consider a user attempting to download an executable program via a
      surrogate (e.g., a caching proxy).  The surrogate, acting as an
      ICAP client, can ask an external server to check the executable
      for viruses before accepting it into its cache.

o 代理か発生源サーバが、代わりに他のサーバに仕事を追っ払うことによって高価な操作を実行するのを避けることができます。 これは、複数のマシンの向こう側に負荷を分配するのを助けます。 例えば、代理(例えば、キャッシュしているプロキシ)を通して実行可能プログラムをダウンロードするのを試みるユーザを考えてください。 ICAPクライアントとして機能して、代理は、それをキャッシュに受け入れる前にウイルスのための実行可能をチェックするように外部のサーバに頼むことができます。

   o  Firewalls or surrogates can act as ICAP clients and send outgoing
      requests to a service that checks to make sure the URI in the
      request is allowed (for example, in a system that allows parental
      control of web content viewed by children).  In this case, it is a
      *request* that is being adapted, not an object returned by a
      response.

o ファイアウォールか代理が、要求におけるURIが許容されているのを(例えば子供によって見られたウェブ内容のペアレンタル・コントロールを許容するシステムで)確実にするためにICAPクライアントとして務めて、送信する要求をチェックするサービスに送ることができます。 この場合、それは応答で返されたオブジェクトではなく、適合させられている*要求*です。

   In all of these examples, ICAP is helping to reduce or distribute the
   load on origin servers, surrogates, or the network itself.  In some
   cases, ICAP facilitates transformations near the edge of the network,
   allowing greater cachability of the underlying content.  In other
   examples, devices such as origin servers or surrogates are able to
   reduce their load by distributing expensive operations onto other
   machines.  In all cases, ICAP has also created a standard interface
   for content adaptation to allow greater flexibility in content
   distribution or the addition of value added services in surrogates.

これらの例では、全部で、ICAPは、発生源サーバ、代理、またはネットワーク自体で負荷を減少するか、または分配するのを助けています。 いくつかの場合、基本的な内容の、よりすばらしいcachabilityを許容して、ICAPはネットワークの縁の近くで変換を容易にします。 他の例では、発生源サーバか代理などのデバイスは、高価な操作を他のマシンに広げることによって、彼らの負荷を減少させることができます。 また、すべての場合では、満足している適合が代理に満足している分配における、より大きい柔軟性か付加価値が付いたサービスの追加を許容するように、ICAPは標準インターフェースを作成しました。

Elson & Cerpa                Informational                      [Page 4]

RFC 3507                          ICAP                        April 2003

[4ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   There are two major components in our architecture:

私たちのアーキテクチャには2個の主要コンポーネントがあります:

   1. Transaction semantics -- "How do I ask for adaptation?"

1. トランザクション意味論--「私はどのように適合を求めますか?」

   2. Control of policy -- "When am I supposed to ask for adaptation,
      what kind of adaptation do I ask for, and from where?"

2. 方針のコントロール--「いつが私であるかは、適合を求めると思って、どこでどこからどういう適合を尋ねます」。

   Currently, ICAP defines only the transaction semantics.  For example,
   this document specifies how to send an HTTP message from an ICAP
   client to an ICAP server, specify the URI of the ICAP resource
   requested along with other resource-specific parameters, and receive
   the adapted message.

現在、ICAPはトランザクション意味論だけを定義します。 例えば、このドキュメントはどのようにICAPクライアントからICAPサーバにHTTPメッセージを送って、他のリソース特有のパラメタと共に要求されたICAPリソースのURIを指定して、適合しているメッセージを受け取るかを指定します。

   Although a necessary building-block, this wire-protocol defined by
   ICAP is of limited use without the second part: an accompanying
   application framework in which it operates.  The more difficult
   policy issue is beyond the scope of the current ICAP protocol, but is
   planned in future work.

必要なブロックですが、ICAPによって定義されたこのワイヤプロトコルは第二部なしで限られて役に立ちます: それが作動する付随のアプリケーションフレームワーク。 より難しい政策問題は、現在のICAPプロトコルの範囲を超えていますが、今後の活動で計画されています。

   In initial implementations, we expect that implementation-specific
   manual configuration will be used to define policy.  This includes
   the rules for recognizing messages that require adaptation, the URIs
   of available adaptation resources, and so on.  For ICAP clients and
   servers to interoperate, the exact method used to define policy need
   not be consistent across implementations, as long as the policy
   itself is consistent.

初期の実装では、私たちは、実装特有の手動の構成が方針を定義するのに使用されると予想します。 これは適合を必要とするメッセージを認識するための規則、利用可能な適合リソースのURIなどを含んでいます。 ICAPクライアントとサーバが共同利用するために、方針を定義するのに使用される正確なメソッドは実装の向こう側に一貫している必要はありません、方針自体が一貫している限り。

   IMPORTANT:
      Note that at this time, in the absence of a policy-framework, it
      is strongly RECOMMENDED that transformations SHOULD only be
      performed on messages with the explicit consent of either the
      content-provider or the user (or both).  Deployment of
      transformation services without the consent of either leads to, at
      best, unpredictable results.  For more discussion of these issues,
      see Section 7.

重要: このとき方針フレームワークがないときそれが強くそうであることに注意してください、RECOMMENDED、変換SHOULDはコンテンツプロバイダーかユーザのどちらかの明白な同意(ともに)でメッセージに実行されるだけです。 どちらかの同意のない変換サービスの展開は予測できない結果にせいぜいつながります。 これらの問題の、より多くの議論に関しては、セクション7を見てください。

   Once the full extent of the typical policy decisions are more fully
   understood through experience with these initial implementations,
   later follow-ons to this architecture may define an additional policy
   control protocol.  This future protocol may allow a standard policy
   definition interface complementary to the ICAP transaction interface
   defined here.

典型的な政策決定の完全な範囲がこれらの初期の実装の経験で、より完全にいったん理解されていると、このアーキテクチャへの後のフォローオンは追加方針制御プロトコルを定義するかもしれません。 この将来のプロトコルは標準約款定義インタフェース補色をここで定義されたICAPトランザクションインタフェースまで許容するかもしれません。

2.  Terminology

2. 用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [2].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。

Elson & Cerpa                Informational                      [Page 5]

RFC 3507                          ICAP                        April 2003

[5ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   The special terminology used in this document is defined below.  The
   majority of these terms are taken as-is from HTTP/1.1 [4] and are
   reproduced here for reference.  A thorough understanding of HTTP/1.1
   is assumed on the part of the reader.

本書では使用される特別な用語は以下で定義されます。 これらの用語の大部分が、HTTP/1.1[4]からそのままでかかって、参照のためにここで再生します。 HTTP/1.1の徹底的な理解は読者側の想定されます。

   connection:
      A transport layer virtual circuit established between two programs
      for the purpose of communication.

接続: トランスポート層の仮想の回路は2の間にコミュニケーションの目的のためのプログラムを設立しました。

   message:
      The basic unit of HTTP communication, consisting of a structured
      sequence of octets matching the syntax defined in Section 4 of
      HTTP/1.1 [4] and transmitted via the connection.

メッセージ: HTTP/1.1[4]のセクション4で定義されて、接続で伝えられた構文に合っている八重奏の構造化された系列から成るHTTPコミュニケーションの原単位。

   request:
      An HTTP request message, as defined in Section 5 of HTTP/1.1 [4].

以下を要求してください。 HTTP/1.1[4]のセクション5で定義されるようなHTTP要求メッセージ。

   response:
      An HTTP response message, as defined in Section 6 of HTTP/1.1 [4].

応答: HTTP/1.1[4]のセクション6で定義されるようなHTTP応答メッセージ。

   resource:
      A network data object or service that can be identified by a URI,
      as defined in Section 3.2 of HTTP/1.1 [4].  Resources may be
      available in multiple representations (e.g., multiple languages,
      data formats, size, resolutions) or vary in other ways.

リソース: HTTP/1.1[4]のセクション3.2で定義されるようにURIで特定できるネットワークデータ・オブジェクトかサービス。 リソースは、複数の表現(例えば、複数の言語、データ形式、サイズ、解決)で利用可能であるか、または他の方法で異なるかもしれません。

   client:
      A program that establishes connections for the purpose of sending
      requests.

クライアント: 要求を送る目的のために関係を樹立するプログラム。

   server:
      An application program that accepts connections in order to
      service requests by sending back responses.  Any given program may
      be capable of being both a client and a server; our use of these
      terms refers only to the role being performed by the program for a
      particular connection, rather than to the program's capabilities
      in general. Likewise, any server may act as an origin server,
      surrogate, gateway, or tunnel, switching behavior based on the
      nature of each request.

サーバ: 応答を返送することによって要求を修理するために接続を受け入れるアプリケーション・プログラム。 どんな与えられたプログラムもクライアントとサーバの両方であることができるかもしれません。 私たちのこれらの用語の使用は一般に、プログラムの能力にというよりむしろ特定の接続のためのプログラムで実行される役割だけについて言及します。 同様に、どんなサーバも発生源サーバ、代理、ゲートウェイ、またはトンネルとして務めるかもしれません、それぞれの要求の本質に基づく振舞いを切り換えて。

   origin server:
      The server on which a given resource resides or is to be created.

発生源サーバ: 住んでいるか、または作成される与えられたリソースがことであるサーバ。

Elson & Cerpa                Informational                      [Page 6]

RFC 3507                          ICAP                        April 2003

[6ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   proxy:
      An intermediary program which acts as both a server and a client
      for the purpose of making requests on behalf of other clients.
      Requests are serviced internally or by passing them on, with
      possible translation, to other servers.  A proxy MUST implement
      both the client and server requirements of this specification.

プロキシ: 他のクライアントを代表して要求をする目的のためのサーバとクライアントの両方として作動する仲介者プログラム。 要求は、内部的か可能な翻訳で他のサーバにそれらを伝えることによって、修理されます。 プロキシは、両方がこの仕様のクライアントとサーバ要件であると実装しなければなりません。

   cache:
      A program's local store of response messages and the subsystem
      that controls its message storage, retrieval, and deletion.  A
      cache stores cachable responses in order to reduce the response
      time and network bandwidth consumption on future, equivalent
      requests.  Any client or server may include a cache, though a
      cache cannot be used by a server that is acting as a tunnel.

以下をキャッシュしてください。 メッセージストレージ、検索、および削除を制御するプログラムの応答メッセージとサブシステムの地元の小売店。 キャッシュは、将来的で、同等な要求における応答時間とネットワーク回線容量消費を短縮するためにキャッシュ可能応答を保存します。 どんなクライアントやサーバもキャッシュを入れるかもしれません、トンネルとして機能しているサーバでキャッシュを使用できませんが。

   cachable:
      A response is cachable if a cache is allowed to store a copy of
      the response message for use in answering subsequent requests.
      The rules for determining the cachability of HTTP responses are
      defined in Section 13 of [4].  Even if a resource is cachable,
      there may be additional constraints on whether a cache can use the
      cached copy for a particular request.

キャッシュ可能: キャッシュがその後の要求に答えることにおける使用のための応答メッセージのコピーを保存できるなら、応答はキャッシュ可能です。 HTTP応答のcachabilityを決定するための規則は[4]のセクション13で定義されます。 リソースがキャッシュ可能であっても、キャッシュが特定の要求にキャッシュされたコピーを使用できるかどうかに関して追加規制があるかもしれません。

   surrogate:
      A gateway co-located with an origin server, or at a different
      point in the network, delegated the authority to operate on behalf
      of, and typically working in close co-operation with, one or more
      origin servers.  Responses are typically delivered from an
      internal cache.  Surrogates may derive cache entries from the
      origin server or from another of the origin server's delegates.
      In some cases a surrogate may tunnel such requests.

代理: ゲートウェイが発生源サーバ、またはネットワークにおけるa異なったポイントで共同場所を見つけて、密接な協力で作動して、通常働く権威を代表として派遣した、1つ以上の発生源サーバ。 応答は内部キャッシュから通常提供されます。 代理は発生源サーバか発生源サーバの代表の別のものからキャッシュエントリーを引き出すかもしれません。 いくつかの場合、代理はそのような要求にトンネルを堀るかもしれません。

      Where close co-operation between origin servers and surrogates
      exists, this enables modifications of some protocol requirements,
      including the Cache-Control directives in [4].  Such modifications
      have yet to be fully specified.

発生源サーバと代理の間の密接な協力が存在しているところでは、これはいくつかのプロトコル要件の変更を可能にします、[4]にCache-コントロール指示を含んでいて。 そのような変更はまだ完全に指定されているというわけではありません。

      Devices commonly known as "reverse proxies" and "(origin) server
      accelerators" are both more properly defined as surrogates.

「逆のプロキシ」と「(発生源)サーバアクセラレータ」として一般的に知られているデバイスはともにより適切に代理と定義されます。

   New definitions:

新しい定義:

   ICAP resource:
      Similar to an HTTP resource as described above, but the URI refers
      to an ICAP service that performs adaptations of HTTP messages.

ICAPリソース: 上で説明されるHTTPリソースと同様です、URIだけがHTTPメッセージの適合を実行するICAPサービスについて言及します。

Elson & Cerpa                Informational                      [Page 7]

RFC 3507                          ICAP                        April 2003

[7ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   ICAP server:
      Similar to an HTTP server as described above, except that the
      application services ICAP requests.

ICAPサーバ: アプリケーションがICAP要求を修理するのを除いて、上で説明されるHTTPサーバと同様です。

   ICAP client:
      A program that establishes connections to ICAP servers for the
      purpose of sending requests.  An ICAP client is often, but not
      always, a surrogate acting on behalf of a user.

ICAPクライアント: 要求を送る目的のためにICAPサーバに関係を樹立するプログラム。 しばしばである代理がユーザを代表して行動して、ICAPクライアントはいつもそうであるというわけではありません。

3.  ICAP Overall Operation

3. ICAPの総合的な操作

   Before describing ICAP's semantics in detail, we will first give a
   general overview of the protocol's major functions and expected uses.
   As described earlier, ICAP focuses on modification of HTTP requests
   (Section 3.1), and modification of HTTP responses (Section 3.2).

詳細にICAPの意味論について説明する前に、私たちは最初に、プロトコルの主要な機能と予想された用途の概要を与えるつもりです。 より早く説明されるように、ICAPはHTTP要求の変更(セクション3.1)、およびHTTP応答の変更(セクション3.2)に焦点を合わせます。

3.1  Request Modification

3.1 要求変更

   In "request modification" (reqmod) mode, an ICAP client sends an HTTP
   request to an ICAP server.  The ICAP server may then:

「要求変更」(reqmod)モードで、ICAPクライアントはHTTP要求をICAPサーバに送ります。ICAPサーバはそしてときにそうするかもしれません:

   1) Send back a modified version of the request.  The ICAP client may
      then perform the modified request by contacting an origin server;
      or, pipeline the modified request to another ICAP server for
      further modification.

1) 要求の変更されたバージョンを返送してください。 次に、ICAPクライアントは発生源サーバに連絡することによって、変更された要求を実行するかもしれません。 または、変更がさらなる変更のための別のICAPサーバに要求するパイプライン。

   2) Send back an HTTP response to the request.  This is used to
      provide information useful to the user in case of an error (e.g.,
      "you sent a request to view a page you are not allowed to see").

2) 要求へのHTTP応答を返送してください。 これは、誤りの場合にユーザの役に立つ情報を提供するのに使用されます(例えば、「あなたはあなたが見ることができない1ページを見るという要求を送りました」)。

   3) Return an error.

3) 誤りを返してください。

   ICAP clients MUST be able to handle all three types of responses.
   However, in line with the guidance provided for HTTP surrogates in
   Section 13.8 of [4], ICAP client implementors do have flexibility in
   handling errors.  If the ICAP server returns an error, the ICAP
   client may (for example) return the error to the user, execute the
   unadapted request as it arrived from the client, or re-try the
   adaptation again.

ICAPクライアントはすべての3つのタイプの応答を扱うことができなければなりません。 しかしながら、[4]のセクション13.8のHTTP代理に提供された指導に沿って、ICAPクライアント作成者は取り扱い誤りにおける柔軟性を持っています。 ICAPサーバが誤りを返すなら、ICAPクライアントは、(例えば) 誤りをユーザに返すか、クライアントから到着したので「非-適合させ」られた要求を実行するか、または再び適合を再試行するかもしれません。

   We will illustrate this method with an example application: content
   filtering.  Consider a surrogate that receives a request from a
   client for a web page on an origin server.  The surrogate, acting as
   an ICAP client, sends the client's request to an ICAP server that
   performs URI-based content filtering.  If access to the requested URI
   is allowed, the request is returned to the ICAP client unmodified.
   However, if the ICAP server chooses to disallow access to the
   requested resources, it may either:

私たちは例のアプリケーションをこのメソッドに入れるつもりです: コンテントのフィルタリング。 ウェブページのために発生源サーバにクライアントから要求を受け取る代理を考えてください。ICAPクライアントとして機能して、代理はURIベースのコンテントのフィルタリングを実行するICAPサーバにクライアントの要求を送ります。 要求されたURIへのアクセスを許すなら、ICAPクライアントに要求を変更されていなく返します。 しかしながら、ICAPサーバが、要求されたリソースへのアクセスを禁じるのを選ぶなら、選びます:

Elson & Cerpa                Informational                      [Page 8]

RFC 3507                          ICAP                        April 2003

[8ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   1) Modify the request so that it points to a page containing an error
      message instead of the original URI.

1) オリジナルのURIの代わりにエラーメッセージを含む1ページを示すように、要求を変更してください。

   2) Return an encapsulated HTTP response that indicates an HTTP error.

2) HTTP誤りを示すカプセル化されたHTTP応答を返してください。

   This method can be used for a variety of other applications; for
   example, anonymization, modification of the Accept: headers to handle
   special device requirements, and so forth.

他のさまざまなアプリケーションにこのメソッドを使用できます。 例えば、anonymization、Acceptの変更: 特別なデバイス要件などを扱うヘッダー。

   Typical data flow:

典型的なデータは流れます:

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

発生源サーバ| /|\ | | 5 | | 4 | | \|/ | 2ICAP-クライアント-------------->ICAP-リソース(代理)<。-------------- ICAP-サーバに関して| /|\ 3 | | 6 | | 1 | | \|/ | クライアント

   1. A client makes a request to a ICAP-capable surrogate (ICAP client)
      for an object on an origin server.

1. クライアントはオブジェクトのために発生源サーバでICAP有能な代理(ICAPクライアント)に要求を出します。

   2. The surrogate sends the request to the ICAP server.

2. 代理はICAPサーバに要求を送ります。

   3. The ICAP server executes the ICAP resource's service on the
      request and sends the possibly modified request, or a response to
      the request back to the ICAP client.

3. ICAPサーバは、ICAPクライアントへの要求に要求のときにICAPリソースのサービスを実行して、ことによると変更された要求、または応答を送ります。

   If Step 3 returned a request:

Step3が要求を返したなら:

   4. The surrogate sends the request, possibly different from original
      client request, to the origin server.

4. 代理はことによるとオリジナルのクライアント要求から発生源サーバまで異なった要求を送ります。

   5. The origin server responds to request.

5. 発生源サーバは要求に応じます。

   6. The surrogate sends the reply (from either the ICAP server or the
      origin server) to the client.

6. 代理は回答(ICAPサーバか発生源サーバのどちらかからの)をクライアントに送ります。

Elson & Cerpa                Informational                      [Page 9]

RFC 3507                          ICAP                        April 2003

[9ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

3.2  Response Modification

3.2 応答変更

   In the "response modification" (respmod) mode, an ICAP client sends
   an HTTP response to an ICAP server.  (The response sent by the ICAP
   client typically has been generated by an origin server.)  The ICAP
   server may then:

「応答変更」(respmod)モードで、ICAPクライアントはICAPサーバへのHTTP応答を送ります。. (ICAPクライアントによって送られた応答は発生源サーバによって通常生成されました。) ICAPサーバはそしてときにそうするかもしれません:

   1) Send back a modified version of the response.

1) 応答の変更されたバージョンを返送してください。

   2) Return an error.

2) 誤りを返してください。

   The response modification method is intended for post-processing
   performed on an HTTP response before it is delivered to a client.
   Examples include formatting HTML for display on special devices,
   human language translation, virus checking, and so forth.

それがクライアントに提供される前にHTTP応答に実行されて、応答変更メソッドは後工程の間、意図します。 例は特別なデバイスにおけるディスプレイのための形式HTML、人間の言語翻訳、ウイルスの照合などを含んでいます。

   Typical data flow:

典型的なデータは流れます:

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

発生源サーバ| /|\ | | 3 | | 2 | | \|/ | 4ICAP-クライアント-------------->ICAP-リソース(代理)<。-------------- ICAP-サーバに関して| /|\ 5 | | 6 | | 1 | | \|/ | クライアント

   1. A client makes a request to a ICAP-capable surrogate (ICAP client)
      for an object on an origin server.

1. クライアントはオブジェクトのために発生源サーバでICAP有能な代理(ICAPクライアント)に要求を出します。

   2. The surrogate sends the request to the origin server.

2. 代理は発生源サーバに要求を送ります。

   3. The origin server responds to request.

3. 発生源サーバは要求に応じます。

   4. The ICAP-capable surrogate sends the origin server's reply to the
      ICAP server.

4. ICAP有能な代理は発生源サーバの回答をICAPサーバに送ります。

   5. The ICAP server executes the ICAP resource's service on the origin
      server's reply and sends the possibly modified reply back to the
      ICAP client.

5. ICAPサーバは、発生源サーバの回答のときにICAPリソースのサービスを実行して、ことによると変更された回答をICAPクライアントに送り返します。

Elson & Cerpa                Informational                     [Page 10]

RFC 3507                          ICAP                        April 2003

[10ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   6. The surrogate sends the reply, possibly modified from the original
      origin server's reply, to the client.

6. 代理はことによるとオリジナルの発生源サーバの回答から変更された回答をクライアントに送ります。

4.  Protocol Semantics

4. プロトコル意味論

4.1  General Operation

4.1 一般操作

   ICAP is a request/response protocol similar in semantics and usage to
   HTTP/1.1 [4].  Despite the similarity, ICAP is not HTTP, nor is it an
   application protocol that runs over HTTP.  This means, for example,
   that ICAP messages can not be forwarded by HTTP surrogates.  Our
   reasons for not building directly on top of HTTP are discussed in
   Section 8.1.

ICAPは意味論と用法においてHTTP/1.1[4]と同様の要求/応答プロトコルです。 類似性にもかかわらず、ICAPはHTTPではありません、そして、HTTPをひくのは、アプリケーション・プロトコルではありません。 例えば、これは、HTTP代理がICAPメッセージを転送できないことを意味します。 セクション8.1で私たちの直接HTTPの上に建てない理由について議論します。

   ICAP uses TCP/IP as a transport protocol.  The default port is 1344,
   but other ports may be used.  The TCP flow is initiated by the ICAP
   client to a passively listening ICAP server.

ICAPはトランスポート・プロトコルとしてTCP/IPを使用します。 デフォルトポートは1344ですが、他のポートは使用されるかもしれません。 TCP流動はICAPクライアントによって受け身に聴いているICAPサーバに起こされます。

   ICAP messages consist of requests from client to server and responses
   from server to client.  Requests and responses use the generic
   message format of RFC 2822 [3] -- that is, a start-line (either a
   request line or a status line), a number of header fields (also known
   as "headers"), an empty line (i.e., a line with nothing preceding the
   CRLF) indicating the end of the header fields, and a message-body.

ICAPメッセージはクライアントからサーバまでの要求とサーバからクライアントまでの応答から成ります。 要求と応答はRFC2822[3]のジェネリックメッセージ・フォーマットを使用します--すなわち、スタート系列(要求系列か状況表示行のどちらか)、多くのヘッダーフィールド(また、「ヘッダー」として、知られている)、ヘッダーフィールドの終わりを示す空の系列(すなわち、何もCRLFに先行していない系列)、およびメッセージ本体。

   The header lines of an ICAP message specify the ICAP resource being
   requested as well as other meta-data such as cache control
   information. The message body of an ICAP request contains the
   (encapsulated) HTTP messages that are being modified.

ICAPメッセージのヘッダー系列はキャッシュ制御情報などの他のメタデータと同様に要求されているICAPリソースを指定します。 ICAP要求のメッセージ本体は変更されている(要約します)HTTPメッセージを含んでいます。

   As in HTTP/1.1, a single transport connection MAY (perhaps even
   SHOULD) be re-used for multiple request/response pairs.  The rules
   for doing so in ICAP are the same as described in Section 8.1.2.2 of
   [4].  Specifically, requests are matched up with responses by
   allowing only one outstanding request on a transport connection at a
   time.  Multiple parallel connections MAY be used as in HTTP.

HTTP/1.1のように、単独の輸送接続は複数の要求/応答に、再中古の組であるかもしれません(恐らくSHOULDさえ)。 ICAPでそうするための規則は[4]でセクション8.1.2で.2について説明するのと同じです。 明確に、要求は一度に輸送接続のときに1つの傑出している要求だけを許すことによって応答に上がった状態で取り組んでいます。 複数の並列接続がHTTPのように使用されているかもしれません。

4.2  ICAP URIs

4.2 ICAP URI

   All ICAP requests specify the ICAP resource being requested from the
   server using an ICAP URI.  This MUST be an absolute URI that
   specifies both the complete hostname and the path of the resource
   being requested.  For definitive information on URL syntax and
   semantics, see "Uniform Resource Identifiers (URI): Generic Syntax
   and Semantics," RFC 2396 [1], Section 3.  The URI structure defined
   by ICAP is roughly:

すべてのICAP要求がサーバからICAP URIを使用することで要求されるICAPリソースを指定します。 これは要求されている完全なホスト名とリソースの経路の両方を指定する絶対URIであるに違いありません。 URL構文と意味論の決定的な情報に関しては、見てください、「Uniform Resource Identifier(URI):」 「ジェネリック構文と意味論」(RFC2396[1])は3を区分します。 ICAPによって定義されたURI構造はおよそ以下の通りです。

Elson & Cerpa                Informational                     [Page 11]

RFC 3507                          ICAP                        April 2003

[11ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

      ICAP_URI = Scheme ":" Net_Path [ "?" Query ]

「ICAP_URI=体系」:、」 ネット_経路[“?"質問]

      Scheme = "icap"

体系="icap"

      Net_Path = "//" Authority [ Abs_Path ]

「ネット_経路は」 //と等しい」という権威[腹筋_経路]

      Authority = [ userinfo "@" ] host [ ":" port ]

権威=[userinfo"@"]ホスト[「:」 ポート]

   ICAP adds the new scheme "icap" to the ones defined in RFC 2396.  If
   the port is empty or not given, port 1344 is assumed.  An example
   ICAP URI line might look like this:

ICAPは新しい体系"icap"をRFC2396で定義されたものに加えます。 ポートが人影がないか考えないで、ポート1344は想定されます。 例のICAP URI系列はこれに似るかもしれません:

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

icap://icap.example.net: icap2000/サービス/サービス1

   An ICAP server MUST be able to recognize all of its hosts names,
   including any aliases, local variations, and numeric IP addresses of
   its interfaces.

ICAPサーバはホスト名のすべてを認識できなければなりません、インタフェースのどんな別名、地理的変異、および数値IPアドレスも含んでいて。

   Any arguments that an ICAP client wishes to pass to an ICAP service
   to modify the nature of the service MAY be passed as part of the
   ICAP-URI, using the standard "?"-encoding of attribute-value pairs
   used in HTTP. For example:

ICAPクライアントがサービスの本質を変更するためにICAPサービスに通りたがっているというどんな主張もICAP-URIの一部として通過されるかもしれません、HTTPに使用される属性値組の標準の“?"-コード化を使用して。 例えば:

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

icap://icap.net/サービス?モード=は翻訳されます、そして、langはフレンチと等しいです。

4.3  ICAP Headers

4.3 ICAPヘッダー

   The following sections define the valid headers for ICAP messages.
   Section 4.3.1 describes headers common to both requests and
   responses.  Request-specific and response-specific headers are
   described in Sections 4.3.2 and 4.3.3, respectively.

以下のセクションはICAPメッセージのために有効なヘッダーを定義します。 セクション4.3 .1 要求と応答の両方に共通のヘッダーについて説明します。 要求特有の、そして、応答特有のヘッダーはセクション4.3.2と4.3で説明されます。それぞれ.3。

   User-defined header extensions are allowed.  In compliance with the
   precedent established by the Internet mail format [3] and later
   adopted by HTTP [4], all user-defined headers MUST follow the "X-"
   naming convention ("X-Extension-Header: Foo").  ICAP implementations
   MAY ignore any "X-" headers without loss of compliance with the
   protocol as defined in this document.

ユーザによって定義されたヘッダー拡大は許されています。 インターネットメール書式[3]によって確立されて、後でHTTP[4]によって採用された先例に従って、(「X-拡張ヘッダー: Foo」)とコンベンションを命名して、すべてのユーザによって定義されたヘッダーが「X」の後をつけなければなりません。 ICAP実装は本書では定義されるようにプロトコルへの承諾の損失なしでどんな「X」ヘッダーも無視するかもしれません。

   Each header field consists of a name followed by a colon (":") and
   the field value.  Field names are case-insensitive.  ICAP follows the
   rules describe in section 4.2 of [4].

各ヘッダーフィールドがコロンがあとに続いた名前から成る、(「:」、)、そして、分野値。 フィールド名は大文字と小文字を区別しないです。 規則が[4]のセクション4.2で説明するICAP尾行。

4.3.1  Headers Common to Requests and Responses

4.3.1 要求と応答に共通のヘッダー

   The headers of all ICAP messages MAY include the following
   directives, defined in ICAP the same as they are in HTTP:

すべてのICAPメッセージのヘッダーはHTTPにはそれらがあるのと同じICAPで定義された以下の指示を入れるかもしれません:

Elson & Cerpa                Informational                     [Page 12]

RFC 3507                          ICAP                        April 2003

[12ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

      Cache-Control
      Connection
      Date
      Expires
      Pragma
      Trailer
      Upgrade

キャッシュ制御接続日付はPragmaトレーラアップグレードを吐き出します。

   Note in particular that the "Transfer-Encoding" option is not
   allowed.  The special transfer-encoding requirements of ICAP bodies
   are described in Section 4.4.

「転送をコード化している」オプションが許容されていないことに特に注意してください。 ICAPボディーの特別な転送をコード化する要件はセクション4.4で説明されます。

   The Upgrade header MAY be used to negotiate Transport-Layer Security
   on an ICAP connection, exactly as described for HTTP/1.1 in [4].

UpgradeヘッダーはICAP接続に関してTransport-層のSecurityを交渉するのに使用されるかもしれません、ちょうど[4]のHTTP/1.1のために説明されるように。

   The ICAP-specific headers defined are:

定義されたICAP特有のヘッダーは以下の通りです。

      Encapsulated  (See Section 4.4)

要約します。(セクション4.4を見ます)

4.3.2  Request Headers

4.3.2 ヘッダーを要求してください。

   Similar to HTTP, ICAP requests MUST start with a request line that
   contains a method, the complete URI of the ICAP resource being
   requested, and an ICAP version string.  The current version number of
   ICAP is "1.0".

HTTPと同様です、ICAP要求はメソッドを含む要求系列、要求されているICAPリソースの完全なURI、およびICAPバージョンストリングから始まらなければなりません。 ICAPの最新版番号は「1インチ」です。

   This version of ICAP defines three methods:

ICAPのこのバージョンは3つのメソッドを定義します:

      REQMOD  - for Request Modification (Section 4.8)
      RESPMOD - for Response Modification (Section 4.9)
      OPTIONS - to learn about configuration (Section 4.10)

REQMOD--Response Modification(セクション4.9)OPTIONSのためのRequest Modification(セクション4.8)RESPMODが構成に関して学ぶように(セクション4.10)

   The OPTIONS method MUST be implemented by all ICAP servers.  All
   other methods are optional and MAY be implemented.

すべてのICAPサーバでOPTIONSメソッドを実装しなければなりません。 他のすべてのメソッドが、任意であり、実装されるかもしれません。

   User-defined extension methods are allowed.  Before attempting to use
   an extension method, an ICAP client SHOULD use the OPTIONS method to
   query the ICAP server's list of supported methods; see Section 4.10.
   (If an ICAP server receives a request for an unknown method, it MUST
   give a 501 error response as described in the next section.)

ユーザによって定義された拡大メソッドは許容されています。 拡大メソッド、ICAPを使用するのを試みる前に、クライアントSHOULDはICAPサーバのサポートしているメソッドのリストについて質問するOPTIONSメソッドを使用します。 セクション4.10を見てください。 (ICAPサーバが未知のメソッドを求める要求を受け取るなら、それは次のセクションで説明されるように501誤り応答を与えなければなりません。)

   Given the URI rules described in Section 4.2, a well-formed ICAP
   request line looks like the following example:

セクション4.2で説明されたURI規則を考えて、整形式のICAP要求系列は以下の例に似ています:

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

RESPMOD icap://icap.example.net/は翻訳されます--モードはフレンチICAP/1.0と等しいです。

Elson & Cerpa                Informational                     [Page 13]

RFC 3507                          ICAP                        April 2003

[13ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   A number of request-specific headers are allowed in ICAP requests,
   following the same semantics as the corresponding HTTP request
   headers (Section 5.3 of [4]).  These are:

多くの要求特有のヘッダーがICAP要求に許容されています、対応するHTTP要求ヘッダーと同じ意味論に従って。([4])のセクション5.3。 これらは以下の通りです。

      Authorization
      Allow (see Section 4.6)
      From  (see Section 14.22 of [4])
      Host (REQUIRED in ICAP as it is in HTTP/1.1)
      Referer (see Section 14.36 of [4])
      User-Agent

承認Allow(セクション4.6を見る)、([4]) ホスト(HTTP/1.1にはそれとしてのICAPのREQUIREDがある)Refererのセクション14.22を見てください、([4]) ユーザエージェントのセクション14.36を見てください。

   In addition to HTTP-like headers, there are also request headers
   unique to ICAP defined:

また、HTTPのようなヘッダーに加えて、定義されたICAPにユニークな要求ヘッダーがあります:

      Preview (see Section 4.5)

プレビュー(セクション4.5を見ます)

4.3.3  Response Headers

4.3.3 応答ヘッダ

   ICAP responses MUST start with an ICAP status line, similar in form
   to that used by HTTP, including the ICAP version and a status code.
   For example:

ICAP応答はICAP状況表示行から始まらなければなりません、フォームにおいてHTTPによって使用されるそれと同様です、ICAPバージョンとステータスコードを含んでいて。 例えば:

      ICAP/1.0 200 OK

ICAP/1.0 200OK

   Semantics of ICAP status codes in ICAP match the status codes defined
   by HTTP (Section 6.1.1 and 10 of [4]), except where otherwise
   indicated in this document; n.b. 100 (Section 4.5) and 204 (Section
   4.6).

ICAPのICAPステータスコードの意味論はHTTPによって定義されたステータスコードに合っています。([4])について6.1に.1と10を区分して、本書では示されて、そうでないところで区分してください。 n. b。 100 (セクション4.5)と204(セクション4.6)。

   ICAP error codes that differ from their HTTP counterparts are:

彼らのHTTP対応者と異なっているICAPエラーコードは以下の通りです。

   100 - Continue after ICAP Preview (Section 4.5).

100--ICAPが(セクション4.5)を下見した後に続いてください。

   204 - No modifications needed (Section 4.6).

204--どんな変更も(セクション4.6)を必要としませんでした。

   400 - Bad request.

400--悪い要求。

   404 - ICAP Service not found.

404--見つけられなかったICAP Service。

   405 - Method not allowed for service (e.g., RESPMOD requested for
         service that supports only REQMOD).

405--メソッドはサービス(例えばREQMODだけをサポートするサービスのために要求されたRESPMOD)を考慮しませんでした。

   408 - Request timeout.  ICAP server gave up waiting for a request
         from an ICAP client.

408--タイムアウトを要求してください。 ICAPサーバは、ICAPクライアントからの要求を待つのをやめました。

   500 - Server error.  Error on the ICAP server, such as "out of disk
         space".

500--サーバ誤り。 ICAPサーバにおける「椎間腔」などの誤り。

Elson & Cerpa                Informational                     [Page 14]

RFC 3507                          ICAP                        April 2003

[14ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   501 - Method not implemented.  This response is illegal for an
         OPTIONS request since implementation of OPTIONS is mandatory.

501--実装されなかったメソッド。 OPTIONSの実装が義務的であるので、OPTIONS要求に、この応答は不法です。

   502 - Bad Gateway.  This is an ICAP proxy and proxying produced an
         error.

502--悪いゲートウェイ。 これはICAPプロキシです、そして、proxyingは誤りを起こしました。

   503 - Service overloaded.  The ICAP server has exceeded a maximum
         connection limit associated with this service; the ICAP client
         should not exceed this limit in the future.

503--積みすぎられたサービス。 ICAPサーバはこのサービスに関連している最大の接続限界を超えていました。 ICAPクライアントは将来、この限界を超えるべきではありません。

   505 - ICAP version not supported by server.

505--サーバによってサポートされなかったICAPバージョン。

   As in HTTP, the 4xx class of error codes indicate client errors, and
   the 5xx class indicate server errors.

HTTPでは、エラーコードの4xxのクラスがクライアント誤りを示して、5xxのクラスがサーバ誤りを示すので。

   ICAP's response-header fields allow the server to pass additional
   information in the response that cannot be placed in the ICAP's
   status line.

ICAPの応答ヘッダ分野で、サーバはICAPの状況表示行に置くことができない応答における追加情報を通過できます。

   A response-specific header is allowed in ICAP requests, following the
   same semantics as the corresponding HTTP response headers (Section
   6.2 of [4]).  This is:

応答特有のヘッダーはICAP要求に許容されています、対応するHTTP応答ヘッダと同じ意味論に従って。([4])のセクション6.2。 これは以下の通りです。

      Server (see Section 14.38 of [4])

サーバ([4])のセクション14.38を見てください。

   In addition to HTTP-like headers, there is also a response header
   unique to ICAP defined:

また、HTTPのようなヘッダーに加えて、定義されたICAPにユニークな応答ヘッダがいます:

      ISTag (see Section 4.7)

ISTag(セクション4.7を見ます)

4.3.4  ICAP-Related Headers in HTTP Messages

4.3.4 HTTPメッセージのICAP関連のヘッダー

   When an ICAP-enabled HTTP surrogate makes an HTTP request to an
   origin server, it is often useful to advise the origin server of the
   surrogate's ICAP capabilities.  Origin servers can use this
   information to modify its response accordingly.  For example, an
   origin server may choose not to insert an advertisement into a page
   if it knows that a downstream ICAP server can insert the ad instead.

ICAPによって可能にされたHTTP代理がHTTP要求を発生源サーバにするとき、代理のICAP能力を発生源サーバに知らせるのはしばしば役に立ちます。 発生源サーバは、それに従って、応答を変更するのにこの情報を使用できます。 例えば、発生源サーバは、川下のICAPサーバが代わりに広告を載せることができるのを知っているなら1ページに広告を載せないのを選ぶかもしれません。

   Although this ICAP specification can not mandate how HTTP is used in
   communication between HTTP clients and servers, we do suggest a
   convention: such headers (if used) SHOULD start with "X-ICAP".  HTTP
   clients with ICAP services SHOULD minimally include an "X-ICAP-
   Version: 1.0" header along with their application-specific headers.

このICAP仕様はHTTPがHTTPクライアントとサーバとのコミュニケーションでどう使用されるかを強制できませんが、私たちはコンベンションを勧めます: そのようなヘッダー(使用されるなら)SHOULDは"X-ICAP"から始めます。 ICAPサービスSHOULDをもっているHTTPクライアントが最少量で入れる、「X-ICAPバージョン:」 彼らのアプリケーション特有のヘッダーに伴う1インチのヘッダー。

Elson & Cerpa                Informational                     [Page 15]

RFC 3507                          ICAP                        April 2003

[15ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

4.4  ICAP Bodies: Encapsulation of HTTP Messages

4.4 ICAPボディー: HTTPメッセージのカプセル化

   The ICAP encapsulation model is a lightweight means of packaging any
   number of HTTP message sections into an encapsulating ICAP message-
   body, in order to allow the vectoring of requests, responses, and
   request/response pairs to an ICAP server.

ICAPカプセル化モデルは要約ICAPメッセージへのいろいろなHTTPメッセージ部が具体化させるパッケージの軽量の手段です、要求、応答、および要求/応答組のベクトル決定をICAPサーバに許容するために。

   This is accomplished by concatenating interesting message parts
   (encapsulatED sections) into a single ICAP message-body (the
   encapsulatING message).  The encapsulated sections may be the headers
   or bodies of HTTP messages.

これは、単一のICAPメッセージボディー(encapsulatINGメッセージ)におもしろいメッセージ部分(encapsulatED部)を連結することによって、達成されます。 カプセル化されたセクションは、HTTPメッセージのヘッダーかボディーであるかもしれません。

   Encapsulated bodies MUST be transferred using the "chunked"
   transfer-coding described in Section 3.6.1 of [4].  However,
   encapsulated headers MUST NOT be chunked.  In other words, an ICAP
   message-body switches from being non-chunked to chunked as the body
   passes from the encapsulated header to encapsulated body section.
   (See Examples in Sections 4.8.3 and 4.9.3.).  The motivation behind
   this decision is described in Section 8.2.

セクション3.6.1で説明された"chunkedする"の転送コード化を使用して、カプセル化されたボディーは[4]でわたっているに違いありません。 しかしながら、カプセル化されたヘッダーをchunkedしてはいけません。 言い換えれば、ICAPメッセージボディーはボディーがカプセル化されたヘッダーからカプセル化されたボディー部まで通りながらchunkedされるのに非chunkedされるのから切り替わります。 (.3にセクション4.8.3と4.9における例を見ます。) この決定の後ろの動機はセクション8.2で説明されます。

4.4.1  The "Encapsulated" Header

4.4.1 「カプセル化された」ヘッダー

   The offset of each encapsulated section's start relative to the start
   of the encapsulating message's body is noted using the "Encapsulated"
   header.  This header MUST be included in every ICAP message.  For
   example, the header

「カプセル化された」ヘッダーを使用することで要約メッセージのボディーの始まりに比例したそれぞれのカプセル化されたセクションの始めのオフセットは注意されます。 あらゆるICAPメッセージにこのヘッダーを含まなければなりません。 例えば、ヘッダー

      Encapsulated: req-hdr=0, res-hdr=45, res-body=100

カプセル化される: req-hdr=0、res-hdr=45、res-ボディー=100

   indicates a message that encapsulates a group of request headers, a
   group of response headers, and then a response body.  Each of these
   is included at the byte-offsets listed.  The byte-offsets are in
   decimal notation for consistency with HTTP's Content-Length header.

要求ヘッダー、応答ヘッダのグループ、および次に、応答本体のグループをカプセル化するメッセージを示します。 それぞれのこれらは記載されたバイトオフセットのときに含まれています。 バイトオフセットがHTTPのContent-長さのヘッダーと共に一貫性のための10進法であります。

   The special entity "null-body" indicates there is no encapsulated
   body in the ICAP message.

特別な実体「ヌルボディー」は、ICAPメッセージにはカプセル化されたボディーが全くないのを示します。

   The syntax of an Encapsulated header is:

Encapsulatedヘッダーの構文は以下の通りです。

   encapsulated_header: "Encapsulated: " encapsulated_list
   encapsulated_list: encapsulated_entity |
                      encapsulated_entity ", " encapsulated_list
   encapsulated_entity: reqhdr | reshdr | reqbody | resbody | optbody
   reqhdr  = "req-hdr" "=" (decimal integer)
   reshdr  = "res-hdr" "=" (decimal integer)
   reqbody = { "req-body" | "null-body" } "=" (decimal integer)
   resbody = { "res-body" | "null-body" } "=" (decimal integer)
   optbody = { "opt-body" | "null-body" } "=" (decimal integer)

カプセル化された_ヘッダー: 「カプセル化されました」 「カプセル化された_リストは、_がリストであるとカプセル化しました」 _実体であるとカプセル化されます。| 「_実体であるとカプセル化され」て、「カプセル化された_リストは、_が実体であるとカプセル化しました」。 reqhdr| reshdr| reqbody| resbody| 「req-ボディー」| "res-hdr"「=」(10進整数)"req-hdr"「=」(10進整数)optbody reqhdr=reshdr=reqbody=「ヌルボディー」「=」(10進整数)resbodyが「res-ボディー」| 「ヌルボディー」「=」(10進整数)optbody=と等しい、「」 | ボディーを選んでいる「ヌルボディー」、「=」(10進整数)

Elson & Cerpa                Informational                     [Page 16]

RFC 3507                          ICAP                        April 2003

[16ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   There are semantic restrictions on Encapsulated headers beyond the
   syntactic restrictions.  The order in which the encapsulated parts
   appear in the encapsulating message-body MUST be the same as the
   order in which the parts are named in the Encapsulated header.  In
   other words, the offsets listed in the Encapsulated line MUST be
   monotonically increasing.  In addition, the legal forms of the
   Encapsulated header depend on the method being used (REQMOD, RESPMOD,
   or OPTIONS).  Specifically:

意味制限はEncapsulatedヘッダーの上に構文の制限を超えています。 カプセル化された部品が要約メッセージ本体に現れるオーダーは部品がEncapsulatedヘッダーで命名されるオーダーと同じであるに違いありません。 言い換えれば、Encapsulated系列で記載されたオフセットは単調に増加しなければなりません。 さらに、Encapsulatedヘッダーの法令諸様式は使用されるメソッド(REQMOD、RESPMOD、またはOPTIONS)に依存します。 明確に:

   REQMOD  request  encapsulated_list: [reqhdr] reqbody
   REQMOD  response encapsulated_list: {[reqhdr] reqbody} |
                                       {[reshdr] resbody}
   RESPMOD request  encapsulated_list: [reqhdr] [reshdr] resbody
   RESPMOD response encapsulated_list: [reshdr] resbody
   OPTIONS response encapsulated_list: optbody

REQMODはカプセル化された_リストを要求します: [reqhdr]reqbody REQMOD応答は、_がリストであるとカプセル化しました: [reqhdr]reqbody| RESPMODが要求する[reshdr]resbodyは、_がリストであるとカプセル化しました: [reqhdr][reshdr]resbody RESPMOD応答は、_がリストであるとカプセル化しました: [reshdr]resbody OPTIONS応答は、_がリストであるとカプセル化しました: optbody

   In the above grammar, note that encapsulated headers are always
   optional.  At most one body per encapsulated message is allowed.  If
   no encapsulated body is presented, the "null-body" header is used
   instead; this is useful because it indicates the length of the header
   section.

上の文法で、カプセル化されたヘッダーがいつも任意であることに注意してください。 高々、カプセル化されたメッセージあたり1つのボディーが許容されています。 カプセル化されたボディーが全く提示されないなら、「ヌルボディー」ヘッダーは代わりに使用されます。 ヘッダー部分の長さを示すので、これは役に立ちます。

   Examples of legal Encapsulated headers:

法的なEncapsulatedヘッダーに関する例:

   /* REQMOD request: This encapsulated HTTP request's headers start
    * at offset 0; the HTTP request body (e.g., in a POST) starts
    * at 412. */
   Encapsulated: req-hdr=0, req-body=412

/*REQMODは以下を要求します。 このカプセル化されたHTTP要求のヘッダーはオフセット0時に*を始めます。 HTTP要求本体(例えば、ポストにおける)は412で*を始めます。 */は要約されました: req-hdr=0、req-ボディー=412

   /* REQMOD request: Similar to the above, but no request body is
    * present (e.g., a GET).  We use the null-body directive instead.
    * In both this case and the previous one, we can tell from the
    * Encapsulated header that the request headers were 412 bytes
    * long. */
   Encapsulated: req-hdr=0, null-body=412

/*REQMODは以下を要求します。 上にもかかわらず、いいえ、要求本体と同様であるのは、*プレゼント(例えば、GET)です。 私たちは代わりにヌルボディー指示を使用します。 * 本件と前のものの両方では、私たちは、ヘッダーであるとカプセル化された*から要求ヘッダーが*長い間412バイトであったと言うことができます。 */は要約されました: req-hdr=0、ヌルボディーの=412

   /* REQMOD response: ICAP server returned a modified request,
    * with body */
   Encapsulated: req-hdr=0, req-body=512

/*REQMOD応答: ICAPサーバはボディー*/カプセル化されると共に変更された要求、*を返しました: req-hdr=0、req-ボディー=512

   /* RESPMOD request: Request headers at 0, response headers at 822,
    * response body at 1655.  Note that no request body is allowed in
    * RESPMOD requests. */
   Encapsulated: req-hdr=0, res-hdr=822, res-body=1655

/*RESPMODは以下を要求します。 822、1655年の*応答本体で0時のヘッダー、応答ヘッダを要求してください。 要求本体が全く*RESPMOD要求に許容されていないことに注意してください。 */は要約されました: req-hdr=0、res-hdr=822、res-ボディー=1655

   /* RESPMOD or REQMOD response: header and body returned */
   Encapsulated: res-hdr=0, res-body=749

/*RESPMODかREQMOD応答: ヘッダーとボディーは*/カプセル化された状態で戻りました: res-hdr=0、res-ボディー=749

Elson & Cerpa                Informational                     [Page 17]

RFC 3507                          ICAP                        April 2003

[17ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   /* OPTIONS response when there IS an options body */
   Encapsulated: opt-body=0

オプションボディー*/があるとき、/*OPTIONS応答は要約されました: ボディー=を選んでいる0

   /* OPTIONS response when there IS NOT an options body */
   Encapsulated: null-body=0

オプションボディー*/がないとき、/*OPTIONS応答は要約されました: ヌルボディーの=0

4.4.2  Encapsulated HTTP Headers

4.4.2 カプセル化されたHTTPヘッダ

   By default, ICAP messages may encapsulate HTTP message headers and
   entity bodies.  HTTP headers MUST start with the request-line or
   status-line for requests and responses, respectively, followed by
   interesting HTTP headers.

デフォルトで、ICAPメッセージは、HTTPがメッセージヘッダーと実体本体であるとカプセル化するかもしれません。 HTTPヘッダはおもしろいHTTPヘッダがそれぞれあとに続いた要求と応答のために要求系列か状況表示行から始まらなければなりません。

   The encapsulated headers MUST be terminated by a blank line, in order
   to make them human readable, and in order to terminate line-by-line
   HTTP parsers.

空白行でカプセル化されたヘッダーを終えなければなりません、彼らを人間読み込み可能にして、1行ずつのHTTPパーサを終えるために。

   HTTP/1.1 makes a distinction between end-to-end headers and hop-by-
   hop headers (see Section 13.5.1 of [4]).  End-to-end headers are
   meaningful to the ultimate recipient of a message, whereas hop-by-hop
   headers are meaningful only for a single transport-layer connection.
   Hop-by-hop headers include Connection, Keep-Alive, and so forth.  All
   end-to-end HTTP headers SHOULD be encapsulated, and all hop-by-hop
   headers MUST NOT be encapsulated.

HTTP/1.1は、終わりから終わりへのヘッダーの区別にaを作って、近く跳びホップをヘッダーに作ります。([4])についてセクション13.5.1を見てください。 メッセージの究極の受取人にとって、終わりから終わりへのヘッダーは重要ですが、単独のトランスポート層接続だけに、ホップごとのヘッダーは重要です。 ホップごとのヘッダーはConnection、生きているKeepなどを入れます。 すべての終わらせる終わりのHTTPヘッダSHOULDがカプセル化されて、ホップですべて跳びます。ヘッダーはカプセルに入れられてはいけません。

   Despite the above restrictions on encapsulation, the hop-by-hop
   Proxy-Authenticate and Proxy-Authorization headers MUST be forwarded
   to the ICAP server in the ICAP header section (not the encapsulated
   message).  This allows propagation of client credentials that might
   have been sent to the ICAP client in cases where the ICAP client is
   also an HTTP surrogate.  Note that this does not contradict HTTP/1.1,
   which explicitly states "A proxy MAY relay the credentials from the
   client request to the next proxy if that is the mechanism by which
   the proxies cooperatively authenticate a given request."  (Section
   14.34).

カプセル化における上の制限、ホップごとにProxy認証して、ICAPヘッダー部分(カプセル化されたメッセージでない)のICAPサーバにProxy-承認ヘッダーを送らなければなりません。 これはまたICAPクライアントがそうである場合におけるICAPクライアントに送られたかもしれないクライアント資格証明書の伝播にHTTP代理を許容します。 これがHTTP/1.1に矛盾しないことに注意してください。(明らかに、1.1は「プロキシはそれがプロキシが協力して与えられた要求を認証するメカニズムであるならクライアント要求から次期プロキシまで資格証明書をリレーするかもしれません。」と述べます)。 (セクション14.34。)

   The Via header of an encapsulated message SHOULD be modified by an
   ICAP server as if the encapsulated message were traveling through an
   HTTP surrogate.  The Via header added by an ICAP server MUST specify
   protocol as ICAP/1.0.

変更されていて、ICAPサーバがまるでカプセル化することが通信するようであったというHTTP代理を通って旅行するカプセル化されたメッセージSHOULDのViaヘッダー。 ICAPサーバによって加えられたViaヘッダーはICAP/1.0としてプロトコルを指定しなければなりません。

4.5  Message Preview

4.5 メッセージプレビュー

   ICAP REQMOD or RESPMOD requests sent by the ICAP client to the ICAP
   server may include a "preview".  This feature allows an ICAP server
   to see the beginning of a transaction, then decide if it wants to

ICAPクライアントによってICAPサーバに送られたICAP REQMODかRESPMOD要求が「プレビュー」を含むかもしれません。 この特徴で、ICAPサーバをトランザクションの始まりを見て、次に、それがそうしたがっているかどうか決めます。

Elson & Cerpa                Informational                     [Page 18]

RFC 3507                          ICAP                        April 2003

[18ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   opt-out of the transaction early instead of receiving the remainder
   of the request message.  Previewing can yield significant performance
   improvements in a variety of situations, such as the following:

要求メッセージの残りを受け取ることの代わりに早くトランザクションから手を引いてください。 下見は以下などのさまざまな状況における顕著な性能改良をもたらすことができます:

   -  Virus-checkers can certify a large fraction of files as "clean"
      just by looking at the file type, file name extension, and the
      first few bytes of the file.  Only the remaining files need to be
      transmitted to the virus-checking ICAP server in their entirety.

- ウイルスチェックソフトは、まさしくファイルのファイルがタイプされるのを見る、ファイル名の拡張子、および最初の数バイトでファイルの大きい部分が「清潔である」と認証できます。 残っているファイルだけが、ウイルスをチェックするICAPサーバに全体として伝えられる必要があります。

   -  Content filters can use Preview to decide if an HTTP entity needs
      to be inspected (the HTTP file type alone is not enough in cases
      where "text" actually turns out to be graphics data).  The magic
      numbers at the front of the file can identify a file as a JPEG or
      GIF.

- 満足しているフィルタは、HTTP実体が、点検される必要であるかどうか(HTTPファイルの種類だけが「テキスト」が実際にグラフィックスデータであると判明する場合に十分ではありません)決めるのにPreviewを使用できます。 ファイルの前部におけるマジックナンバーは、ファイルがJPEGかGIFであると認識できます。

   -  If an ICAP server wants to transcode all GIF87 files into GIF89
      files, then the GIF87 files could quickly be detected by looking
      at the first few body bytes of the file.

- ICAPサーバがGIF89ファイルの中へのすべてのGIF87ファイルを「移-コード」に必要とするなら、GIF87ファイルは、ファイルの最初のボディー数バイトを見ることによって、すぐに検出されるかもしれません。

   -  If an ICAP server wants to force all cacheable files to expire in
      24 hours or less, then this could be implemented by selecting HTTP
      messages with expiries more than 24 hours in the future.

- ICAPサーバが、すべての「キャッシュ-可能」ファイルを24時間以下後に期限が切れさせる必要があるなら、これは、将来、24時間以上expiriesでHTTPメッセージを選択することによって、実装されるかもしれません。

   ICAP servers SHOULD use the OPTIONS method (see Section 4.10) to
   specify how many bytes of preview are needed for a particular ICAP
   application on a per-resource basis.  Clients SHOULD be able to
   provide Previews of at least 4096 bytes.  Clients furthermore SHOULD
   provide a Preview when using any ICAP resource that has indicated a
   Preview is useful.  (This indication might be provided via the
   OPTIONS method, or some other "out-of-band" configuration.)  Clients
   SHOULD NOT provide a larger Preview than a server has indicated it is
   willing to accept.

ICAPサーバSHOULDはいくつのバイトのプレビューが1リソースあたり1個のベースで特定のICAPアプリケーションに必要であるかを指定するOPTIONSメソッド(セクション4.10を見る)を使用します。 クライアントSHOULD、少なくとも4096バイトのPreviewsを提供できてください。 クライアント、Previewが役に立つのを示したどんなICAPリソースも使用するとき、その上、SHOULDはPreviewを提供します。 (OPTIONSメソッド、または「バンドの外」というある他の構成でこの指示を提供するかもしれません。) クライアントSHOULD NOTはサーバが、受け入れても構わないと思っているのを示したより大きいPreviewを提供します。

   To effect a Preview, an ICAP client MUST add a "Preview:" header to
   its request headers indicating the length of the preview.  The ICAP
   client then sends:

Previewに作用するように、ICAPクライアントは、aが「以下を下見する」と言い足さなければなりません。 プレビューの長さを示す要求ヘッダーへのヘッダー。 次に、ICAPクライアントは発信します:

   -  all of the encapsulated header sections, and

- そしてカプセル化されたヘッダー部分のすべて。

   -  the beginning of the encapsulated body section, if any, up to the
      number of bytes advertised in the Preview (possibly 0).

- もしあればPreview(ことによると0)の広告に掲載されたバイト数までのカプセル化されたボディー部の始まり。

   After the Preview is sent, the client stops and waits for an
   intermediate response from the ICAP server before continuing.  This
   mechanism is similar to the "100-Continue" feature found in HTTP,
   except that the stop-and-wait point can be within the message body.
   In contrast, HTTP requires that the point must be the boundary
   between the headers and body.

Previewを送った後に、クライアントは、続く前に、ICAPサーバから中間的応答を止めて、待ちます。 このメカニズムが同様である、「100、-続いてください、」 特徴によって、それを除いたHTTPでメッセージ本体の中に停止と待ちポイントがあることができるのがわかりました。 対照的に、HTTPは、ポイントがヘッダーとボディーの間の境界であるに違いないことを必要とします。

Elson & Cerpa                Informational                     [Page 19]

RFC 3507                          ICAP                        April 2003

[19ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   For example, to effect a Preview consisting of only encapsulated HTTP
   headers, the ICAP client would add the following header to the ICAP
   request:

例えば、カプセル化されたHTTPヘッダだけから成るPreviewに作用するように、ICAPクライアントは以下のヘッダーをICAP要求に追加するでしょう:

      Preview: 0

以下を下見してください。 0

   This indicates that the ICAP client will send only the encapsulated
   header sections to the ICAP server, then it will send a zero-length
   chunk and stop and wait for a "go ahead" to send more encapsulated
   body bytes to the ICAP server.

これが、ICAPクライアントがカプセル化されたヘッダー部分だけをICAPサーバに送るのを示して、次に、それは、ゼロ・レングス塊を送って、止まって、「前方に行ってください」がICAPサーバにより多くのカプセル化されたボディーバイト発信するのを待つでしょう。

   Similarly, the ICAP header:

同様である、ICAPヘッダー:

      Preview: 4096

以下を下見してください。 4096

   Indicates that the ICAP client will attempt to send 4096 bytes of
   origin server data in the encapsulated body of the ICAP request to
   the ICAP server.  It is important to note that the actual transfer
   may be less, because the ICAP client is acting like a surrogate and
   is not looking ahead to find the total length of the origin server
   response.  The entire ICAP encapsulated header section(s) will be
   sent, followed by up to 4096 bytes of encapsulated HTTP body.  The
   chunk body terminator "0\r\n\r\n" is always included in these
   transactions.

ICAPクライアントは、ICAP要求のカプセル化されたボディーで4096バイトの発生源サーバデータをICAPサーバに送るのを試みるでしょう。ICAPクライアントが代理のように行動していて、発生源サーバ応答の全長を見つけるために前を見ていないので、実際の転送が、より少ないかもしれないことに注意するのが重要であることを示します。 最大4096バイトのカプセル化されたHTTP本体があとに続いていて、ヘッダー部分であるとカプセル化された全体のICAPを送るでしょう。 塊ボディーターミネータ「0円r\n円r\n」はいつもこれらの取引において含まれています。

   After sending the preview, the ICAP client will wait for a response
   from the ICAP server.  The response MUST be one of the following:

プレビューを送った後に、ICAPクライアントはICAPサーバから応答を待っています。応答は以下の1つであるに違いありません:

   -  204 No Content.  The ICAP server does not want to (or can not)
      modify the ICAP client's request.  The ICAP client MUST treat this
      the same as if it had sent the entire message to the ICAP server
      and an identical message was returned.

- 204 内容がありません。 または、ICAPサーバがそうしたがっていない、()、ICAPクライアントの要求を変更できてください。 まるで全体のメッセージをICAPサーバに送ったかのようにICAPクライアントはこの同じくらいを扱わなければなりません、そして、同じメッセージを返しました。

   -  ICAP reqmod or respmod response, depending what method was the
      original request.  See Section 4.8.2 and 4.9.2 for the format of
      reqmod and respmod responses.

- どんなメソッドがオリジナルの要求であったかによるICAP reqmodかrespmod応答。 セクション4.8.2と4.9を見てください。.2 reqmodとrespmod応答の形式のために。

   -  100 Continue.  If the entire encapsulated HTTP body did not fit
      in the preview, the ICAP client MUST send the remainder of its
      ICAP message, starting from the first chunk after the preview.  If
      the entire message fit in the preview (detected by the "EOF"
      symbol explained below), then the ICAP server MUST NOT respond
      with 100 Continue.

- 100は続きます。 全体のカプセル化されたHTTP本体がプレビューをうまくはめ込まなかったなら、ICAPクライアントはICAPメッセージの残りを送らなければなりません、プレビューの後に最初の塊から始めて。 全体のメッセージがプレビュー(以下で説明された"EOF"シンボルで、検出される)をうまくはめ込んだなら、サーバが100で反応させてはいけないICAPは続きます。

   When an ICAP client is performing a preview, it may not yet know how
   many bytes will ultimately be available in the arriving HTTP message
   that it is relaying to the HTTP server.  Therefore, ICAP defines a
   way for ICAP clients to indicate "EOF" to ICAP servers if one

ICAPクライアントがプレビューを実行しているとき、それは、いくつのバイトが結局それがHTTPサーバにリレーしている到着しているHTTPメッセージで有効になるかをまだ知っていないかもしれません。したがって、ICAPは1であるならICAPクライアントが"EOF"をICAPサーバに示す方法を定義します。

Elson & Cerpa                Informational                     [Page 20]

RFC 3507                          ICAP                        April 2003

[20ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   unexpectedly arrives during the preview process.  This is a
   particularly useful optimization if a header-only HTTP response
   arrives at the ICAP client (i.e., zero bytes of body); only a single
   round trip will be needed for the complete ICAP server response.

不意に、プレビュープロセスの間、到着します。 ヘッダーだけHTTP応答がICAPクライアントに到着するなら(すなわち、バイトのボディーのゼロを合わせてください)、これは特に役に立つ最適化です。 単発旅行だけが完全なICAPサーバ応答に必要でしょう。

   We define an HTTP chunk-extension of "ieof" to indicate that an ICAP
   chunk is the last chunk (see [4]).  The ICAP server MUST strip this
   chunk extension before passing the chunk data to an ICAP application
   process.

私たちはICAP塊が最後の塊であることを示す"ieof"のHTTP塊拡大を定義します。([4])を見てください。 塊データをICAPアプリケーション・プロセスに通過する前に、ICAPサーバはこの塊拡大を剥取らなければなりません。

   For example, consider an ICAP client that has just received HTTP
   response headers from an origin server and initiates an ICAP RESPMOD
   transaction to an ICAP server.  It does not know yet how many body
   bytes will be arriving from the origin server because the server is
   not using the Content-Length header.  The ICAP client informs the
   ICAP server that it will be sending a 1024-byte preview using a
   "Preview:  1024" request header.  If the HTTP origin server then
   closes its connection to the ICAP client before sending any data
   (i.e., it provides a zero-byte body), the corresponding zero-byte
   preview for that zero-byte origin response would appear as follows:

例えば、発生源サーバからHTTP応答ヘッダをちょうど受け取って、ICAPサーバにICAP RESPMODトランザクションを開始するICAPクライアントを考えてください。それは、サーバがContent-長さのヘッダーを使用していないのでいくつのボディーバイトが発生源サーバから到着するかをまだ知っていません。 ICAPクライアントは、「以下を下見してください」というaを使用することで1024年のバイトのプレビューを送って、ことであることをICAPサーバに知らせます。 「1024」はヘッダーを要求します。 次に、どんなデータも送る前にHTTP発生源サーバがICAPクライアントに接続を終えるなら(すなわち、それは無バイト本体を提供します)、その無バイト発生源応答のための対応する無バイトプレビューは以下の通りに見えるでしょう:

      \r\n
      0; ieof\r\n\r\n

\、r n0円。 ieof\r\n円r\n

   If an ICAP server sees this preview, it knows from the presence of
   "ieof" that the client will not be sending any more chunk data.  In
   this case, the server MUST respond with the modified response or a
   204 No Content message right away.  It MUST NOT send a 100-Continue
   response in this case.  (In contrast, if the origin response had been
   1 byte or larger, the "ieof" would not have appeared.  In that case,
   an ICAP server MAY reply with 100-Continue, a modified response, or
   204 No Content.)

ICAPサーバがこのプレビューを見るなら、それは、"ieof"の存在からクライアントがそれ以上の塊データを送らないのを知っています。 この場合、サーバはすぐ、変更された応答か204いいえContentメッセージで反応しなければなりません。 aを送ってはいけない、100、-続いてください、この場合、応答。 (対照的に、発生源応答が1バイト以上であったなら、"ieof"は現れなかったでしょうに。 その場合、ICAPサーバが返答するかもしれない、100、-続いてください、変更された応答、または204ノーContent。)

   In another example, if the preview is 1024 bytes and the origin
   response is 1024 bytes in two chunks, then the encapsulation would
   appear as follows:

別の例では、カプセル化はプレビューが1024バイトであり、発生源応答が2つの塊で1024バイトであるなら以下の通りに見えるでしょう:

      200\r\n
      <512 bytes of data>\r\n
      200\r\n
      <512 bytes of data>\r\n
      0; ieof\r\n\r\n

データ>\r n200円の\r\n<の200\r円nの<512バイト、512バイトのデータ>\r\n、0。 ieof\r\n円r\n

      <204 or modified response> (100 Continue disallowed due to ieof)

<204か変更された応答>。(100は禁じられた支払われるべきものをieofに続けています)

   If the preview is 1024 bytes and the origin response is 1025 bytes
   (and the ICAP server responds with 100-continue), then these chunks
   would appear on the wire:

そして、プレビューが1024バイトであり、発生源応答が1025バイトである、(ICAPサーバが応じる、100、-続いてください、)、次に、これらの塊はワイヤの上に現れるでしょう:

Elson & Cerpa                Informational                     [Page 21]

RFC 3507                          ICAP                        April 2003

[21ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

      200\r\n
      <512 bytes of data>\r\n
      200\r\n
      <512 bytes of data>\r\n
      0\r\n

データ>\r n200円の\r\n<の200\r円nの<512バイト、512バイトのデータ>\r n0円\r\、n

      <100 Continue Message>

<100はメッセージ>を続けています。

      1\r\n
      <1 byte of data>\r\n
      0\r\n\r\n  <no ieof because we are no longer in preview mode>

私たちがもう少しも中にいないので、1円rの\n<、1バイトのデータ>\r n0円の\r\n\r\n<ノーieofはモード>を下見します。

   Once the ICAP server receives the eof indicator, it finishes reading
   the current chunk stream.

ICAPサーバがいったんeofインディケータを受けると、それは、現在の塊ストリームを読み終えます。

   Note that when offering a Preview, the ICAP client is committing to
   temporarily buffer the previewed portion of the message so that it
   can honor a "204 No Content" response.  The remainder of the message
   is not necessarily buffered; it might be pipelined directly from
   another source to the ICAP server after a 100-Continue.

Previewを提供するとき、ICAPクライアントが「204いいえ内容」応答を光栄に思うことができるように一時メッセージの下見された部分をバッファリングするように公約していることに注意してください。 メッセージの残りは必ずバッファリングされるというわけではありません。 それが直接別のソースからICAPサーバまで後aであることでpipelinedされるかもしれない、100、-続いてください。

4.6  "204 No Content" Responses outside of Previews

4.6 Previewsの外の「204いいえ内容」Responses

   An ICAP client MAY choose to honor "204 No Content" responses for an
   entire message.  This is the decision of the client because it
   imposes a burden on the client of buffering the entire message.

ICAPクライアントは、全体のメッセージのための「204いいえ内容」応答を光栄に思うのを選ぶかもしれません。 全体のメッセージをバッファリングするクライアントの上で負担をかけるので、これはクライアントの決定です。

   An ICAP client MAY include "Allow: 204" in its request headers,
   indicating that the server MAY reply to the message with a "204 No
   Content" response if the object does not need modification.

ICAPクライアントは「以下を許容してください」を入れるかもしれません。 「204」 要求ヘッダーでは、サーバがオブジェクトであるなら「204いいえ内容」応答でメッセージに答えるかもしれないのを示すのが変更を必要としません。

   If an ICAP server receives a request that does not have "Allow: 204",
   it MUST NOT reply with a 204.  In this case, an ICAP server MUST
   return the entire message back to the client, even though it is
   identical to the message it received.

ICAPサーバが要求を受け取るなら、それには、「以下を許容してください」がありません。 「204」 それは204で返答してはいけません。 この場合、ICAPサーバは全体のメッセージをクライアントに返して戻さなければなりません、それが受け取ったメッセージと同じですが。

   The ONLY EXCEPTION to this rule is in the case of a message preview,
   as described in the previous section.  If this is the case, an ICAP
   server can respond with a 204 No Content message in response to a
   message preview EVEN if the original request did not have the "Allow:
   204" header.

メッセージプレビューの場合にはこの規則へのONLY EXCEPTIONが前項で説明されるようにあります。 これがそうであり、オリジナルの要求に「以下を許容してください」がなかったなら、ICAPサーバは204いいえContentメッセージでメッセージプレビューEVENに対応して反応できます。 「204」ヘッダー。

4.7  ISTag Response Header

4.7 ISTag応答ヘッダ

   The ISTag ("ICAP Service Tag") response-header field provides a way
   for ICAP servers to send a service-specific "cookie" to ICAP clients
   that represents a service's current state.  It is a 32-byte-maximum
   alphanumeric string of data (not including the null character) that

ISTag(「ICAPサービスタグ」)応答ヘッダ分野はICAPサーバがICAPクライアントへのサービスの現状を表すサービス特有の「クッキー」を送る方法を提供します。 それが32バイトの最大の英数字の一連のデータ(ヌル文字を含んでいなくて)である、それ

Elson & Cerpa                Informational                     [Page 22]

RFC 3507                          ICAP                        April 2003

[22ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   may, for example, be a representation of the software version or
   configuration of a service.  An ISTag validates that previous ICAP
   server responses can still be considered fresh by an ICAP client that
   may be caching them.  If a change on the ICAP server invalidates
   previous responses, the ICAP server can invalidate portions of the
   ICAP client's cache by changing its ISTag.  The ISTag MUST be
   included in every ICAP response from an ICAP server.

例えば、サービスのソフトウェアバージョンか構成の表現であるかもしれません。 それらをキャッシュしているかもしれないICAPクライアントで新鮮な状態で考えられて、ISTagはまだその前のICAPサーバ応答缶を有効にしています。 ICAPサーバの変化が前の応答を無効にするなら、ICAPサーバは、ISTagを変えることによって、ICAPクライアントのキャッシュの部分を無効にすることができます。 あらゆるICAP応答にICAPサーバからISTagを含まなければなりません。

   For example, consider a virus-scanning ICAP service.  The ISTag might
   be a combination of the virus scanner's software version and the
   release number of its virus signature database.  When the database is
   updated, the ISTag can be changed to invalidate all previous
   responses that had been certified as "clean" and cached with the old
   ISTag.

例えば、ウイルスをスキャンするICAPがサービスであると考えてください。 ISTagはウイルス・スキャナーのソフトウェアバージョンの組み合わせとウイルス署名データベースのリリース番号であるかもしれません。 データベースをアップデートするとき、「清潔であること」が公認されて、古いISTagと共にキャッシュされた前のすべての応答を無効にするためにISTagを変えることができます。

   ISTag is similar, but not identical, to the HTTP ETag.  While an ETag
   is a validator for a particular entity (object), an ISTag validates
   all entities generated by a particular service (URI).  A change in
   the ISTag invalidates all the other entities provided a service with
   the old ISTag, not just the entity whose response contained the
   updated ISTag.

ISTagは同様ですが、HTTP ETagと同じではありません。 ETagは特定の実体(オブジェクト)のためのvalidatorですが、ISTagは特定のサービス(URI)で生成されたすべての実体を有効にします。 ISTagにおける変化は応答がアップデートされたISTagを含んだ実体だけではなく、他の実体が古いISTagとのサービスを提供したすべてを無効にします。

   The syntax of an ISTag is simply:
      ISTag = "ISTag: " quoted-string

ISTagの構文は単に以下の通りです。 ISTagが等しい、「ISTag:」 「引用文字列」

   In this document we use the quoted-string definition defined in
   section 2.2 of [4].

本書では私たちは[4]のセクション2.2で定義された引用文字列定義を使用します。

   For example:
      ISTag: "874900-1994-1c02798"

例えば: ISTag: 「874900-1994-1 c02798」

4.8  Request Modification Mode

4.8 要求変更モード

   In this method, described in Section 3.1, an ICAP client sends an
   HTTP request to an ICAP server.  The ICAP server returns a modified
   version of the request, an HTTP response, or (if the client indicates
   it supports 204 responses) an indication that no modification is
   required.

セクション3.1で説明されたこのメソッドで、ICAPクライアントはHTTP要求をICAPサーバに送ります。ICAPサーバは要求の変更されたバージョン、HTTP応答、または変更が全く必要でないという(クライアントが、204の応答をサポートするのを示すなら)指示を返します。

4.8.1  Request

4.8.1 要求

   In REQMOD mode, the ICAP request MUST contain an encapsulated HTTP
   request.  The headers and body (if any) MUST both be encapsulated,
   except that hop-by-hop headers are not encapsulated.

REQMODモードで、ICAP要求はカプセル化されたHTTP要求を含まなければなりません。 ホップごとのヘッダーがカプセルに入れられないのを除いて、ともに、ヘッダーとボディー(もしあれば)をカプセルに入れらなければなりません。

Elson & Cerpa                Informational                     [Page 23]

RFC 3507                          ICAP                        April 2003

[23ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

4.8.2  Response

4.8.2 応答

   The response from the ICAP server back to the ICAP client may take
   one of four forms:

ICAPサーバからICAPクライアントまでの応答は4つのフォームの1つを取るかもしれません:

   -  An error indication,

- 誤り表示

   -  A 204 indicating that the ICAP client's request requires no
      adaptation (see Section 4.6 for limitations of this response),

- ICAPクライアントの要求が適合(この応答の制限に関してセクション4.6を見る)を全く必要としないのを示す204

   -  An encapsulated, adapted version of the ICAP client's request, or

- またはICAPクライアントの要求のカプセル化されて、適合しているバージョン。

   -  An encapsulated HTTP error response.  Note that Request
      Modification requests may only be satisfied with HTTP responses in
      cases when the HTTP response is an error (e.g., 403 Forbidden).

- カプセル化されたHTTP誤り応答。 HTTP応答が誤り(例えば、403Forbidden)であるときにだけ、Request Modification要求が場合におけるHTTP応答に満たされるかもしれないことに注意してください。

   The first line of the response message MUST be a status line as
   described in Section 4.3.3.  If the return code is a 2XX, the ICAP
   client SHOULD continue its normal execution of the request.  If the
   ICAP client is a surrogate, this may include serving an object from
   its cache or forwarding the modified request to an origin server.
   Note it is valid for a 2XX ICAP response to contain an encapsulated
   HTTP error response, which in turn should be returned to the
   downstream client by the ICAP client.

応答メッセージの最初の系列はセクション4.3.3で説明されるように状況表示行であるに違いありません。 復帰コードが2XXであるなら、ICAPクライアントSHOULDは要求の通常の実行を続けています。 ICAPクライアントが代理であるなら、これは、キャッシュからオブジェクトに役立つか、または変更された要求を発生源サーバに転送するのを含むかもしれません。2XX ICAP応答がICAPクライアントによって順番に川下のクライアントに返されるべきであるカプセル化されたHTTP誤り応答を含むのが、有効であることに注意してください。

   For other return codes that indicate an error, the ICAP client MAY
   (for example) return the error to the downstream client or user,
   execute the unadapted request as it arrived from the client, or re-
   try the adaptation again.

誤りを示す他の復帰コードのために、ICAPクライアントは、(例えば) 川下のクライアントかユーザに誤りを返すか、クライアントから到着したので「非-適合させ」られた要求を実行するか、または再び適合を再試みるかもしれません。

   The modified request headers, if any, MUST be returned to the ICAP
   client using appropriate encapsulation as described in Section 4.4.

セクション4.4で説明されるように適切なカプセル化を使用して、もしあれば変更された要求ヘッダーをICAPクライアントに返さなければなりません。

4.8.3  Examples

4.8.3 例

   Consider the following example, in which a surrogate receives a
   simple GET request from a client.  The surrogate, acting as an ICAP
   client, then forwards this request to an ICAP server for
   modification.  The ICAP server modifies the request headers and sends
   them back to the ICAP client.  Our hypothetical ICAP server will
   modify several headers and strip the cookie from the original
   request.

以下の例を考えてください。そこでは、代理がクライアントから簡単なGET要求を受け取ります。 そして、ICAPクライアントとして機能して、代理は変更のためのICAPサーバにこの要求を転送します。 ICAPサーバは、要求ヘッダーを変更して、ICAPクライアントに彼らを送り返します。 私たちの仮定しているICAPサーバは、オリジナルの要求から数個のヘッダーを変更して、クッキーを剥取るでしょう。

   In all of our examples, we include the extra meta-data added to the
   message due to chunking the encapsulated message body (if any).  We
   assume that end-of-line terminations, and blank lines, are two-byte
   "CRLF" sequences.

例では、全部で、私たちはカプセル化されたメッセージが具体化させる(もしあれば)分魂化のためメッセージに追加された付加的なメタデータを入れます。 私たちは、行末終了、および空白行が2バイトの"CRLF"系列であると思います。

Elson & Cerpa                Informational                     [Page 24]

RFC 3507                          ICAP                        April 2003

[24ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   ICAP Request Modification Example 1 - ICAP Request
   ----------------------------------------------------------------
   REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0
   Host: icap-server.net
   Encapsulated: req-hdr=0, null-body=170

ICAP要求変更の例1--ICAP要求---------------------------------------------------------------- REQMOD icap://icap-server.net/サーバ?arg=87 ICAP/1.0Host: icap-server.net Encapsulated: req-hdr=0、ヌルボディーの=170

   GET / HTTP/1.1
   Host: www.origin-server.com
   Accept: text/html, text/plain
   Accept-Encoding: compress
   Cookie: ff39fk3jur@4ii0e02i
   If-None-Match: "xyzzy", "r2d2xxxx"

/ HTTP/1.1ホストを手に入れてください: www.origin-server.com Accept: テキスト/html、テキスト/明瞭なAccept-コード化: Cookieを圧縮してください: ff39fk3jur@4ii0e02i 、なにも合っていないなら: "xyzzy"、"r2d2xxxx"

   ----------------------------------------------------------------
   ICAP Request Modification Example 1 - ICAP Response
   ----------------------------------------------------------------
   ICAP/1.0 200 OK
   Date: Mon, 10 Jan 2000  09:55:21 GMT
   Server: ICAP-Server-Software/1.0
   Connection: close
   ISTag: "W3E4R7U9-L2E4-2"
   Encapsulated: req-hdr=0, null-body=231

---------------------------------------------------------------- ICAP要求変更の例1--ICAP応答---------------------------------------------------------------- ICAP/1.0 200OK日付: グリニッジ標準時2000年1月10日月曜日9時55分21秒のサーバ: ICAPサーバソフトウェア/1.0接続: ISTagを閉じてください: 「W3E4R7U9-L2E4-2インチは要約されました」 req-hdr=0、ヌルボディーの=231

   GET /modified-path HTTP/1.1
   Host: www.origin-server.com
   Via: 1.0 icap-server.net (ICAP Example ReqMod Service 1.1)
   Accept: text/html, text/plain, image/gif
   Accept-Encoding: gzip, compress
   If-None-Match: "xyzzy", "r2d2xxxx"

変更された経路HTTP/1.1が接待する/を手に入れてください: www.origin-server.com Via: (ICAP Example ReqMod Service1.1)が受け入れる1.0icap-server.net: テキスト/明瞭で、gif Acceptをイメージ/コード化しているテキスト/html: gzip、なにも合わせないIfを圧縮してください: "xyzzy"、"r2d2xxxx"

   ----------------------------------------------------------------

----------------------------------------------------------------

   The second example is similar to the first, except that the request
   being modified in this case is a POST instead of a GET.  Note that
   the encapsulated Content-Length argument has been modified to reflect
   the modified body of the POST message.  The outer ICAP message does
   not need a Content-Length header because it uses chunking (not
   shown).

2番目の例は1日と同様です、この場合変更される要求がGETの代わりにポストであるのを除いて。 カプセル化されたContent-長さの議論がポストメッセージの変更されたボディーを反映するように変更されたことに注意してください。 分魂化(目立たない)を使用するので、外側のICAPメッセージはContent-長さのヘッダーを必要としません。

   In this second example, the Encapsulated header shows the division
   between the forwarded header and forwarded body, for both the request
   and the response.

この2番目の例では、Encapsulatedヘッダーは進められたヘッダーと進められたボディーの間の分割を見せています、要求と応答の両方のために。

   ICAP Request Modification Example 2 - ICAP Request
   ----------------------------------------------------------------
   REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0
   Host: icap-server.net
   Encapsulated: req-hdr=0, req-body=147

ICAP要求変更の例2--ICAP要求---------------------------------------------------------------- REQMOD icap://icap-server.net/サーバ?arg=87 ICAP/1.0Host: icap-server.net Encapsulated: req-hdr=0、req-ボディー=147

Elson & Cerpa                Informational                     [Page 25]

RFC 3507                          ICAP                        April 2003

[25ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   POST /origin-resource/form.pl HTTP/1.1
   Host: www.origin-server.com
   Accept: text/html, text/plain
   Accept-Encoding: compress
   Pragma: no-cache

発生源ポスト/リソース/form.pl HTTP/1.1ホスト: www.origin-server.com Accept: テキスト/html、テキスト/明瞭なAccept-コード化: Pragmaを圧縮してください: キャッシュがありません。

   1e
   I am posting this information.
   0

この情報を掲示する1e。 0

   ----------------------------------------------------------------
   ICAP Request Modification Example 2 - ICAP Response
   ----------------------------------------------------------------
   ICAP/1.0 200 OK
   Date: Mon, 10 Jan 2000  09:55:21 GMT
   Server: ICAP-Server-Software/1.0
   Connection: close
   ISTag: "W3E4R7U9-L2E4-2"
   Encapsulated: req-hdr=0, req-body=244

---------------------------------------------------------------- ICAP要求変更の例2--ICAP応答---------------------------------------------------------------- ICAP/1.0 200OK日付: グリニッジ標準時2000年1月10日月曜日9時55分21秒のサーバ: ICAPサーバソフトウェア/1.0接続: ISTagを閉じてください: 「W3E4R7U9-L2E4-2インチは要約されました」 req-hdr=0、req-ボディー=244

   POST /origin-resource/form.pl HTTP/1.1
   Host: www.origin-server.com
   Via: 1.0 icap-server.net (ICAP Example ReqMod Service 1.1)
   Accept: text/html, text/plain, image/gif
   Accept-Encoding: gzip, compress
   Pragma: no-cache
   Content-Length: 45

発生源ポスト/リソース/form.pl HTTP/1.1ホスト: www.origin-server.com Via: (ICAP Example ReqMod Service1.1)が受け入れる1.0icap-server.net: テキスト/明瞭で、gif Acceptをイメージ/コード化しているテキスト/html: gzip、Pragmaを圧縮してください: Content-長さをキャッシュしないでください: 45

   2d
   I am posting this information.  ICAP powered!
   0

この情報を掲示する2d。 動かされたICAP! 0

   ----------------------------------------------------------------
   Finally, this third example shows an ICAP server returning an error
   response when it receives a Request Modification request.

---------------------------------------------------------------- 最終的に、この3番目の例は、Request Modification要求を受け取るとき、ICAPサーバが誤り応答を返すのを示します。

   ICAP Request Modification Example 3 - ICAP Request
   ----------------------------------------------------------------
   REQMOD icap://icap-server.net/content-filter ICAP/1.0
   Host: icap-server.net
   Encapsulated: req-hdr=0, null-body=119

ICAP要求変更の例3--ICAP要求---------------------------------------------------------------- 満足しているREQMOD icap://icap-server.net/フィルタICAP/1.0Host: icap-server.net Encapsulated: req-hdr=0、ヌルボディーの=119

   GET /naughty-content HTTP/1.1
   Host: www.naughty-site.com
   Accept: text/html, text/plain
   Accept-Encoding: compress

下品の内容HTTP/1.1が接待する/を手に入れてください: www.naughty-site.com Accept: テキスト/html、テキスト/明瞭なAccept-コード化: 湿布

   ----------------------------------------------------------------

----------------------------------------------------------------

Elson & Cerpa                Informational                     [Page 26]

RFC 3507                          ICAP                        April 2003

[26ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   ICAP Request Modification Example 3 - ICAP Response
   ----------------------------------------------------------------
   ICAP/1.0 200 OK
   Date: Mon, 10 Jan 2000  09:55:21 GMT
   Server: ICAP-Server-Software/1.0
   Connection: close
   ISTag: "W3E4R7U9-L2E4-2"
   Encapsulated: res-hdr=0, res-body=213

ICAP要求変更の例3--ICAP応答---------------------------------------------------------------- ICAP/1.0 200OK日付: グリニッジ標準時2000年1月10日月曜日9時55分21秒のサーバ: ICAPサーバソフトウェア/1.0接続: ISTagを閉じてください: 「W3E4R7U9-L2E4-2インチは要約されました」 res-hdr=0、res-ボディー=213

   HTTP/1.1 403 Forbidden
   Date: Wed, 08 Nov 2000 16:02:10 GMT
   Server: Apache/1.3.12 (Unix)
   Last-Modified: Thu, 02 Nov 2000 13:51:37 GMT
   ETag: "63600-1989-3a017169"
   Content-Length: 58
   Content-Type: text/html

HTTP/1.1 403の禁制の日付: グリニッジ標準時2000年11月8日水曜日16時2分10秒のサーバ: アパッチ/1.3.12(unix)最終更新日: グリニッジ標準時2000年11月2日木曜日13時51分37秒ETag: 「63600-1989-3 a017169」コンテンツの長さ: 58コンテントタイプ: テキスト/html

   3a
   Sorry, you are not allowed to access that naughty content.
   0

3a、すみません、あなたはその下品の内容にアクセスできません。 0

   ----------------------------------------------------------------

----------------------------------------------------------------

4.9  Response Modification Mode

4.9 応答変更モード

   In this method, described in Section 3.2, an ICAP client sends an
   origin server's HTTP response to an ICAP server, and (if available)
   the original client request that caused that response.  Similar to
   Request Modification method, the response from the ICAP server can be
   an adapted HTTP response, an error, or a 204 response code indicating
   that no adaptation is required.

セクション3.2で説明されたこのメソッドで、ICAPクライアントはICAPサーバへの発生源サーバのHTTP応答、およびその応答を引き起こした(利用可能であるなら)オリジナルのクライアント要求を送ります。 Request Modificationメソッドと同様です、ICAPサーバからの応答は、適合は全く必要でないことを示す適合しているHTTP応答、誤り、または204応答コードであるかもしれません。

4.9.1  Request

4.9.1 要求

   Using encapsulation described in Section 4.4, the header and body of
   the HTTP response to be modified MUST be included in the ICAP body.
   If available, the header of the original client request SHOULD also
   be included.  As with the other method, the hop-by-hop headers of the
   encapsulated messages MUST NOT be forwarded.  The Encapsulated header
   MUST indicate the byte-offsets of the beginning of each of these four
   parts.

ICAPボディーに変更されるためにHTTP応答のセクション4.4、ヘッダー、およびボディーで説明されたカプセル化を使用するのを含まなければなりません。 利用可能であるなら、また、含まれていて、オリジナルのクライアントのヘッダーはSHOULDを要求します。 もう片方のメソッドでホップごとのカプセル化されたメッセージのヘッダーを進めてはいけないので。 Encapsulatedヘッダーはそれぞれのこれらの4つの部品の始まりのバイトオフセットを示さなければなりません。

4.9.2  Response

4.9.2 応答

   The response from the ICAP server looks just like a reply in the
   Request Modification method (Section 4.8); that is,

Request Modificationメソッド(セクション4.8)でICAPサーバからの応答はまさしく回答に似ています。 that is,

   -  An error indication,

- 誤り表示

Elson & Cerpa                Informational                     [Page 27]

RFC 3507                          ICAP                        April 2003

[27ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   -  An encapsulated and potentially modified HTTP response header and
      response body, or

- またはカプセル化された、潜在的に変更されたHTTP応答ヘッダと応答本体。

   -  An HTTP response 204 indicating that the ICAP client's request
      requires no adaptation.

- それを示すHTTP応答204は適合を全く必要としませんICAPクライアントのものが、要求する。

   The first line of the response message MUST be a status line as
   described in Section 4.3.3.  If the return code is a 2XX, the ICAP
   client SHOULD continue its normal execution of the response.  The
   ICAP client MAY re-examine the headers in the response's message
   headers in order to make further decisions about the response (e.g.,
   its cachability).

応答メッセージの最初の系列はセクション4.3.3で説明されるように状況表示行であるに違いありません。 復帰コードが2XXであるなら、ICAPクライアントSHOULDは応答の通常の実行を続けています。 ICAPクライアントは、さらに応答に関する決定を(例えば、cachability)にするように応答のメッセージヘッダーでヘッダーを再検討するかもしれません。

   For other return codes that indicate an error, the ICAP client SHOULD
   NOT return these directly to downstream client, since these errors
   only make sense in the ICAP client/server transaction.

誤りを示す他の復帰コードのために、ICAPクライアントSHOULD NOTは直接川下のクライアントにこれらを返します、これらの誤りがICAPクライアント/サーバトランザクションで理解できるだけであるので。

   The modified response headers, if any, MUST be returned to the ICAP
   client using appropriate encapsulation as described in Section 4.4.

セクション4.4で説明されるように適切なカプセル化を使用して、もしあれば変更された応答ヘッダをICAPクライアントに返さなければなりません。

4.9.3  Examples

4.9.3 例

   In Example 4, an ICAP client is requesting modification of an entity
   that was returned as a result of a client GET.  The original client
   GET was to an origin server at "www.origin-server.com"; the ICAP
   server is at "icap.example.org".

Example4では、ICAPクライアントはクライアントGETの結果、返された実体の変更を要求しています。 発生源サーバにはオリジナルのクライアントGETが"www.origin-server.com"にありました。 ICAPサーバが"icap.example.org"にあります。

   ICAP Response Modification Example 4 - ICAP Request
   ----------------------------------------------------------------
   RESPMOD icap://icap.example.org/satisf ICAP/1.0
   Host: icap.example.org
   Encapsulated: req-hdr=0, res-hdr=137, res-body=296

ICAP応答変更の例4--ICAP要求---------------------------------------------------------------- RESPMOD icap://icap.example.org/satisf ICAP/1.0Host: icap.example.org Encapsulated: req-hdr=0、res-hdr=137、res-ボディー=296

   GET /origin-resource HTTP/1.1
   Host: www.origin-server.com
   Accept: text/html, text/plain, image/gif
   Accept-Encoding: gzip, compress

発生源リソースHTTP/1.1が接待する/を手に入れてください: www.origin-server.com Accept: テキスト/明瞭で、gif Acceptをイメージ/コード化しているテキスト/html: gzip、湿布

   HTTP/1.1 200 OK
   Date: Mon, 10 Jan 2000 09:52:22 GMT
   Server: Apache/1.3.6 (Unix)
   ETag: "63840-1ab7-378d415b"
   Content-Type: text/html
   Content-Length: 51

HTTP/1.1 200OK日付: グリニッジ標準時2000年1月10日月曜日9時52分22秒のサーバ: アパッチ/1.3.6(unix)ETag: 「63840-1 ab7-378d415b」コンテントタイプ: html Contentテキスト/長さ: 51

Elson & Cerpa                Informational                     [Page 28]

RFC 3507                          ICAP                        April 2003

[28ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   33
   This is data that was returned by an origin server.
   0

33 これは発生源サーバ0時までに返されたデータです。

   ----------------------------------------------------------------

----------------------------------------------------------------

   ICAP Response Modification Example 4 - ICAP Response
   ----------------------------------------------------------------
   ICAP/1.0 200 OK
   Date: Mon, 10 Jan 2000  09:55:21 GMT
   Server: ICAP-Server-Software/1.0
   Connection: close
   ISTag: "W3E4R7U9-L2E4-2"
   Encapsulated: res-hdr=0, res-body=222

ICAP応答変更の例4--ICAP応答---------------------------------------------------------------- ICAP/1.0 200OK日付: グリニッジ標準時2000年1月10日月曜日9時55分21秒のサーバ: ICAPサーバソフトウェア/1.0接続: ISTagを閉じてください: 「W3E4R7U9-L2E4-2インチは要約されました」 res-hdr=0、res-ボディー=222

   HTTP/1.1 200 OK
   Date: Mon, 10 Jan 2000  09:55:21 GMT
   Via: 1.0 icap.example.org (ICAP Example RespMod Service 1.1)
   Server: Apache/1.3.6 (Unix)
   ETag: "63840-1ab7-378d415b"
   Content-Type: text/html
   Content-Length: 92

HTTP/1.1 200OK日付: 以下を通ってグリニッジ標準時2000年1月10日月曜日9時55分21秒 1.0icap.example.org(ICAP Example RespMod Service1.1)サーバ: アパッチ/1.3.6(unix)ETag: 「63840-1 ab7-378d415b」コンテントタイプ: html Contentテキスト/長さ: 92

   5c
   This is data that was returned by an origin server, but with
   value added by an ICAP server.
   0

5c、これ. 発生源サーバで返しましたが、ICAPサーバによる付加価値で返したデータは0です。

   ----------------------------------------------------------------

----------------------------------------------------------------

4.10  OPTIONS Method

4.10 オプションメソッド

   The ICAP "OPTIONS" method is used by the ICAP client to retrieve
   configuration information from the ICAP server.  In this method, the
   ICAP client sends a request addressed to a specific ICAP resource and
   receives back a response with options that are specific to the
   service named by the URI.  All OPTIONS requests MAY also return
   options that are global to the server (i.e., apply to all services).

ICAP「オプション」メソッドは、ICAPサーバからの設定情報を検索するのにICAPクライアントによって使用されます。このメソッドで、ICAPクライアントは、特定のICAPリソースに扱われた要求を送って、URIによって指定されたサービスに特定のオプションで応答を受け返します。 また、すべてのOPTIONS要求がサーバにグローバルなオプションを返すかもしれません(すなわち、すべてのサービスに適用してください)。

4.10.1 OPTIONS Request

4.10.1 オプション要求

   The OPTIONS method consists of a request-line, as described in
   Section 4.3.2, such as the following example:

OPTIONSメソッドは以下の.2のセクション4.3の例などで説明されるように要求系列から成ります:

   OPTIONS icap://icap.server.net/sample-service ICAP/1.0 User-Agent:
   ICAP-client-XYZ/1.001

サンプルOPTIONS icap://icap.server.net/サービスICAP/1.0User-エージェント: ICAPクライアントXYZ/1.001

Elson & Cerpa                Informational                     [Page 29]

RFC 3507                          ICAP                        April 2003

[29ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   Other headers are also allowed as described in Section 4.3.1 and
   Section 4.3.2 (for example, Host).

また、他のヘッダーはセクション4.3.1とセクション4.3.2(例えば、Host)で説明されるように許容されています。

4.10.2 OPTIONS Response

4.10.2 オプション応答

   The OPTIONS response consists of a status line as described in
   section 4.3.3 followed by a series of header field names-value pairs
   optionally followed by an opt-body.  Multiple values in the value
   field MUST be separated by commas.  If an opt-body is present in the
   OPTIONS response, the Opt-body-type header describes the format of
   the opt-body.

OPTIONS応答が値を命名している組が任意に続いたヘッダーフィールドのシリーズがあとに続いていて、セクション4.3.3で説明されるように状況表示行から成る、ボディーを選びます。 コンマで値の分野の複数の値を切り離さなければなりません。 Optボディータイプヘッダーは、ボディーを選ぶのが、OPTIONS応答でプレゼントであると形式を説明します。ボディーを選びます。

   The OPTIONS headers supported in this version of the protocol are:

プロトコルのこのバージョンで支えられたOPTIONSヘッダーは以下の通りです。

   -- Methods:

-- メソッド:

      The method that is supported by this service.  This header MUST be
      included in the OPTIONS response.  The OPTIONS method MUST NOT be
      in the Methods' list since it MUST be supported by all the ICAP
      server implementations.  Each service should have a distinct URI
      and support only one method in addition to OPTIONS (see Section
      6.4).

このサービスでサポートされるメソッド。 OPTIONS応答にこのヘッダーを含まなければなりません。 OPTIONSメソッドが、すべてのICAPサーバ実装でそれをサポートしなければならないので、Methodsのリストにあるはずがありません。 各サービスは、異なったURIを持って、OPTIONSに加えた1つのメソッドだけをサポートするべきです(セクション6.4を見てください)。

      For example:
      Methods: RESPMOD

例えば: メソッド: RESPMOD

   -- Service:

-- サービス:

      A text description of the vendor and product name.  This header
      MAY be included in the OPTIONS response.

ベンダーと製品名のテキスト記述。 このヘッダーはOPTIONS応答に含まれるかもしれません。

      For example:
      Service: XYZ Technology Server 1.0

例えば: サービス: XYZ技術サーバ1.0

   -- ISTag:

-- ISTag:

      See section 4.7 for details.  This header MUST be included in the
      OPTIONS response.

詳細に関してセクション4.7を見てください。 OPTIONS応答にこのヘッダーを含まなければなりません。

      For example:
      ISTag: "5BDEEEA9-12E4-2"

例えば: ISTag: 「5BDEEEA9-12E42インチ」

   -- Encapsulated:

-- カプセル化される:

      This header MUST be included in the OPTIONS response; see Section
      4.4.

OPTIONS応答にこのヘッダーを含まなければなりません。 セクション4.4を見てください。

Elson & Cerpa                Informational                     [Page 30]

RFC 3507                          ICAP                        April 2003

[30ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

      For example:
      Encapsulated: opt-body=0

例えば: カプセル化される: ボディー=を選んでいる0

   -- Opt-body-type:

-- ボディータイプを選んでください:

      A token identifying the format of the opt-body.  (Valid opt-body
      types are not defined by ICAP.)  This header MUST be included in
      the OPTIONS response ONLY if an opt-body type is present.

形式を特定するトークン、ボディーを選びます。 (有効なボディーを選んでいるタイプはICAPによって定義されません。) ボディーを選んでいるタイプが出席しているだけであるなら、OPTIONS応答にこのヘッダーを含まなければなりません。

      For example:
      Opt-body-type: XML-Policy-Table-1.0

例えば: ボディータイプを選んでください: XML方針テーブル1.0

   -- Max-Connections:

-- マックス-コネクションズ:

      The maximum number of ICAP connections the server is able to
      support.  This header MAY be included in the OPTIONS response.

サーバがサポートすることができるICAP接続の最大数。 このヘッダーはOPTIONS応答に含まれるかもしれません。

      For example:
      Max-Connections: 1500

例えば: マックス-コネクションズ: 1500

   -- Options-TTL:

-- オプション-TTL:

      The time (in seconds) for which this OPTIONS response is valid.
      If none is specified, the OPTIONS response does not expire.  This
      header MAY be included in the OPTIONS response.  The ICAP client
      MAY reissue an OPTIONS request once the Options-TTL expires.

このOPTIONS応答が有効である時(秒の)。 なにも指定されないなら、OPTIONS応答は期限が切れません。 このヘッダーはOPTIONS応答に含まれるかもしれません。 Options-TTLがいったん期限が切れると、ICAPクライアントはOPTIONS要求を再発行するかもしれません。

      For example:
      Options-TTL: 3600

例えば: オプション-TTL: 3600

   -- Date:

-- 日付:

      The server's clock, specified as an RFC 1123 compliant date/time
      string.  This header MAY be included in the OPTIONS response.

RFC1123対応することの日付/時間ストリングとして指定されたサーバの時計。 このヘッダーはOPTIONS応答に含まれるかもしれません。

      For example:
      Date: Fri, 15 Jun 2001 04:33:55 GMT

例えば: 日付: グリニッジ標準時2001年6月15日金曜日4時33分55秒

   -- Service-ID:

-- サービスID:

      A short label identifying the ICAP service.  It MAY be used in
      attribute header names.  This header MAY be included in the
      OPTIONS response.

ICAPサービスを特定する脆いラベル。 それは属性ヘッダー名に使用されるかもしれません。 このヘッダーはOPTIONS応答に含まれるかもしれません。

      For example:
      Service-ID: xyztech

例えば: サービスID: xyztech

Elson & Cerpa                Informational                     [Page 31]

RFC 3507                          ICAP                        April 2003

[31ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   -- Allow:

-- 許容します:

      A directive declaring a list of optional ICAP features that this
      server has implemented.  This header MAY be included in the
      OPTIONS response.  In this document we define the value "204" to
      indicate that the ICAP server supports a 204 response.

このサーバが実装した任意のICAPの特徴のリストを宣言する指示。 このヘッダーはOPTIONS応答に含まれるかもしれません。 本書では私たちは、ICAPサーバが204応答をサポートするのを示すために値「204」を定義します。

      For example:
      Allow: 204

例えば: 許容します: 204

   -- Preview:

-- 以下を下見してください。

      The number of bytes to be sent by the ICAP client during a
      preview.  This header MAY be included in the OPTIONS response.

プレビューの間にICAPクライアントによって送られるバイト数。 このヘッダーはOPTIONS応答に含まれるかもしれません。

      For example:
      Preview: 1024

例えば: 以下を下見してください。 1024

   -- Transfer-Preview:

-- 転送プレビュー:

      A list of file extensions that should be previewed to the ICAP
      server before sending them in their entirety.  This header MAY be
      included in the OPTIONS response.  Multiple file extensions values
      should be separated by commas.  The wildcard value "*" specifies
      the default behavior for all the file extensions not specified in
      any other Transfer-* header (see below).

それらを全体として送る前にICAPサーバに下見されるべきであるファイル拡張子のリスト。 このヘッダーはOPTIONS応答に含まれるかもしれません。 複数のファイル拡張子値がコンマによって切り離されるべきです。 ワイルドカード値の「*」はいかなる他の転送*ヘッダーでも指定されたというわけではないすべてのファイル拡張子のためのデフォルトの振舞いを指定します(以下を見てください)。

      For example:
      Transfer-Preview: *

例えば: 転送プレビュー: *

   -- Transfer-Ignore:

-- 以下を転送で無視してください。

      A list of file extensions that should NOT be sent to the ICAP
      server.  This header MAY be included in the OPTIONS response.
      Multiple file extensions should be separated by commas.

. ICAPサーバへのこのヘッダーに送られるべきでないファイル拡張子のリストはOPTIONS応答に含まれるかもしれません。 複数のファイル拡張子がコンマによって切り離されるべきです。

      For example:
      Transfer-Ignore: html

例えば: 以下を転送で無視してください。 html

   -- Transfer-Complete:

-- 転送完全:

      A list of file extensions that should be sent in their entirety
      (without preview) to the ICAP server.  This header MAY be included
      in the OPTIONS response.  Multiple file extensions values should
      be separated by commas.

ICAPサーバに全体として(プレビューなしで)送って. このヘッダーがOPTIONS応答に含まれるかもしれないということであるべきであるファイル拡張子のリスト。 複数のファイル拡張子値がコンマによって切り離されるべきです。

      For example:
      Transfer-Complete: asp, bat, exe, com, ole

例えば: 転送完全: エジプトコブラ、バット、exe、com、ole

Elson & Cerpa                Informational                     [Page 32]

RFC 3507                          ICAP                        April 2003

[32ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   Note: If any of Transfer-* are sent, exactly one of them MUST contain
   the wildcard value "*" to specify the default.  If no Transfer-* are
   sent, all responses will be sent in their entirety (without Preview).

以下に注意してください。 もしあれば、ちょうどそれらの1つは、Transfer-*を送って、デフォルトを指定するためにワイルドカード値の「*」を含まなければなりません。 Transfer-*を全く送らないと、すべての応答を全体として(Previewなしで)送るでしょう。

4.10.3 OPTIONS Examples

4.10.3 オプションの例

   In example 5, an ICAP Client sends an OPTIONS Request to an ICAP
   Service named icap.server.net/sample-service in order to get
   configuration information for the service provided.

例5では、ICAP Clientはサービスのための設定情報を提供させるためにサンプルicap.server.net/サービスというICAP ServiceにOPTIONS Requestを送ります。

   ICAP OPTIONS Example 5 - ICAP OPTIONS Request
   ----------------------------------------------------------------
   OPTIONS icap://icap.server.net/sample-service ICAP/1.0
   Host: icap.server.net
   User-Agent: BazookaDotCom-ICAP-Client-Library/2.3

ICAPは例5をゆだねます--ICAPは要求をゆだねます。---------------------------------------------------------------- サンプルOPTIONS icap://icap.server.net/サービスICAP/1.0Host: icap.server.net User-エージェント: BazookaDotCom-ICAPクライアント図書館/2.3

   ----------------------------------------------------------------

----------------------------------------------------------------

   ICAP OPTIONS Example 5 - ICAP OPTIONS Response
   ----------------------------------------------------------------
   ICAP/1.0 200 OK
   Date: Mon, 10 Jan 2000  09:55:21 GMT
   Methods: RESPMOD
   Service: FOO Tech Server 1.0
   ISTag: "W3E4R7U9-L2E4-2"
   Encapsulated: null-body=0
   Max-Connections: 1000
   Options-TTL: 7200
   Allow: 204
   Preview: 2048
   Transfer-Complete: asp, bat, exe, com
   Transfer-Ignore: html
   Transfer-Preview: *

ICAPは例5をゆだねます--ICAPは応答をゆだねます。---------------------------------------------------------------- ICAP/1.0 200OK日付: グリニッジ標準時2000年1月10日月曜日9時55分21秒のメソッド: RESPMODサービス: FOOの科学技術のサーバ1.0ISTag: 「W3E4R7U9-L2E4-2インチは要約されました」 ヌルボディーの=0マックス-コネクションズ: 1000オプション-TTL: 7200 許容します: 204プレビュー: 2048 転送完全: エジプトコブラ、バット、exeは以下をcom Transfer無視します。 html Transfer-プレビュー: *

   ----------------------------------------------------------------

----------------------------------------------------------------

5.  Caching

5. キャッシュ

   ICAP servers' responses MAY be cached by ICAP clients, just as any
   other surrogate might cache HTTP responses.  Similar to HTTP, ICAP
   clients MAY always store a successful response (see sections 4.8.2
   and 4.9.2) as a cache entry, and MAY return it without validation if
   it is fresh. ICAP servers use the caching directives described in
   HTTP/1.1 [4].

ICAPサーバの応答5月がICAPクライアントによってキャッシュされて、ちょうどいかなる他の代理もキャッシュするかもしれないようにHTTP応答をキャッシュしてください。 HTTPと同様です、ICAPクライアントがいつもうまくいっている応答を保存するかもしれない、(セクション4.8 .2と4.9を見てください、.2)、aはエントリーをキャッシュして、それが新鮮であるなら、合法化なしでそれを返すかもしれません。 ICAPサーバは指示がHTTP/1.1[4]で説明したキャッシュを使用します。

   In Request Modification mode, the ICAP server MAY include caching
   directives in the ICAP header section of the ICAP response (NOT in
   the encapsulated HTTP request of the ICAP message body).  In Response

Request Modificationモードでは、ICAPサーバは、ICAP応答(ICAPメッセージボディーのカプセル化されたHTTP要求でないのにおける)のICAPヘッダー部分で指示をキャッシュするのを含むかもしれません。 応答で

Elson & Cerpa                Informational                     [Page 33]

RFC 3507                          ICAP                        April 2003

[33ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   Modification mode, the ICAP server MAY add or modify the HTTP caching
   directives located in the encapsulated HTTP response (NOT in the ICAP
   header section).  Consequently, the ICAP client SHOULD look for
   caching directives in the ICAP headers in case of REQMOD, and in the
   encapsulated HTTP response in case of RESPMOD.

変更モード、ICAPサーバはカプセル化されたHTTP応答(ICAPヘッダー部分でないところの)で位置する指示をキャッシュするHTTPを、加えるか、または変更するかもしれません。 その結果、ICAPクライアントSHOULDは、RESPMODの場合にREQMODの場合のICAPヘッダー、およびカプセル化されたHTTP応答における指示をキャッシュするのを見ます。

   In cases where an ICAP server returns a modified version of an object
   created by an origin server, such as in Response Modification mode,
   the expiration of the ICAP-modified object MUST NOT be longer than
   that of the origin object.  In other words, ICAP servers MUST NOT
   extend the lifetime of origin server objects, but MAY shorten it.

ICAPサーバがResponse Modificationモードなどの発生源サーバによって作成されたオブジェクトの変更されたバージョンを返す場合では、それより長い間、ICAPによって変更されたオブジェクトの満了は発生源オブジェクトのものであるはずがありません。 言い換えれば、ICAPサーバは、発生源サーバオブジェクトの生涯を広げてはいけませんが、それを短くするかもしれません。

   In cases where the ICAP server is the authoritative source of an ICAP
   response, such as in Request Modification mode, the ICAP server is
   not restricted in its expiration policy.

ICAPサーバがRequest ModificationモードなどのICAP応答の権威筋である場合では、ICAPサーバは満了方針で制限されません。

   Note that the ISTag response-header may also be used to providing
   caching hints to clients; see Section 4.7.

また、ISTag応答ヘッダがクライアントにヒントをキャッシュしながら提供するのに慣れるかもしれないことに注意してください。 セクション4.7を見てください。

6.  Implementation Notes

6. 実装注意

6.1  Vectoring Points

6.1 ベクトル決定ポイント

   The definition of the ICAP protocol itself only describes two
   different adaptation channels: modification (and satisfaction) of
   requests, and modifications of replies.  However, an ICAP client
   implementation is likely to actually distinguish among four different
   classes of adaptation:

ICAPプロトコル自体の定義は2個の異なった適合チャンネルしか説明しません: 要求の変更(そして、満足)、および回答の変更。 しかしながら、ICAPクライアント実装は実際に適合の4つの異なったクラスで区別しそうです:

   1.  Adaptation of client requests.  This is adaptation done every
       time a request arrives from a client.  This is adaptation done
       when a request is "on its way into the cache".  Factors such as
       the state of the objects currently cached will determine whether
       or not this request actually gets forwarded to an origin server
       (instead of, say, getting served off the cache's disk).  An
       example of this type of adaptation would be special access
       control or authentication services that must be performed on a
       per-client basis.

1. クライアント要求の適合。 これは要求がクライアントから到着するときはいつも、行われた適合です。 これは「要求はキャッシュに近づいているとき」行われた適合です。 現在キャッシュされているオブジェクトの状態などの要素は、この要求が実際に発生源サーバ(たとえば、キャッシュのディスクで役立たれることの代わりに)に送られるかどうか決定するでしょう。 このタイプの適合に関する例は、1クライアントあたり1個のベースに実行しなければならない特別なアクセスコントロールか認証サービスでしょう。

   2.  Adaptation of requests on their way to an origin server.
       Although this type of adaptation is also an adaptation of
       requests similar to (1), it describes requests that are "on their
       way out of the cache"; i.e., if a request actually requires that
       an origin server be contacted.  These adaptation requests are not
       necessarily specific to particular clients.  An example would be
       addition of "Accept:"  headers for special devices; these
       adaptations can potentially apply to many clients.

2. 適合、発生源サーバへの途中での要求. また、このタイプの適合は(1)と同様の要求の適合ですが、「キャッシュから近づいています」要求について説明します。 すなわち、要求が、実際に発生源サーバが連絡されるのを必要とするなら。 特定のクライアントには、これらの適合要求は必ず特定であるというわけではありません。 例は「受け入れてください」の追加でしょう。 特別なデバイスのためのヘッダー。 潜在的にこれらの適合は多くのクライアントに適用できます。

Elson & Cerpa                Informational                     [Page 34]

RFC 3507                          ICAP                        April 2003

[34ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   3.  Adaptations of responses coming from an origin server.  This is
       the adaptation of an object "on its way into the cache".  In
       other words, this is adaptation that a surrogate might want to
       perform on an object before caching it.  The adapted object may
       subsequently served to many clients.  An example of this type of
       adaptation is virus checking: a surrogate will want to check an
       incoming origin reply for viruses once, before allowing it into
       the cache -- not every time the cached object is served to a
       client.

3. 適合、発生源サーバからの応答到来では. これは「キャッシュに途中の」オブジェクトの適合です。 言い換えれば、これはそれをキャッシュする前に代理がオブジェクトに実行したがっているかもしれない適合です。 適合しているオブジェクトは次に、多くのクライアントにサービスされていた状態でそうするかもしれません。 このタイプの適合に関する例はウイルスの照合です: 代理はウイルスがないかどうか一度入って来る発生源回答をチェックしたくなるでしょう、キャッシュされたオブジェクトがクライアントにサービスされているたびにキャッシュにそれを許容する前に。

       Adaptation of responses coming from the surrogate, heading back
       to the client.  Although this type of adaptation, like (3), is
       the adaptation of a response, it is client-specific.  Client
       reply adaptation is adaptation that is required every time an
       object is served to a client, even if all the replies come from
       the same cached object off of disk.  Ad insertion is a common
       form of this kind of adaptation; e.g., if a popular (cached)
       object that rarely changes needs a different ad inserted into it
       every time it is served off disk to a client.  Note that the
       relationship between adaptations of type (3) and (4) is analogous
       to the relationship between types (2) and (1).

クライアントに向かって戻って、代理から来る応答の適合。 (3)のように、このタイプの適合は応答の適合ですが、それはクライアント特有です。 クライアント回答適合はオブジェクトがクライアントにサービスされているときはいつも、必要である適合です、すべての回答が同じキャッシュされたオブジェクトからディスクから来ても。 広告挿入は一般的な形式のこの種類の適合です。 例えば、めったに変化しないポピュラーな(キャッシュされる)オブジェクトが、毎回異なった広告をそれに載せる必要があるなら、それはディスクでクライアントにサービスされています。 タイプ(3)と(4)の適合の間の関係がタイプ(2)と(1)の間の関係に類似していることに注意してください。

   Although the distinction among these four adaptation points is
   critical for ICAP client implementations, the distinction is not
   significant for the ICAP protocol itself.  From the point of view of
   an ICAP server, a request is a request -- the ICAP server doesn't
   care what policy led the ICAP client to generate the request.  We
   therefore did not make these four channels explicit in ICAP for
   simplicity.

ICAPクライアント実装に、これらの4適合ポイントの中の区別は重要ですが、ICAPプロトコル自体には、区別は重要ではありません。 ICAPサーバの観点から、要求は要求です--ICAPサーバは、どんな方針が、ICAPクライアントが要求を生成するように導いたかを気にかけません。 したがって、私たちはこれらの4個のチャンネルをICAPで簡単さに明白にしませんでした。

6.2  Application Level Errors

6.2 アプリケーションレベル誤り

   Section 4 described "on the wire" protocol errors that MUST be
   standardized across implementations to ensure interoperability.  In
   this section, we describe errors that are communicated between ICAP
   software and the clients and servers on which they are implemented.
   Although such errors are implementation dependent and do not
   necessarily need to be standardized because they are "within the
   box", they are presented here as advice to future implementors based
   on past implementation experience.

セクション4は「ワイヤ」で相互運用性を確実にするために実装の向こう側に標準化しなければならないプロトコル誤りについて説明しました。 このセクションで、私たちはICAPソフトウェアとクライアントの間で伝えられる誤りとそれらが実装されるサーバについて説明します。 そのような誤りは、実装に依存していて、必ずそれらが「箱」にあるので標準化される必要があるというわけではありませんが、それらはアドバイスとしてここに過去の実装経験に基づく将来の作成者に提示されます。

Elson & Cerpa                Informational                     [Page 35]

RFC 3507                          ICAP                        April 2003

[35ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   Error name                                     Value
   ====================================================
   ICAP_CANT_CONNECT                               1000
   ICAP_SERVER_RESPONSE_CLOSE                      1001
   ICAP_SERVER_RESPONSE_RESET                      1002
   ICAP_SERVER_UNKNOWN_CODE                        1003
   ICAP_SERVER_UNEXPECTED_CLOSE_204                1004
   ICAP_SERVER_UNEXPECTED_CLOSE                    1005

エラー名Value==================================================== ICAP_合言葉_は1004年の予期していなかった近い1000年の1001年の1002年の近いICAP_サーバのICAP_サーバ_未知の__応答_ICAP_サーバ_応答_リセットコード1003のICAP_サーバ_予期していなかった_ICAP_サーバ___204閉鎖1005を接続します。

   1000 ICAP_CANT_CONNECT:
       "Cannot connect to ICAP server".

1000 ICAP_合言葉_は接続します: 「ICAPサーバに接続できません。」

       The ICAP server is not connected on the socket.  Maybe the ICAP
       server is dead or it is not connected on the socket.

ICAPサーバはソケットに接続されません。 多分、ICAPサーバが死んでいるか、またはそれはソケットに接続されません。

   1001 ICAP_SERVER_RESPONSE_CLOSE:
       "ICAP Server closed connection while reading response".

1001年のICAP_サーバ_応答_は閉じます: 「ICAP Serverは応答を読む間、接続を終えました。」

       The ICAP server TCP-shutdowns the connection before the ICAP
       client can send all the body data.

ICAPクライアントの前での接続がすべてのボディーデータを送ることができるICAPサーバTCP-閉鎖。

   1002 ICAP_SERVER_RESPONSE_RESET:
       "ICAP Server reset connection while reading response".

1002年のICAP_サーバ_応答_は以下をリセットします。 「ICAP Serverは応答を読んでいる間、接続をリセットしました。」

       The ICAP server TCP-reset the connection before the ICAP client
       can send all the body data.

ICAPクライアントがすべてのボディーデータを送ることができる前にICAPサーバは接続をTCPリセットしました。

   1003 ICAP_SERVER_UNKNOWN_CODE:
       "ICAP Server sent unknown response code".

1003年のICAP_サーバの_の未知の_コード: 「ICAP Serverは未知の応答コードを送りました。」

       An unknown ICAP response code (see Section 4.x) was received by
       the ICAP client.

未知のICAP応答コード(セクション4.xを見る)はICAPクライアントによって受け取られました。

   1004 ICAP_SERVER_UNEXPECTED_CLOSE_204:
       "ICAP Server closed connection on 204 without 'Connection: close'
       header".

_の予期していなかった1004年のICAP_サーバ_は_204を閉じます: 「ICAP Serverは'接続なしで204に接続を引けた'、」 「''ヘッダーを閉じてください。」

       An ICAP server MUST send the "Connection: close" header if
       intends to close after the current transaction.

ICAPサーバが発信しなければならない、「接続:」 「近い」ヘッダー、経常取引の後に閉じるつもりです。

   1005 ICAP_SERVER_UNEXPECTED_CLOSE:
       "ICAP Server closed connection as ICAP client wrote body
       preview".

_の予期していなかった1005年のICAP_サーバ_は閉じます: 「ICAPクライアントがボディープレビューを書いたとき、ICAP Serverは接続を終えました。」

Elson & Cerpa                Informational                     [Page 36]

RFC 3507                          ICAP                        April 2003

[36ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

6.3  Use of Chunked Transfer-Encoding

6.3 Chunked転送コード化の使用

   For simplicity, ICAP messages MUST use the "chunked" transfer-
   encoding within the encapsulated body section as defined in HTTP/1.1
   [4].  This requires that ICAP client implementations convert incoming
   objects "on the fly" to chunked from whatever transfer-encoding on
   which they arrive.  However, the transformation is simple:

簡単さのために、ICAPメッセージはHTTP/1.1[4]で定義されるようにカプセル化されたボディー部の中で"chunkedする"の転送コード化を使用しなければなりません。 これは、ICAPクライアント実装が「急いで」それらが到着するいかなる転送コード化からもchunkedされるのに入って来るオブジェクトを変換するのを必要とします。 しかしながら、変換は簡単です:

   -  For objects arriving using "Content-Length" headers, one big chunk
      can be created of the same size as indicated in the Content-Length
      header.

- 「コンテンツの長さ」ヘッダーを使用することで届くオブジェクトに関しては、Content-長さのヘッダーにみられるように同じサイズについて1つの大きい塊を作成できます。

   -  For objects arriving using a TCP close to signal the end of the
      object, each incoming group of bytes read from the OS can be
      converted into a chunk (by writing the length of the bytes read,
      followed by the bytes themselves)

- オブジェクトの端に合図するのに近くでTCPを使用することで届くオブジェクトに関しては、OSから読まれたバイトのそれぞれの入って来るグループを塊に変換できます。(書くことによる読まれたバイトの長さバイト自体があとに続いていて、

   -  For objects arriving using chunked encoding, they can be
      retransmitted as is (without re-chunking).

- chunkedコード化を使用することで届くオブジェクトに関しては、そのままで(再分魂化なしで)それらを再送できます。

6.4  Distinct URIs for Distinct Services

6.4 異なったサービスのための異なったURI

   ICAP servers SHOULD assign unique URIs to each service they provide,
   even if such services might theoretically be differentiated based on
   their method.  In other words, a REQMOD and RESPMOD service should
   never have the same URI, even if they do something that is
   conceptually the same.

ICAPサーバSHOULDはそれらが提供する各サービスにユニークなURIを割り当てます、そのようなサービスがそれらのメソッドに基づいて理論的に差別化されるかもしれなくても。 言い換えれば、REQMODとRESPMODサービスには、同じURIが決してあるべきではありません、彼らが概念的に何か同じことをしても。

   This situation in ICAP is similar to that found in HTTP where it
   might, in theory, be possible to perform a GET or a POST to the same
   URI and expect two different results.  This kind of overloading of
   URIs only causes confusion and should be avoided.

ICAPのこの状況は同じURIにGETかポストを実行して、2つの異なった結果を予想するのが理論上可能であるかもしれないHTTPで見つけられたそれと同様です。 この種類のURIの積みすぎだけが、混乱を引き起こして、避けられるべきです。

7.  Security Considerations

7. セキュリティ問題

7.1  Authentication

7.1 認証

   Authentication in ICAP is very similar to proxy authentication in
   HTTP as specified in RFC 2617.  Specifically, the following rules
   apply:

ICAPでの認証はRFC2617の指定されるとしてのHTTPにおけるプロキシ認証と非常に同様です。 明確に、以下の規則は適用されます:

   -  WWW-Authenticate challenges and responses are for end-to-end
      authentication between a client (user) and an origin server.  As
      any proxy, ICAP clients and ICAP servers MUST forward these
      headers without modification.

- 挑戦をWWW認証してください。そうすれば、クライアント(ユーザ)と発生源サーバの間には、応答は終わりから終わりへの認証のためにあります。どんなプロキシとしても、ICAPクライアントとICAPサーバは変更なしでこれらのヘッダーを進めなければなりません。

Elson & Cerpa                Informational                     [Page 37]

RFC 3507                          ICAP                        April 2003

[37ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   -  If authentication is required between an ICAP client and ICAP
      server, hop-by-hop Proxy Authentication as described in RFC 2617
      MUST be used.

- 認証がICAPクライアントとICAPサーバの間で必要であるなら、ホップごとのRFC2617で説明されるProxy Authenticationを使用しなければなりません。

   There are potential applications where a user (as opposed to ICAP
   client) might have rights to access an ICAP service.  In this version
   of the protocol, we assume that ICAP clients and ICAP servers are
   under the same administrative domain, and contained in a single trust
   domain. Therefore, in these cases, we assume that it is sufficient
   for users to authenticate themselves to the ICAP client (which is a
   surrogate from the point of view from the user).  This type of
   authentication will also be Proxy Authentication as described in RFC
   2617.

潜在的利用がユーザ(ICAPクライアントと対照的に)がICAPサービスにアクセスする権利を持っているかもしれないところにあります。 プロトコルのこのバージョンでは、私たちは、ICAPクライアントとICAPサーバが同じ管理ドメインの下にあって、ただ一つの信頼ドメインに含まれていると思います。 したがって、これらの場合では、私たちは、ユーザがICAPクライアント(ユーザからの観点からの代理である)に自分たちを認証するのが、十分であると思います。 また、このタイプの認証はRFC2617で説明されるようにProxy Authenticationになるでしょう。

   This standard explicitly excludes any method for a user to
   authenticate directly to an ICAP server; the ICAP client MUST be
   involved as described above.

この規格は明らかにユーザが直接ICAPサーバに認証するどんなメソッドも除きます。 ICAPクライアントは上で説明されるようにかかわっているに違いありません。

7.2  Encryption

7.2 暗号化

   Users of ICAP should note well that ICAP messages are not encrypted
   for transit by default.  In the absence of some other form of
   encryption at the link or network layers, eavesdroppers may be able
   to record the unencrypted transactions between ICAP clients and
   servers.  As described in Section 4.3.1, the Upgrade header MAY be
   used to negotiate transport-layer security for an ICAP connection
   [5].

ICAPのユーザは、ICAPメッセージがトランジットのためにデフォルトで暗号化されないことによく注意するべきです。 リンクかネットワーク層における、ある他の形式の暗号化がないとき、立ち聞きする者はICAPクライアントとサーバの間の非暗号化されたトランザクションを記録できるかもしれません。 セクション4.3.1で説明されるように、UpgradeヘッダーはICAP接続[5]のためにトランスポート層セキュリティを交渉するのにおいて使用されているかもしれません。

   Note also that end-to-end encryption between a client and origin
   server is likely to preclude the use of value-added services by
   intermediaries such as surrogates.  An ICAP server that is unable to
   decrypt a client's messages will, of course, be unable to perform any
   transformations on it.

また、クライアントと発生源サーバの間の終端間暗号化が代理などの仲介者による付加価値が付いたサービスの使用を排除しそうに注意してください。 クライアントのメッセージを解読することができないICAPサーバはもちろんそれにどんな変換も実行できないでしょう。

7.3  Service Validation

7.3 サービス合法化

   Normal HTTP surrogates, when operating correctly, should not affect
   the end-to-end semantics of messages that pass through them.  This
   forms a well-defined criterion to validate that a surrogate is
   working correctly: a message should look the same before the
   surrogate as it does after the surrogate.

正しく作動するとき、普通のHTTP代理はそれらを通り抜けるメッセージの終わりから終わりへの意味論に影響するはずがありません。 これは有効にする代理が正しく扱っている明確な評価基準を形成します: メッセージは代理の後にするように代理の前で同じに見えるべきです。

   In contrast, ICAP is meant to cause changes in the semantics of
   messages on their way from origin servers to users.  The criteria for
   a correctly operating surrogate are no longer as easy to define.
   This will make validation of ICAP services significantly more
   difficult.  Incorrect adaptations may lead to security
   vulnerabilities that were not present in the unadapted content.

対照的に、ICAPは発生源サーバからユーザへの途中でメッセージの意味論における変化を引き起こすことになっています。 正しく稼働している代理の評価基準はもう同じくらい定義しにくいです。 これで、ICAPサービスの合法化はかなり難しくなるでしょう。 不正確な適合は「非-適合させ」られた内容に存在していないセキュリティの脆弱性につながるかもしれません。

Elson & Cerpa                Informational                     [Page 38]

RFC 3507                          ICAP                        April 2003

[38ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

8.  Motivations and Design Alternatives

8. 動機とデザイン代替手段

   This section describes some of our design decisions in more detail,
   and describes the ideas and motivations behind them.  This section
   does not define protocol requirements, but hopefully sheds light on
   the requirements defined in previous sections.  Nothing in this
   section carries the "force of law" or is part of the formal protocol
   specification.

このセクションは、さらに詳細に私たちのデザイン決定のいくつかについて説明して、それらの後ろで考えと動機について説明します。 このセクションは、プロトコル要件を定義しませんが、希望をいだいて前項で定義された要件を解明します。 このセクションの何はも、「法律効力」を運ぶか、正式なプロトコル仕様の一部ではありませんでも。

   In general, our guiding principle was to make ICAP the simplest
   possible protocol that would do the job, and no simpler.  Some
   features were rejected where alternative (non-protocol-based)
   solutions could be found.  In addition, we have intentionally left a
   number of issues at the discretion of the implementor, where we
   believe that doing so does not compromise interoperability.

一般に、私たちの指導原理は、ICAPを仕事をする可能な限り簡単なプロトコルにするようにあって、より簡単ではありません。 いくつかの特徴が代替(非プロトコルベースの)のソリューションを見つけることができたところで拒絶されました。 さらに、私たちは故意に作成者の裁量における多くの問題を残しました。そこでは、私たちが、そうするのが相互運用性に感染しないと信じています。

8.1  To Be HTTP, or Not To Be

8.1、HTTPであるかHTTPでない

   ICAP was initially designed as an application-layer protocol built to
   run on top of HTTP.  This was desirable for a number of reasons.
   HTTP is well-understood in the community and has enjoyed significant
   investments in software infrastructure (clients, servers, parsers,
   etc.).  Our initial designs focused on leveraging that existing work;
   we hoped that it would be possible to implement ICAP services simply,
   using CGI scripts run by existing web servers.

ICAPは初めは、HTTPの上で稼働するために築き上げられた応用層プロトコルとして設計されました。 これは様々な意味で望ましかったです。 HTTPは、共同体でよく理解されていて、ソフトインフラ(クライアント、サーバ、パーサなど)で重要な投資を持っていました。 私たちのその存在を利用するのに集中している初期のデザインは働いています。 既存のウェブサーバーによって実行されたCGIスクリプトを使用して、単にICAPにサービスを実装するのが可能であることを願っていました。

   However, the devil (as always) proved to be in the details.  Certain
   features that we considered important were impossible to implement
   with HTTP.  For example, ICAP clients can stop and wait for a "100
   Continue" message in the midst of a message-body; HTTP clients may
   only wait between the header and body.  In addition, certain
   transformations of HTTP messages by surrogates are legal (and
   harmless for HTTP), but caused problems with ICAP's "header-in-
   header" encapsulation and other features.

しかしながら、悪魔は、(いつものように)詳細にいると判明しました。 私たちが重要であると考えたある特徴はHTTPで実装するのが不可能でした。 例えば、ICAPクライアントは、メッセージ本体の中で「100は続く」というメッセージを止めて、待つことができます。 HTTPクライアントはヘッダーとボディーの間で待つだけであるかもしれません。 代理によるHTTPメッセージのある変換はさらに、法的、そして、(HTTPに無害)であり、ICAPのものに関する問題を引き起こされる、「」 カプセル化ともう一方が特集する中のヘッダーヘッダー。

   Ultimately, we decided that the tangle of workarounds required to fit
   ICAP into HTTP was more complex and confusing than moving away from
   HTTP and defining a new (but similar) protocol.

結局、私たちは、HTTPにICAPに合うのに必要である回避策のもつれがHTTPから遠くに移行して、新しくて(同様)のプロトコルを定義するより複雑であって、紛らわしいと決めました。

8.2  Mandatory Use of Chunking

8.2 分魂化の義務的な使用

   Chunking is mandatory in ICAP encapsulated bodies for three reasons.
   First, efficiency is important, and the chunked encoding allows both
   the client and server to keep the transport-layer connection open for
   later reuse.  Second, ICAP servers (and their developers) should be
   encouraged to produce "incremental" responses where possible, to
   reduce the latency perceived by users.  Chunked encoding is the only
   way to support this type of implementation.  Finally, by

分魂化はボディーであるとカプセル化されたICAPで3つの理由に義務的です。 まず最初に、効率は重要です、そして、chunkedコード化は後の再利用において開くようにトランスポート層接続を保つためにクライアントとサーバを両方に許容します。 2番目に、ICAPサーバ(そして、彼らの開発者)は、「増加」の応答を可能であるところに起こして、ユーザによって知覚されたレイテンシを減少させるよう奨励されるべきです。 Chunkedコード化はこのタイプの実装をサポートする唯一の方法です。 by

Elson & Cerpa                Informational                     [Page 39]

RFC 3507                          ICAP                        April 2003

[39ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   standardizing on a single encapsulation mechanism, we avoid the
   complexity that would be required in client and server software to
   support multiple mechanisms.  This simplifies ICAP, particularly in
   the "body preview" feature described in Section 4.5.

ただ一つのカプセル化メカニズムの上の標準化、私たちは複数のメカニズムをサポートするのにクライアントとサーバソフトウェアで必要である複雑さを避けます。これはICAPを簡素化します、特にセクション4.5で説明された「ボディープレビュー」の特徴で。

   While chunking of encapsulated bodies is mandatory, encapsulated
   headers are not chunked.  There are two reasons for this decision.
   First, in cases where a chunked HTTP message body is being
   encapsulated in an ICAP message, the ICAP client (HTTP server) can
   copy it directly from the HTTP client to the ICAP server without un-
   chunking and then re-chunking it.  Second, many header-parser
   implementations have difficulty dealing with headers that come in
   multiple chunks.  Earlier drafts of this document mandated that a
   chunk boundary not come within a header.  For clarity, chunking of
   encapsulated headers has simply been disallowed.

カプセル化されたボディーの分魂化が義務的である間、カプセル化されたヘッダーはchunkedされません。 この決定の2つの理由があります。 最初に、chunked HTTPメッセージ本体がICAPメッセージでカプセル化されている場合では、ICAPクライアント(HTTPサーバ)は不-分魂化と次に、再分魂化なしでそれを直接HTTPクライアントからICAPサーバまでコピーできます。それ。 2番目に、多くのヘッダーパーサ実装が複数の塊に入るヘッダーに対処するのに苦労します。 この草稿は、前に塊境界がヘッダーに含まれないのを強制したと記録します。 明快において、カプセル化されたヘッダーの分魂化は単に禁じられました。

8.3  Use of the null-body directive in the Encapsulated header

8.3 Encapsulatedヘッダーにおけるヌルボディー指示の使用

   There is a disadvantage to not using the chunked transfer-encoding
   for encapsulated header part of an ICAP message.  Specifically,
   parsers do not know in advance how much header data is coming (e.g.,
   for buffer allocation).  ICAP does not allow chunking in the header
   part for reasons described in Section 8.2.  To compensate, the
   "null-body" directive allows the final header's length to be
   determined, despite it not being chunked.

ICAPメッセージのカプセル化されたヘッダー部分にchunked転送コード化を使用しないことへの難点があります。 明確に、パーサは、あらかじめ、どのくらいのヘッダー・データが来るかを(例えば、バッファ配分のために)知りません。 ICAPはセクション8.2で説明された理由によるヘッダー部分に分魂化を許容しません。 代償するために、「ヌルボディー」指示は、それにもかかわらず、chunkedされないで、最終的なヘッダーの長さが決定しているのを許容します。

9.  References

9. 参照

   [1]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
        August 1998.

[1]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文と意味論」、RFC2396、8月1998日

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [3]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[3] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。

   [4]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

[4] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。

   [5]  Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
        RFC 2817, May 2000.

「HTTP/1.1インチ、RFC2817、2000年5月中にTLSにアップグレードする」[5]Khare、R.、およびS.ローレンス。

Elson & Cerpa                Informational                     [Page 40]

RFC 3507                          ICAP                        April 2003

[40ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

10.  Contributors

10. 貢献者

   ICAP is based on an original idea by John Martin and Peter Danzig.
   Many individuals and organizations have contributed to the
   development of ICAP, including the following contributors (past and
   present):

ジョン・マーチンとピーター・ダンツィグのICAPは着想に基づいています。 多くの個人と組織は以下の貢献者(過去の、そして、現在の)を含むICAPの開発に貢献しました:

   Lee Duggs
   Network Appliance, Inc.
   495 East Java Dr.
   Sunnyvale, CA 94089 USA

リーDuggsネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)

   Phone: (408) 822-6000
   EMail: lee.duggs@netapp.com

以下に電話をしてください。 (408) 822-6000 メールしてください: lee.duggs@netapp.com

   Paul Eastham
   Network Appliance, Inc.
   495 East Java Dr.
   Sunnyvale, CA 94089 USA

ポールEasthamネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)

   Phone: (408) 822-6000
   EMail: eastham@netapp.com

以下に電話をしてください。 (408) 822-6000 メールしてください: eastham@netapp.com

   Debbie Futcher
   Network Appliance, Inc.
   495 East Java Dr.
   Sunnyvale, CA 94089 USA

デビーFutcherネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)

   Phone: (408) 822-6000
   EMail: deborah.futcher@netapp.com

以下に電話をしてください。 (408) 822-6000 メールしてください: deborah.futcher@netapp.com

   Don Gillies
   Network Appliance, Inc.
   495 East Java Dr.
   Sunnyvale, CA 94089 USA

ドン従者ネットアプライアンスのInc.495の東Javaサニーベルカリフォルニア94089博士(米国)

   Phone: (408) 822-6000
   EMail: gillies@netapp.com

以下に電話をしてください。 (408) 822-6000 メールしてください: gillies@netapp.com

   Steven La
   Network Appliance, Inc.
   495 East Java Dr.
   Sunnyvale, CA 94089 USA

スティーブンLaネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)

   Phone: (408) 822-6000
   EMail: steven.la@netapp.com

以下に電話をしてください。 (408) 822-6000 メールしてください: steven.la@netapp.com

Elson & Cerpa                Informational                     [Page 41]

RFC 3507                          ICAP                        April 2003

[41ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   John Martin
   Network Appliance, Inc.
   495 East Java Dr.
   Sunnyvale, CA 94089 USA

ジョンマーチンネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)

   Phone: (408) 822-6000
   EMail: jmartin@netapp.com

以下に電話をしてください。 (408) 822-6000 メールしてください: jmartin@netapp.com

   Jeff Merrick
   Network Appliance, Inc.
   495 East Java Dr.
   Sunnyvale, CA 94089 USA

ジェフメリックネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)

   Phone: (408) 822-6000
   EMail: jeffrey.merrick@netapp.com

以下に電話をしてください。 (408) 822-6000 メールしてください: jeffrey.merrick@netapp.com

   John Schuster
   Network Appliance, Inc.
   495 East Java Dr.
   Sunnyvale, CA 94089 USA

ジョンシュスターネットアプライアンスInc.495の東Javaサニーベルカリフォルニア94089博士(米国)

   Phone: (408) 822-6000
   EMail: john.schuster@netapp.com

以下に電話をしてください。 (408) 822-6000 メールしてください: john.schuster@netapp.com

   Edward Sharp
   Network Appliance, Inc.
   495 East Java Dr.
   Sunnyvale, CA 94089 USA

サニーベル博士、鋭いネットアプライアンスInc.495の東Javaカリフォルニア94089米国のエドワード

   Phone: (408) 822-6000
   EMail: edward.sharp@netapp.com

以下に電話をしてください。 (408) 822-6000 メールしてください: edward.sharp@netapp.com

   Peter Danzig
   Akamai Technologies
   1400 Fashion Island Blvd
   San Mateo, CA 94404 USA

ピーターダンツィグアカマイ・テクノロジーズ1400ファッション島のBlvdカリフォルニア94404サン・マテオ(米国)

   Phone: (650) 372-5757
   EMail: danzig@akamai.com

以下に電話をしてください。 (650) 372-5757 メールしてください: danzig@akamai.com

   Mark Nottingham
   Akamai Technologies
   1400 Fashion Island Blvd
   San Mateo, CA 94404 USA

マークノッティンガムアカマイ・テクノロジーズ1400ファッション島のBlvdカリフォルニア94404サン・マテオ(米国)

   Phone: (650) 372-5757
   EMail: mnot@akamai.com

以下に電話をしてください。 (650) 372-5757 メールしてください: mnot@akamai.com

Elson & Cerpa                Informational                     [Page 42]

RFC 3507                          ICAP                        April 2003

[42ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   Nitin Sharma
   Akamai Technologies
   1400 Fashion Island Blvd
   San Mateo, CA 94404 USA

Nitinシャルマアカマイ・テクノロジーズ1400ファッション島のBlvdカリフォルニア94404サン・マテオ(米国)

   Phone: (650) 372-5757
   EMail: nitin@akamai.com

以下に電話をしてください。 (650) 372-5757 メールしてください: nitin@akamai.com

   Hilarie Orman
   Novell, Inc.
   122 East 1700 South
   Provo, UT 84606 USA

東1700の南ユタ84606Hilarie OrmanノベルInc.122プロボ(米国)

   Phone: (801) 861-7021
   EMail: horman@novell.com

以下に電話をしてください。 (801) 861-7021 メールしてください: horman@novell.com

   Craig Blitz
   Novell, Inc.
   122 East 1700 South
   Provo, UT 84606 USA

東1700の南ユタ84606クレイグ電撃ノベルInc.122プロボ(米国)

   Phone: (801) 861-7021
   EMail: cblitz@novell.com

以下に電話をしてください。 (801) 861-7021 メールしてください: cblitz@novell.com

   Gary Tomlinson
   Novell, Inc.
   122 East 1700 South
   Provo, UT 84606 USA

東1700の南ユタ84606ゲーリートムリンスンノベルInc.122プロボ(米国)

   Phone: (801) 861-7021
   EMail: garyt@novell.com

以下に電話をしてください。 (801) 861-7021 メールしてください: garyt@novell.com

   Andre Beck
   Bell Laboratories / Lucent Technologies
   101 Crawfords Corner Road
   Holmdel, New Jersey 07733-3030

Crawfordsコーナー道路Holmdel、アンドレべックベル研究所/ルーセントテクノロジーズ101ニュージャージー07733-3030

   Phone: (732) 332-5983
   EMail: abeck@bell-labs.com

以下に電話をしてください。 (732) 332-5983 メールしてください: abeck@bell-labs.com

   Markus Hofmann
   Bell Laboratories / Lucent Technologies
   101 Crawfords Corner Road
   Holmdel, New Jersey 07733-3030

Crawfordsコーナー道路Holmdel、マーカスホフマンベル研究所/ルーセントテクノロジーズ101ニュージャージー07733-3030

   Phone: (732) 332-5983
   EMail: hofmann@bell-labs.com

以下に電話をしてください。 (732) 332-5983 メールしてください: hofmann@bell-labs.com

Elson & Cerpa                Informational                     [Page 43]

RFC 3507                          ICAP                        April 2003

[43ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

   David Bryant
   CacheFlow, Inc.
   650 Almanor Avenue
   Sunnyvale, California 94086

デヴィッドブライアントCacheFlow Inc.650Almanor Avenueサニーベル、カリフォルニア 94086

   Phone: (888) 462-3568
   EMail: david.bryant@cacheflow.com

以下に電話をしてください。 (888) 462-3568 メールしてください: david.bryant@cacheflow.com

Elson & Cerpa                Informational                     [Page 44]

RFC 3507                          ICAP                        April 2003

[44ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

Appendix A   BNF Grammar for ICAP Messages

付録はICAPメッセージのためのBNF文法です。

   This grammar is specified in terms of the augmented Backus-Naur Form
   (BNF) similar to that used by the HTTP/1.1 specification (See Section
   2.1 of [4]).  Implementors will need to be familiar with the notation
   in order to understand this specification.

HTTP/1.1仕様で使用されるそれと同様の増大しているBN記法(BNF)でこの文法は指定されます。([4])のセクション2.1を見てください。 作成者は、この仕様を理解するために記法によく知られる必要があるでしょう。

   Many header values (where noted) have exactly the same grammar and
   semantics as in HTTP/1.1.  We do not reproduce those grammars here.

多くのヘッダー値(有名であるところ)には、まさに同じ文法と意味論がHTTP/1.1のようにあります。 私たちはここでそれらの文法を再生させません。

   ICAP-Version = "ICAP/1.0"

ICAP-バージョン=「ICAP/1インチ」

   ICAP-Message = Request | Response

ICAP-メッセージ=要求| 応答

   Request      = Request-Line
                  *(Request-Header CRLF)
                  CRLF
                  [ Request-Body ]

=要求線*(要求ヘッダーCRLF)CRLFを要求してください。[要求本体]

   Request-Line = Method SP ICAP_URI SP ICAP-Version CRLF

メソッドSP ICAP_ユリSP ICAP-バージョン要求線=CRLF

   Method       = "REQMOD"         ; Section 4.8
                | "RESPMOD"        ; Section 4.9
                | "OPTIONS"        ; Section 4.10
                | Extension-Method ; Section 4.3.2

メソッドは"REQMOD"と等しいです。 セクション4.8| "RESPMOD"。 セクション4.9| 「オプション」。 セクション4.10| 拡大メソッド。 セクション4.3 .2

   Extension-Method = token

拡大メソッドはトークンと等しいです。

   ICAP_URI = Scheme ":" Net_Path [ "?" Query ]  ; Section 4.2

「ICAP_URI=体系」:、」 ネットの_経路[“?"質問]。 セクション4.2

   Scheme      = "icap"

体系="icap"

   Net_Path    = "//" Authority [ Abs_Path ]

「ネット_経路は」 //と等しい」という権威[腹筋_経路]

   Authority   = [ userinfo "@" ] host [ ":" port ]

権威=[userinfo"@"]ホスト[「:」 ポート]

   Request-Header     = Request-Fields ":" [ Generic-Field-Value ]

「要求ヘッダー=要求分野」:、」 [ジェネリック分野価値]

   Request-Fields     = Request-Field-Name
                      | Common-Field-Name

要求分野は要求フィールド名と等しいです。| 一般的なフィールド名

   ; Header fields specific to requests
   Request-Field-Name = "Authorization"   ; Section 4.3.2
                      | "Allow"           ; Section 4.3.2
                      | "From"            ; Section 4.3.2
                      | "Host"            ; Section 4.3.2
                      | "Referer"         ; Section 4.3.2

; 要求Request分野名に特定のヘッダーフィールドは「承認」と等しいです。 セクション4.3 .2| 「許容します」。 セクション4.3 .2| "From"。 セクション4.3 .2| 「ホスト」。 セクション4.3 .2| "Referer"。 セクション4.3 .2

Elson & Cerpa                Informational                     [Page 45]

RFC 3507                          ICAP                        April 2003

[45ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

                      | "User-Agent"      ; Section 4.3.2
                      | "Preview"         ; Section 4.5

| 「ユーザエージェント」。 セクション4.3 .2| 「プレビュー」。 セクション4.5

   ; Header fields common to both requests and responses
   Common-Field-Name  = "Cache-Control"   ; Section 4.3.1
                      | "Connection"      ; Section 4.3.1
                      | "Date"            ; Section 4.3.1
                      | "Expires"         ; Section 4.3.1
                      | "Pragma"          ; Section 4.3.1
                      | "Trailer"         ; Section 4.3.1
                      | "Upgrade"         ; Section 4.3.1
                      | "Encapsulated"    ; Section 4.4
                      | Extension-Field-Name   ; Section 4.3

; 要求と応答の両方に共通のヘッダーフィールドCommon分野名は「キャッシュ制御」と等しいです。 セクション4.3 .1| 「接続」。 セクション4.3 .1| 「デートしてください」。 セクション4.3 .1| 「期限が切れます」。 セクション4.3 .1| "Pragma"。 セクション4.3 .1| 「トレーラ」。 セクション4.3 .1| 「アップグレードしてください」。 セクション4.3 .1| 「要約します」。 セクション4.4| 拡大フィールド名。 セクション4.3

   Extension-Field-Name  = "X-" token

拡大分野名は「X」トークンと等しいです。

   Generic-Field-Value   = *( Generic-Field-Content | LWS )
   Generic-Field-Content = <the OCTETs making up the field-value
                            and consisting of either *TEXT or
                            combinations of token, separators,
                            and quoted-string>

ジェネリック分野価値は分野値を作って、トークン、分離符、および引用文字列>の*TEXTか組み合わせのどちらかから成る*(ジェネリック分野内容| LWS)ジェネリック分野内容=<OCTETsと等しいです。

   Request-Body = *OCTET   ; See Sections 4.4 and 4.5 for semantics

要求本体は*八重奏と等しいです。 意味論に関してセクション4.4と4.5を見てください。

   Response    = Status-Line
                 *(Response-Header CRLF)
                 CRLF
                 [ Response-Body ]

応答=状況表示行*(応答ヘッダCRLF)のCRLF[応答本体]

   Status-Line = ICAP-Version SP Status-Code SP Reason-Phrase CRLF

状況表示行=ICAP-バージョンSPステータスコードSP理由句のCRLF

   Status-Code = "100"  ; Section 4.5
               | "101"  ; Section 10.1.2 of [4]
               | "200"  ; Section 10.2.1 of [4]
               | "201"  ; Section 10.2.2 of [4]
               | "202"  ; Section 10.2.3 of [4]
               | "203"  ; Section 10.2.4 of [4]
               | "204"  ; Section 4.6
               | "205"  ; Section 10.2.6 of [4]
               | "206"  ; Section 10.2.7 of [4]
               | "300"  ; Section 10.3.1 of [4]
               | "301"  ; Section 10.3.2 of [4]
               | "302"  ; Section 10.3.3 of [4]
               | "303"  ; Section 10.3.4 of [4]
               | "304"  ; Section 10.3.5 of [4]
               | "305"  ; Section 10.3.6 of [4]
               | "306"  ; Section 10.3.7 of [4]
               | "307"  ; Section 10.3.8 of [4]

ステータスコード=「100」。 セクション4.5| "101" ; [4]について10.1に.2を区分してください。| "200" ; [4]について10.2に.1を区分してください。| "201" ; [4]について10.2に.2を区分してください。| "202" ; [4]について10.2に.3を区分してください。| "203" ; [4]について10.2に.4を区分してください。| "204" ; セクション4.6| "205" ; [4]について10.2に.6を区分してください。| "206" ; [4]について10.2に.7を区分してください。| "300" ; [4]について10.3に.1を区分してください。| "301" ; [4]について10.3に.2を区分してください。| "302" ; [4]について10.3に.3を区分してください。| "303" ; [4]について10.3に.4を区分してください。| "304" ; [4]について10.3に.5を区分してください。| "305" ; [4]について10.3に.6を区分してください。| "306" ; [4]について10.3に.7を区分してください。| "307" ; セクション10.3.8[4]

Elson & Cerpa                Informational                     [Page 46]

RFC 3507                          ICAP                        April 2003

[46ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

               | "400"  ; Section 4.3.3
               | "401"  ; Section 10.4.2 of [4]
               | "402"  ; Section 10.4.3 of [4]
               | "403"  ; Section 10.4.4 of [4]
               | "404"  ; Section 4.3.3
               | "405"  ; Section 4.3.3
               | "406"  ; Section 10.4.7 of [4]
               | "407"  ; Section 10.4.8 of [4]
               | "408"  ; Section 4.3.3
               | "409"  ; Section 10.4.10 of [4]
               | "410"  ; Section 10.4.11 of [4]
               | "411"  ; Section 10.4.12 of [4]
               | "412"  ; Section 10.4.13 of [4]
               | "413"  ; Section 10.4.14 of [4]
               | "414"  ; Section 10.4.15 of [4]
               | "415"  ; Section 10.4.16 of [4]
               | "416"  ; Section 10.4.17 of [4]
               | "417"  ; Section 10.4.18 of [4]
               | "500"  ; Section 4.3.3
               | "501"  ; Section 4.3.3
               | "502"  ; Section 4.3.3
               | "503"  ; Section 4.3.3
               | "504"  ; Section 10.5.5 of [4]
               | "505"  ; Section 4.3.3
               | Extension-Code

| "400" ; セクション4.3 .3| "401" ; [4]について10.4に.2を区分してください。| "402" ; [4]について10.4に.3を区分してください。| "403" ; [4]について10.4に.4を区分してください。| "404" ; セクション4.3 .3| "405" ; セクション4.3 .3| "406" ; [4]について10.4に.7を区分してください。| "407" ; [4]について10.4に.8を区分してください。| "408" ; セクション4.3 .3| "409" ; [4]について10.4に.10を区分してください。| "410" ; [4]について10.4に.11を区分してください。| "411" ; [4]について10.4に.12を区分してください。| "412" ; [4]について10.4に.13を区分してください。| "413" ; [4]について10.4に.14を区分してください。| "414" ; [4]について10.4に.15を区分してください。| "415" ; [4]について10.4に.16を区分してください。| "416" ; [4]について10.4に.17を区分してください。| "417" ; [4]について10.4に.18を区分してください。| "500" ; セクション4.3 .3| "501" ; セクション4.3 .3| "502" ; セクション4.3 .3| "503" ; セクション4.3 .3| "504" ; [4]について10.5に.5を区分してください。| "505" ; セクション4.3 .3| 拡張コード

   Extension-Code = 3DIGIT

拡張コード=3DIGIT

   Reason-Phrase = *<TEXT, excluding CR, LF>

CR、LF>を除いた理由句の=*<TEXT

   Response-Header     = Response-Fields ":" [ Generic-Field-Value ]

「応答ヘッダは応答分野と等しい」:、」 [ジェネリック分野価値]

   Response-Fields     = Response-Field-Name
                       | Common-Field-Name

応答分野は応答フィールド名と等しいです。| 一般的なフィールド名

   Response-Field-Name = "Server"         ; Section 4.3.3
                       | "ISTag"          ; Section 4.7

応答フィールド名は「サーバ」と等しいです。 セクション4.3 .3| "ISTag"。 セクション4.7

   Response-Body = *OCTET  ; See Sections 4.4 and 4.5 for semantics

応答本体は*八重奏と等しいです。 意味論に関してセクション4.4と4.5を見てください。

Elson & Cerpa                Informational                     [Page 47]

RFC 3507                          ICAP                        April 2003

[47ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

Authors' Addresses

作者のアドレス

   Jeremy Elson
   University of California Los Angeles
   Department of Computer Science
   3440 Boelter Hall
   Los Angeles CA 90095

コンピュータサイエンス3440Boelterホールロサンゼルスカリフォルニア 90095人のジェレミーエルソンカリフォルニア大学ロサンゼルス校部

   Phone: (310) 206-3925
   EMail: jelson@cs.ucla.edu

以下に電話をしてください。 (310) 206-3925 メールしてください: jelson@cs.ucla.edu

   Alberto Cerpa
   University of California Los Angeles
   Department of Computer Science
   3440 Boelter Hall
   Los Angeles CA 90095

コンピュータサイエンス3440Boelterホールロサンゼルスカリフォルニア 90095人のアルベルトCerpaカリフォルニア大学ロサンゼルス校部

   Phone: (310) 206-3925
   EMail: cerpa@cs.ucla.edu

以下に電話をしてください。 (310) 206-3925 メールしてください: cerpa@cs.ucla.edu

   ICAP discussion currently takes place at
           icap-discussions@yahoogroups.com.
   For more information, see
           http://groups.yahoo.com/group/icap-discussions/.

ICAP議論は現在、 icap-discussions@yahoogroups.com で行われます。 詳しくは、 http://groups.yahoo.com/group/icap-discussions/ を見てください。

Elson & Cerpa                Informational                     [Page 48]

RFC 3507                          ICAP                        April 2003

[48ページ]RFC3507ICAP2003年4月の情報のエルソンとCerpa

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Elson & Cerpa                Informational                     [Page 49]

エルソンとCerpa情報です。[49ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

svnコマンドのまとめ

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る