Network Working Group J. Elson
Request for Comments: 3507 A. Cerpa
Category: Informational UCLA
April 2003
Network Working Group J. Elson
Request for Comments: 3507 A. Cerpa
Category: Informational UCLA
April 2003
Internet Content Adaptation Protocol (ICAP)
互联网内容适配协议（ICAP）
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
IESG Note
IESG注释
The Open Pluggable Services (OPES) working group has been chartered to produce a standards track protocol specification for a protocol intended to perform the same of functions as ICAP. However, since ICAP is already in widespread use the IESG believes it is appropriate to document existing usage by publishing the ICAP specification as an informational document. The IESG also notes that ICAP was developed before the publication of RFC 3238 and therefore does not address the architectural and policy issues described in that document.
OpenPluggableServices（OPES）工作组被授权为一个协议制定一个标准跟踪协议规范，该协议旨在执行与ICAP相同的功能。然而，由于ICAP已经被广泛使用，IESG认为通过将ICAP规范作为信息性文件发布来记录现有使用情况是合适的。IESG还注意到，ICAP是在RFC 3238发布之前制定的，因此没有解决该文件中描述的架构和政策问题。
Abstract
摘要
ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services. ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. It allows ICAP clients to pass HTTP messages to ICAP servers for some sort of transformation or other processing ("adaptation"). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. Typically, the adapted messages are either HTTP requests or HTTP responses.
互联网内容适配协议ICAP是一种旨在为HTTP服务提供简单的基于对象的内容矢量化的协议。本质上，ICAP是一种轻量级协议，用于对HTTP消息执行“远程过程调用”。它允许ICAP客户端将HTTP消息传递给ICAP服务器，以进行某种转换或其他处理（“自适应”）。服务器对消息执行其转换服务，并向客户机发回响应，通常是修改消息。通常，调整后的消息是HTTP请求或HTTP响应。
Table of Contents
目录
1. Introduction............................................3
2. Terminology.............................................5
3. ICAP Overall Operation..................................8
3.1 Request Modification..............................8
3.2 Response Modification............................10
4. Protocol Semantics.....................................11
4.1 General Operation................................11
4.2 ICAP URIs........................................11
4.3 ICAP Headers.....................................12
4.3.1 Headers Common to Requests and
Responses................................12
4.3.2 Request Headers..........................13
4.3.3 Response Headers.........................14
4.3.4 ICAP-Related Headers in HTTP
Messages.................................15
4.4 ICAP Bodies: Encapsulation of HTTP
Messages.........................................16
4.4.1 Expected Encapsulated Sections...........16
4.4.2 Encapsulated HTTP Headers................18
4.5 Message Preview..................................18
4.6 "204 No Content" Responses outside of
Previews.........................................22
4.7 ISTag Response Header............................22
4.8 Request Modification Mode........................23
4.8.1 Request..................................23
4.8.2 Response.................................24
4.8.3 Examples.................................24
4.9 Response Modification Mode.......................27
4.9.1 Request..................................27
4.9.2 Response.................................27
4.9.3 Examples.................................28
4.10 OPTIONS Method...................................29
4.10.1 OPTIONS request..........................29
4.10.2 OPTIONS response.........................30
4.10.3 OPTIONS examples.........................33
5. Caching................................................33
6. Implementation Notes...................................34
6.1 Vectoring Points.................................34
6.2 Application Level Errors.........................35
6.3 Use of Chunked Transfer-Encoding.................37
6.4 Distinct URIs for Distinct Services..............37
7. Security Considerations................................37
7.1 Authentication...................................37
7.2 Encryption.......................................38
7.3 Service Validation...............................38
8. Motivations and Design Alternatives....................39
1. Introduction............................................3
2. Terminology.............................................5
3. ICAP Overall Operation..................................8
3.1 Request Modification..............................8
3.2 Response Modification............................10
4. Protocol Semantics.....................................11
4.1 General Operation................................11
4.2 ICAP URIs........................................11
4.3 ICAP Headers.....................................12
4.3.1 Headers Common to Requests and
Responses................................12
4.3.2 Request Headers..........................13
4.3.3 Response Headers.........................14
4.3.4 ICAP-Related Headers in HTTP
Messages.................................15
4.4 ICAP Bodies: Encapsulation of HTTP
Messages.........................................16
4.4.1 Expected Encapsulated Sections...........16
4.4.2 Encapsulated HTTP Headers................18
4.5 Message Preview..................................18
4.6 "204 No Content" Responses outside of
Previews.........................................22
4.7 ISTag Response Header............................22
4.8 Request Modification Mode........................23
4.8.1 Request..................................23
4.8.2 Response.................................24
4.8.3 Examples.................................24
4.9 Response Modification Mode.......................27
4.9.1 Request..................................27
4.9.2 Response.................................27
4.9.3 Examples.................................28
4.10 OPTIONS Method...................................29
4.10.1 OPTIONS request..........................29
4.10.2 OPTIONS response.........................30
4.10.3 OPTIONS examples.........................33
5. Caching................................................33
6. Implementation Notes...................................34
6.1 Vectoring Points.................................34
6.2 Application Level Errors.........................35
6.3 Use of Chunked Transfer-Encoding.................37
6.4 Distinct URIs for Distinct Services..............37
7. Security Considerations................................37
7.1 Authentication...................................37
7.2 Encryption.......................................38
7.3 Service Validation...............................38
8. Motivations and Design Alternatives....................39
8.1 To Be HTTP, or Not to Be.........................39
8.2 Mandatory Use of Chunking........................39
8.3 Use of the null-body directive in the
Encapsulated header..............................40
9. References.............................................40
10. Contributors...........................................41
Appendix A BNF Grammar for ICAP Messages..................45
Authors' Addresses..........................................48
Full Copyright Statement....................................49
8.1 To Be HTTP, or Not to Be.........................39
8.2 Mandatory Use of Chunking........................39
8.3 Use of the null-body directive in the
Encapsulated header..............................40
9. References.............................................40
10. Contributors...........................................41
Appendix A BNF Grammar for ICAP Messages..................45
Authors' Addresses..........................................48
Full Copyright Statement....................................49
As the Internet grows, so does the need for scalable Internet services. Popular web servers are asked to deliver content to hundreds of millions of users connected at ever-increasing bandwidths. The model of centralized, monolithic servers that are responsible for all aspects of every client's request seems to be reaching the end of its useful life.
随着互联网的发展，对可扩展互联网服务的需求也在增长。流行的web服务器被要求向以不断增加的带宽连接的数亿用户交付内容。负责每个客户机请求的所有方面的集中式单片服务器的模型似乎已经到了其使用寿命的尽头。
To keep up with the growth in the number of clients, there has been a move towards architectures that scale better through the use of replication, distribution, and caching. On the content provider side, replication and load-balancing techniques allow the burden of client requests to be spread out over a myriad of servers. Content providers have also begun to deploy geographically diverse content distribution networks that bring origin-servers closer to the "edge" of the network where clients are attached. These networks of distributed origin-servers or "surrogates" allow the content provider to distribute their content whilst retaining control over the integrity of that content. The distributed nature of this type of deployment and the proximity of a given surrogate to the end-user enables the content provider to offer additional services to a user which might be based, for example, on geography where this would have been difficult with a single, centralized service.
为了跟上客户机数量的增长，已经有了一种通过使用复制、分发和缓存实现更好扩展的体系结构。在内容提供商方面，复制和负载平衡技术允许将客户端请求的负担分散到无数服务器上。内容提供商还开始部署地理位置不同的内容分发网络，使源服务器更靠近连接客户端的网络的“边缘”。这些分布式源服务器或“代理”网络允许内容提供商分发其内容，同时保留对该内容完整性的控制。此类部署的分布式性质以及给定代理与最终用户的接近性使得内容提供商能够向用户提供额外的服务，这些服务可能基于（例如）地理位置，而在地理位置上，使用单一的集中式服务很难做到这一点。
ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services. ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. It allows ICAP clients to pass HTTP messages to ICAP servers for some sort of transformation or other processing ("adaptation"). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. The adapted messages may be either HTTP requests or HTTP responses. Though transformations may be possible on other non-HTTP content, they are beyond the scope of this document.
互联网内容适配协议ICAP是一种旨在为HTTP服务提供简单的基于对象的内容矢量化的协议。本质上，ICAP是一种轻量级协议，用于对HTTP消息执行“远程过程调用”。它允许ICAP客户端将HTTP消息传递给ICAP服务器，以进行某种转换或其他处理（“自适应”）。服务器对消息执行其转换服务，并向客户机发回响应，通常是修改消息。适应的消息可以是HTTP请求或HTTP响应。虽然可以在其他非HTTP内容上进行转换，但它们超出了本文档的范围。
This type of Remote Procedure Call (RPC) is useful in a number of ways. For example:
这种类型的远程过程调用（RPC）在许多方面都很有用。例如：
o Simple transformations of content can be performed near the edge of the network instead of requiring an updated copy of an object from an origin server. For example, a content provider might want to provide a popular web page with a different advertisement every time the page is viewed. Currently, content providers implement this policy by marking such pages as non-cachable and tracking user cookies. This imposes additional load on the origin server and the network. In our architecture, the page could be cached once near the edges of the network. These edge caches can then use an ICAP call to a nearby ad-insertion server every time the page is served to a client.
o 可以在网络边缘附近执行内容的简单转换，而无需从源服务器获得对象的更新副本。例如，内容提供商可能希望在每次查看某个流行网页时为该网页提供不同的广告。目前，内容提供商通过将此类页面标记为不可缓存并跟踪用户cookie来实施此策略。这会给源服务器和网络带来额外的负载。在我们的架构中，页面可以在网络边缘附近缓存一次。然后，每次将页面提供给客户端时，这些边缘缓存都可以使用对附近ad插入服务器的ICAP调用。
Other such transformations by edge servers are possible, either with cooperation from the content provider (as in a content distribution network), or as a value-added service provided by a client's network provider (as in a surrogate). Examples of these kinds of transformations are translation of web pages to different human languages or to different formats that are appropriate for special physical devices (e.g., PDA-based or cell-phone-based browsers).
边缘服务器的其他此类转换是可能的，可以与内容提供商合作（如在内容分发网络中），也可以作为客户的网络提供商提供的增值服务（如在代理服务器中）。此类转换的示例包括将网页翻译成不同的人类语言或适合于特殊物理设备（例如，基于PDA或基于手机的浏览器）的不同格式。
o Surrogates or origin servers can avoid performing expensive operations by shipping the work off to other servers instead. This helps distribute load across multiple machines. For example, consider a user attempting to download an executable program via a surrogate (e.g., a caching proxy). The surrogate, acting as an ICAP client, can ask an external server to check the executable for viruses before accepting it into its cache.
o 代理服务器或源服务器可以通过将工作转移到其他服务器来避免执行昂贵的操作。这有助于在多台机器之间分配负载。例如，考虑用户试图通过代理（例如缓存代理）下载可执行程序。代理服务器充当ICAP客户端，可以要求外部服务器在将可执行文件接收到缓存之前检查其是否存在病毒。
o Firewalls or surrogates can act as ICAP clients and send outgoing requests to a service that checks to make sure the URI in the request is allowed (for example, in a system that allows parental control of web content viewed by children). In this case, it is a *request* that is being adapted, not an object returned by a response.
o 防火墙或代理可以充当ICAP客户端，并向服务发送传出请求，该服务检查以确保请求中的URI是允许的（例如，在允许家长控制孩子查看的web内容的系统中）。在这种情况下，正在调整的是*请求*，而不是响应返回的对象。
In all of these examples, ICAP is helping to reduce or distribute the load on origin servers, surrogates, or the network itself. In some cases, ICAP facilitates transformations near the edge of the network, allowing greater cachability of the underlying content. In other examples, devices such as origin servers or surrogates are able to reduce their load by distributing expensive operations onto other machines. In all cases, ICAP has also created a standard interface for content adaptation to allow greater flexibility in content distribution or the addition of value added services in surrogates.
在所有这些示例中，ICAP都有助于减少或分配源服务器、代理服务器或网络本身的负载。在某些情况下，ICAP有助于在网络边缘附近进行转换，从而提高底层内容的可访问性。在其他示例中，诸如源服务器或代理服务器之类的设备能够通过将昂贵的操作分发到其他机器上来减少其负载。在所有情况下，ICAP还为内容改编创建了一个标准接口，以便在内容分发或在代理中添加增值服务方面具有更大的灵活性。
There are two major components in our architecture:
我们的体系结构中有两个主要组件：
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仅定义事务语义。例如，本文档指定如何将HTTP消息从ICAP客户端发送到ICAP服务器，指定请求的ICAP资源的URI以及其他特定于资源的参数，以及如何接收调整后的消息。
Although a necessary building-block, this wire-protocol defined by ICAP is of limited use without the second part: an accompanying application framework in which it operates. The more difficult policy issue is beyond the scope of the current ICAP protocol, but is planned in future work.
尽管这是一个必要的构建块，但ICAP定义的这个有线协议没有第二部分（它运行的附带应用程序框架）的使用是有限的。更困难的政策问题超出了当前ICAP协议的范围，但计划在未来的工作中解决。
In initial implementations, we expect that implementation-specific manual configuration will be used to define policy. This includes the rules for recognizing messages that require adaptation, the URIs of available adaptation resources, and so on. For ICAP clients and servers to interoperate, the exact method used to define policy need not be consistent across implementations, as long as the policy itself is consistent.
在初始实现中，我们希望使用特定于实现的手动配置来定义策略。这包括识别需要自适应的消息的规则、可用自适应资源的URI等。对于要进行互操作的ICAP客户端和服务器，只要策略本身是一致的，用于定义策略的确切方法就不需要在实现之间保持一致。
IMPORTANT: Note that at this time, in the absence of a policy-framework, it is strongly RECOMMENDED that transformations SHOULD only be performed on messages with the explicit consent of either the content-provider or the user (or both). Deployment of transformation services without the consent of either leads to, at best, unpredictable results. For more discussion of these issues, see Section 7.
重要提示：请注意，在目前没有策略框架的情况下，强烈建议仅在内容提供商或用户（或两者）明确同意的情况下对消息执行转换。未经任何一方同意部署转换服务最多只能导致不可预测的结果。有关这些问题的更多讨论，请参见第7节。
Once the full extent of the typical policy decisions are more fully understood through experience with these initial implementations, later follow-ons to this architecture may define an additional policy control protocol. This future protocol may allow a standard policy definition interface complementary to the ICAP transaction interface defined here.
一旦通过这些初始实现的经验更全面地理解了典型策略决策的全部内容，以后对该体系结构的后续操作可能会定义一个附加的策略控制协议。此未来协议可能允许标准策略定义接口，以补充此处定义的ICAP事务接口。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
The special terminology used in this document is defined below. The majority of these terms are taken as-is from HTTP/1.1 [4] and are reproduced here for reference. A thorough understanding of HTTP/1.1 is assumed on the part of the reader.
本文件中使用的特殊术语定义如下。这些术语中的大多数是从HTTP/1.1[4]中照搬过来的，并在此处复制以供参考。读者应该完全理解HTTP/1.1。
connection: A transport layer virtual circuit established between two programs for the purpose of communication.
连接：为通信目的在两个程序之间建立的传输层虚拟电路。
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通信的基本单元，由与HTTP/1.1[4]第4节中定义的语法相匹配的八位字节的结构化序列组成，并通过连接进行传输。
request: An HTTP request message, as defined in Section 5 of HTTP/1.1 [4].
请求：HTTP请求消息，如HTTP/1.1[4]第5节所定义。
response: An HTTP response message, as defined in Section 6 of HTTP/1.1 [4].
响应：HTTP响应消息，如HTTP/1.1[4]第6节所定义。
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.
资源：可以由URI标识的网络数据对象或服务，如HTTP/1.1[4]第3.2节所定义。资源可能有多种表示形式（例如，多种语言、数据格式、大小、分辨率）或以其他方式变化。
client: A program that establishes connections for the purpose of sending requests.
客户端：为发送请求而建立连接的程序。
server: An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, surrogate, gateway, or tunnel, switching behavior based on the nature of each request.
服务器：一个应用程序，它接受连接，以便通过发送回响应来服务请求。任何给定的程序都可以既是客户机又是服务器；我们对这些术语的使用仅指程序为特定连接执行的角色，而不是指程序的总体功能。同样，任何服务器都可以充当源服务器、代理服务器、网关或隧道，根据每个请求的性质进行切换。
origin server: The server on which a given resource resides or is to be created.
源服务器：给定资源所在或要创建的服务器。
proxy: An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification.
代理：一种中间程序，它既是服务器又是客户端，用于代表其他客户端发出请求。请求由内部提供服务，或者通过将请求传递到其他服务器（可能需要翻译）来提供服务。代理必须实现本规范的客户机和服务器要求。
cache: A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cachable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel.
缓存：一个程序的本地响应消息存储和控制其消息存储、检索和删除的子系统。缓存存储可缓存的响应，以减少未来等效请求的响应时间和网络带宽消耗。任何客户端或服务器都可能包含缓存，但缓存不能由充当隧道的服务器使用。
cachable: A response is cachable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cachability of HTTP responses are defined in Section 13 of [4]. Even if a resource is cachable, there may be additional constraints on whether a cache can use the cached copy for a particular request.
可缓存：如果允许缓存存储响应消息的副本以用于应答后续请求，则响应是可缓存的。[4]第13节定义了确定HTTP响应可访问性的规则。即使资源是可缓存的，缓存是否可以将缓存副本用于特定请求也可能存在其他限制。
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.
代理服务器：与源服务器位于同一位置的网关，或位于网络中的不同点，被授权代表一个或多个源服务器运行，通常与一个或多个源服务器密切合作。响应通常从内部缓存传递。代理可以从源服务器或源服务器的另一个代理派生缓存项。在某些情况下，代理可以通过隧道传输此类请求。
Where close co-operation between origin servers and surrogates exists, this enables modifications of some protocol requirements, including the Cache-Control directives in [4]. Such modifications have yet to be fully specified.
如果源服务器和代理服务器之间存在密切合作，则可以修改某些协议要求，包括[4]中的缓存控制指令。此类修改尚未完全明确。
Devices commonly known as "reverse proxies" and "(origin) server accelerators" are both more properly defined as surrogates.
通常被称为“反向代理”和“（原始）服务器加速器”的设备都更适合定义为代理。
New definitions:
新定义：
ICAP resource: Similar to an HTTP resource as described above, but the URI refers to an ICAP service that performs adaptations of HTTP messages.
ICAP资源：与上述HTTP资源类似，但URI指的是执行HTTP消息自适应的ICAP服务。
ICAP server: Similar to an HTTP server as described above, except that the application services ICAP requests.
ICAP服务器：与上述HTTP服务器类似，只是应用程序服务于ICAP请求。
ICAP client: A program that establishes connections to ICAP servers for the purpose of sending requests. An ICAP client is often, but not always, a surrogate acting on behalf of a user.
ICAP客户端：为发送请求而与ICAP服务器建立连接的程序。ICAP客户端通常（但不总是）是代表用户的代理。
Before describing ICAP's semantics in detail, we will first give a general overview of the protocol's major functions and expected uses. As described earlier, ICAP focuses on modification of HTTP requests (Section 3.1), and modification of HTTP responses (Section 3.2).
在详细描述ICAP的语义之前，我们将首先概述该协议的主要功能和预期用途。如前所述，ICAP侧重于修改HTTP请求（第3.1节）和修改HTTP响应（第3.2节）。
In "request modification" (reqmod) mode, an ICAP client sends an HTTP request to an ICAP server. The ICAP server may then:
在“请求修改”（reqmod）模式下，ICAP客户端向ICAP服务器发送HTTP请求。然后，ICAP服务器可以：
1) Send back a modified version of the request. The ICAP client may then perform the modified request by contacting an origin server; or, pipeline the modified request to another ICAP server for further modification.
1) 发回请求的修改版本。然后，ICAP客户端可以通过联系源服务器来执行修改后的请求；或者，将修改后的请求通过管道传输到另一个ICAP服务器进行进一步修改。
2) Send back an HTTP response to the request. This is used to provide information useful to the user in case of an error (e.g., "you sent a request to view a page you are not allowed to see").
2) 向请求发回HTTP响应。这用于在出现错误时向用户提供有用的信息（例如，“您发送了查看不允许查看的页面的请求”）。
3) Return an error.
3) 返回一个错误。
ICAP clients MUST be able to handle all three types of responses. However, in line with the guidance provided for HTTP surrogates in Section 13.8 of [4], ICAP client implementors do have flexibility in handling errors. If the ICAP server returns an error, the ICAP client may (for example) return the error to the user, execute the unadapted request as it arrived from the client, or re-try the adaptation again.
ICAP客户端必须能够处理所有三种类型的响应。然而，根据[4]第13.8节中为HTTP代理提供的指导，ICAP客户端实现者在处理错误方面具有灵活性。如果ICAP服务器返回错误，则ICAP客户端可能（例如）将错误返回给用户，在从客户端到达时执行未调整的请求，或者再次尝试调整。
We will illustrate this method with an example application: content filtering. Consider a surrogate that receives a request from a client for a web page on an origin server. The surrogate, acting as an ICAP client, sends the client's request to an ICAP server that performs URI-based content filtering. If access to the requested URI is allowed, the request is returned to the ICAP client unmodified. However, if the ICAP server chooses to disallow access to the requested resources, it may either:
我们将用一个示例应用程序来说明这种方法：内容过滤。考虑一个代理，该代理从客户端接收源服务器上Web页面的请求。代理服务器充当ICAP客户端，将客户端的请求发送到执行基于URI的内容过滤的ICAP服务器。如果允许访问请求的URI，则请求将不经修改地返回给ICAP客户端。但是，如果ICAP服务器选择不允许访问请求的资源，它可能会：
1) Modify the request so that it points to a page containing an error message instead of the original URI.
1) 修改请求，使其指向包含错误消息而不是原始URI的页面。
2) Return an encapsulated HTTP response that indicates an HTTP error.
2) 返回指示HTTP错误的封装HTTP响应。
This method can be used for a variety of other applications; for example, anonymization, modification of the Accept: headers to handle special device requirements, and so forth.
此方法可用于各种其他应用；例如，匿名化、修改Accept:header以处理特殊的设备需求，等等。
Typical data flow:
典型数据流：
origin-server
| /|\
| |
5 | | 4
| |
\|/ | 2
ICAP-client --------------> ICAP-resource
(surrogate) <-------------- on ICAP-server
| /|\ 3
| |
6 | | 1
| |
\|/ |
client
origin-server
| /|\
| |
5 | | 4
| |
\|/ | 2
ICAP-client --------------> ICAP-resource
(surrogate) <-------------- on ICAP-server
| /|\ 3
| |
6 | | 1
| |
\|/ |
client
1. A client makes a request to a ICAP-capable surrogate (ICAP client) for an object on an origin server.
1. 客户端向支持ICAP的代理服务器（ICAP客户端）请求源服务器上的对象。
2. The surrogate sends the request to the ICAP server.
2. 代理将请求发送到ICAP服务器。
3. The ICAP server executes the ICAP resource's service on the request and sends the possibly modified request, or a response to the request back to the ICAP client.
3. ICAP服务器对请求执行ICAP资源的服务，并将可能修改的请求或对请求的响应发送回ICAP客户端。
If Step 3 returned a request:
如果步骤3返回请求：
4. The surrogate sends the request, possibly different from original client request, to the origin server.
4. 代理将请求（可能与原始客户端请求不同）发送到源服务器。
5. The origin server responds to request.
5. 源服务器响应请求。
6. The surrogate sends the reply (from either the ICAP server or the origin server) to the client.
6. 代理将应答（从ICAP服务器或源服务器）发送到客户端。
In the "response modification" (respmod) mode, an ICAP client sends an HTTP response to an ICAP server. (The response sent by the ICAP client typically has been generated by an origin server.) The ICAP server may then:
在“响应修改”（respmod）模式下，ICAP客户端向ICAP服务器发送HTTP响应。（ICAP客户端发送的响应通常由源服务器生成。）然后，ICAP服务器可以：
1) Send back a modified version of the response.
1) 发回响应的修改版本。
2) Return an error.
2) 返回一个错误。
The response modification method is intended for post-processing performed on an HTTP response before it is delivered to a client. Examples include formatting HTML for display on special devices, human language translation, virus checking, and so forth.
响应修改方法用于在HTTP响应交付到客户端之前对其执行后处理。示例包括格式化HTML以在特殊设备上显示、人类语言翻译、病毒检查等。
Typical data flow:
典型数据流：
origin-server
| /|\
| |
3 | | 2
| |
\|/ | 4
ICAP-client --------------> ICAP-resource
(surrogate) <-------------- on ICAP-server
| /|\ 5
| |
6 | | 1
| |
\|/ |
client
origin-server
| /|\
| |
3 | | 2
| |
\|/ | 4
ICAP-client --------------> ICAP-resource
(surrogate) <-------------- on ICAP-server
| /|\ 5
| |
6 | | 1
| |
\|/ |
client
1. A client makes a request to a ICAP-capable surrogate (ICAP client) for an object on an origin server.
1. 客户端向支持ICAP的代理服务器（ICAP客户端）请求源服务器上的对象。
2. The surrogate sends the request to the origin server.
2. 代理将请求发送到源服务器。
3. The origin server responds to request.
3. 源服务器响应请求。
4. The ICAP-capable surrogate sends the origin server's reply to the ICAP server.
4. 支持ICAP的代理将源服务器的回复发送到ICAP服务器。
5. The ICAP server executes the ICAP resource's service on the origin server's reply and sends the possibly modified reply back to the ICAP client.
5. ICAP服务器在源服务器的应答上执行ICAP资源的服务，并将可能修改的应答发送回ICAP客户端。
6. The surrogate sends the reply, possibly modified from the original origin server's reply, to the client.
6. 代理将应答发送到客户端，该应答可能是从原始源服务器的应答修改而来的。
ICAP is a request/response protocol similar in semantics and usage to HTTP/1.1 [4]. Despite the similarity, ICAP is not HTTP, nor is it an application protocol that runs over HTTP. This means, for example, that ICAP messages can not be forwarded by HTTP surrogates. Our reasons for not building directly on top of HTTP are discussed in Section 8.1.
ICAP是一种在语义和用法上与HTTP/1.1[4]类似的请求/响应协议。尽管有相似之处，ICAP不是HTTP，也不是运行在HTTP上的应用程序协议。例如，这意味着不能通过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消息由客户端到服务器的请求和服务器到客户端的响应组成。请求和响应使用RFC 2822[3]的通用消息格式，即开始行（请求行或状态行）、多个标头字段（也称为“标头”）、空行（即CRLF前面没有任何内容的行）和消息正文，指示标头字段的结束。
The header lines of an ICAP message specify the ICAP resource being requested as well as other meta-data such as cache control information. The message body of an ICAP request contains the (encapsulated) HTTP messages that are being modified.
ICAP消息的头行指定所请求的ICAP资源以及其他元数据，如缓存控制信息。ICAP请求的消息体包含正在修改的（封装的）HTTP消息。
As in HTTP/1.1, a single transport connection MAY (perhaps even SHOULD) be re-used for multiple request/response pairs. The rules for doing so in ICAP are the same as described in Section 8.1.2.2 of [4]. Specifically, requests are matched up with responses by allowing only one outstanding request on a transport connection at a time. Multiple parallel connections MAY be used as in HTTP.
在HTTP/1.1中，单个传输连接可能（甚至可能应该）被重新用于多个请求/响应对。ICAP中的操作规则与[4]第8.1.2.2节所述相同。具体地说，请求与响应相匹配，一次只允许传输连接上有一个未完成的请求。在HTTP中可以使用多个并行连接。
All ICAP requests specify the ICAP resource being requested from the server using an ICAP URI. This MUST be an absolute URI that specifies both the complete hostname and the path of the resource being requested. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [1], Section 3. The URI structure defined by ICAP is roughly:
所有ICAP请求都指定使用ICAP URI从服务器请求的ICAP资源。这必须是一个绝对URI，指定所请求资源的完整主机名和路径。有关URL语法和语义的明确信息，请参阅“统一资源标识符（URI）：通用语法和语义”，RFC 2396[1]，第3节。ICAP定义的URI结构大致如下：
ICAP_URI = Scheme ":" Net_Path [ "?" Query ]
ICAP_URI=Scheme:“网络路径[“？”查询]
Scheme = "icap"
Scheme = "icap"
Net_Path = "//" Authority [ Abs_Path ]
Net_Path = "//" Authority [ Abs_Path ]
Authority = [ userinfo "@" ] host [ ":" port ]
Authority = [ userinfo "@" ] host [ ":" port ]
ICAP adds the new scheme "icap" to the ones defined in RFC 2396. If the port is empty or not given, port 1344 is assumed. An example ICAP URI line might look like this:
ICAP将新方案“ICAP”添加到RFC 2396中定义的方案中。如果端口为空或未给定，则假定端口1344。示例ICAP URI行可能如下所示：
icap://icap.example.net:2000/services/icap-service-1
icap://icap.example.net:2000/services/icap-service-1
An ICAP server MUST be able to recognize all of its hosts names, including any aliases, local variations, and numeric IP addresses of its interfaces.
ICAP服务器必须能够识别其所有主机名，包括其接口的任何别名、本地变体和数字IP地址。
Any arguments that an ICAP client wishes to pass to an ICAP service to modify the nature of the service MAY be passed as part of the ICAP-URI, using the standard "?"-encoding of attribute-value pairs used in HTTP. For example:
ICAP客户端希望传递给ICAP服务以修改服务性质的任何参数都可以作为ICAP-URI的一部分传递，使用HTTP中使用的属性-值对的标准“？”编码。例如：
icap://icap.net/service?mode=translate&lang=french
icap://icap.net/service?mode=translate&lang=french
The following sections define the valid headers for ICAP messages. Section 4.3.1 describes headers common to both requests and responses. Request-specific and response-specific headers are described in Sections 4.3.2 and 4.3.3, respectively.
以下各节定义了ICAP消息的有效标头。第4.3.1节描述了请求和响应的共同标题。第4.3.2节和第4.3.3节分别描述了特定于请求和响应的标题。
User-defined header extensions are allowed. In compliance with the precedent established by the Internet mail format [3] and later adopted by HTTP [4], all user-defined headers MUST follow the "X-" naming convention ("X-Extension-Header: Foo"). ICAP implementations MAY ignore any "X-" headers without loss of compliance with the protocol as defined in this document.
允许使用用户定义的标头扩展名。根据互联网邮件格式[3]建立的先例以及后来被HTTP[4]采用的先例，所有用户定义的头必须遵循“X-”命名约定（“X-Extension-Header:Foo”）。ICAP实施可以忽略任何“X-”头，而不会失去对本文件中定义的协议的遵从性。
Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. ICAP follows the rules describe in section 4.2 of [4].
每个标题字段由一个名称，后跟一个冒号（“：”）和字段值组成。字段名不区分大小写。ICAP遵循[4]第4.2节中描述的规则。
The headers of all ICAP messages MAY include the following directives, defined in ICAP the same as they are in HTTP:
所有ICAP消息的标题可能包括以下指令，这些指令在ICAP中的定义与在HTTP中的定义相同：
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].
升级报头可用于协商ICAP连接上的传输层安全性，正如[4]中HTTP/1.1所述。
The ICAP-specific headers defined are:
定义的ICAP特定标头包括：
Encapsulated (See Section 4.4)
封装（见第4.4节）
Similar to HTTP, ICAP requests MUST start with a request line that contains a method, the complete URI of the ICAP resource being requested, and an ICAP version string. The current version number of ICAP is "1.0".
与HTTP类似，ICAP请求必须以包含方法、所请求ICAP资源的完整URI和ICAP版本字符串的请求行开头。ICAP的当前版本号为“1.0”。
This version of ICAP defines three methods:
此版本的ICAP定义了三种方法：
REQMOD - for Request Modification (Section 4.8) RESPMOD - for Response Modification (Section 4.9) OPTIONS - to learn about configuration (Section 4.10)
REQMOD-请求修改（第4.8节）RESPMOD-响应修改（第4.9节）选项-了解配置（第4.10节）
The OPTIONS method MUST be implemented by all ICAP servers. All other methods are optional and MAY be implemented.
选项方法必须由所有ICAP服务器实现。所有其他方法都是可选的，可以实现。
User-defined extension methods are allowed. Before attempting to use an extension method, an ICAP client SHOULD use the OPTIONS method to query the ICAP server's list of supported methods; see Section 4.10. (If an ICAP server receives a request for an unknown method, it MUST give a 501 error response as described in the next section.)
允许使用用户定义的扩展方法。在尝试使用扩展方法之前，ICAP客户端应使用OPTIONS方法查询ICAP服务器支持的方法列表；见第4.10节。（如果ICAP服务器收到未知方法的请求，它必须给出501错误响应，如下一节所述。）
Given the URI rules described in Section 4.2, a well-formed ICAP request line looks like the following example:
根据第4.2节中描述的URI规则，格式良好的ICAP请求行如下所示：
RESPMOD icap://icap.example.net/translate?mode=french ICAP/1.0
RESPMOD icap://icap.example.net/translate?mode=french ICAP/1.0
A number of request-specific headers are allowed in ICAP requests, following the same semantics as the corresponding HTTP request headers (Section 5.3 of [4]). These are:
ICAP请求中允许使用大量特定于请求的标头，其语义与相应的HTTP请求标头相同（见[4]第5.3节）。这些是：
Authorization Allow (see Section 4.6) From (see Section 14.22 of [4]) Host (REQUIRED in ICAP as it is in HTTP/1.1) Referer (see Section 14.36 of [4]) User-Agent
授权允许（见第4.6节）来自（见[4]第14.22节）主机（在ICAP中要求，因为它在HTTP/1.1中是必需的）Referer（见[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节）
ICAP responses MUST start with an ICAP status line, similar in form to that used by HTTP, including the ICAP version and a status code. For example:
ICAP响应必须以ICAP状态行开始，其形式与HTTP使用的类似，包括ICAP版本和状态代码。例如：
ICAP/1.0 200 OK
ICAP/1.0 200正常
Semantics of ICAP status codes in ICAP match the status codes defined by HTTP (Section 6.1.1 and 10 of [4]), except where otherwise indicated in this document; n.b. 100 (Section 4.5) and 204 (Section 4.6).
ICAP中ICAP状态代码的语义与HTTP（第6.1.1节和[4]第10节）定义的状态代码相匹配，除非本文件另有说明；n、 b.100（第4.5节）和204（第4.6节）。
ICAP error codes that differ from their HTTP counterparts are:
与HTTP对应项不同的ICAP错误代码有：
100 - Continue after ICAP Preview (Section 4.5).
100-ICAP预览后继续（第4.5节）。
204 - No modifications needed (Section 4.6).
204-无需修改（第4.6节）。
400 - Bad request.
400-请求错误。
404 - ICAP Service not found.
404-找不到ICAP服务。
405 - Method not allowed for service (e.g., RESPMOD requested for service that supports only REQMOD).
405-服务不允许使用的方法（例如，仅支持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服务器上出现错误，例如“磁盘空间不足”。
501 - Method not implemented. This response is illegal for an OPTIONS request since implementation of OPTIONS is mandatory.
501-方法未实现。此响应对于选项请求是非法的，因为选项的实现是强制性的。
502 - Bad Gateway. This is an ICAP proxy and proxying produced an error.
502-坏网关。这是一个ICAP代理，代理生成了一个错误。
503 - Service overloaded. The ICAP server has exceeded a maximum connection limit associated with this service; the ICAP client should not exceed this limit in the future.
503-服务过载。ICAP服务器已超过与此服务关联的最大连接限制；ICAP客户端将来不应超过此限制。
505 - ICAP version not supported by server.
505-服务器不支持ICAP版本。
As in HTTP, the 4xx class of error codes indicate client errors, and the 5xx class indicate server errors.
与HTTP中一样，4xx类错误代码表示客户端错误，5xx类表示服务器错误。
ICAP's response-header fields allow the server to pass additional information in the response that cannot be placed in the ICAP's status line.
ICAP的响应头字段允许服务器在响应中传递不能放在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节）
When an ICAP-enabled HTTP surrogate makes an HTTP request to an origin server, it is often useful to advise the origin server of the surrogate's ICAP capabilities. Origin servers can use this information to modify its response accordingly. For example, an origin server may choose not to insert an advertisement into a page if it knows that a downstream ICAP server can insert the ad instead.
当启用ICAP的HTTP代理向源服务器发出HTTP请求时，将代理的ICAP功能告知源服务器通常很有用。源服务器可以使用此信息相应地修改其响应。例如，如果源服务器知道下游ICAP服务器可以插入广告，则它可以选择不将广告插入页面。
Although this ICAP specification can not mandate how HTTP is used in communication between HTTP clients and servers, we do suggest a convention: such headers (if used) SHOULD start with "X-ICAP". HTTP clients with ICAP services SHOULD minimally include an "X-ICAP-Version: 1.0" header along with their application-specific headers.
尽管此ICAP规范不能强制规定HTTP如何用于HTTP客户端和服务器之间的通信，但我们建议采用一种约定：此类头（如果使用）应以“X-ICAP”开头。具有ICAP服务的HTTP客户端应至少包含一个“X-ICAP-Version:1.0”头及其特定于应用程序的头。
The ICAP encapsulation model is a lightweight means of packaging any number of HTTP message sections into an encapsulating ICAP message-body, in order to allow the vectoring of requests, responses, and request/response pairs to an ICAP server.
ICAP封装模型是一种轻量级方法，可将任意数量的HTTP消息节封装到封装的ICAP消息体中，以允许将请求、响应和请求/响应对矢量化到ICAP服务器。
This is accomplished by concatenating interesting message parts (encapsulatED sections) into a single ICAP message-body (the encapsulatING message). The encapsulated sections may be the headers or bodies of HTTP messages.
这是通过将感兴趣的消息部分（封装部分）连接到单个ICAP消息体（封装消息）中来实现的。封装的部分可以是HTTP消息的头或正文。
Encapsulated bodies MUST be transferred using the "chunked" transfer-coding described in Section 3.6.1 of [4]. However, encapsulated headers MUST NOT be chunked. In other words, an ICAP message-body switches from being non-chunked to chunked as the body passes from the encapsulated header to encapsulated body section. (See Examples in Sections 4.8.3 and 4.9.3.). The motivation behind this decision is described in Section 8.2.
封装体必须使用[4]第3.6.1节所述的“分块”传输编码进行传输。但是，封装的头不能分块。换句话说，当主体从封装的头传递到封装的主体部分时，ICAP消息主体从非分块切换到分块。（参见第4.8.3节和第4.9.3节中的示例。）。第8.2节描述了该决定背后的动机。
The offset of each encapsulated section's start relative to the start of the encapsulating message's body is noted using the "Encapsulated" header. This header MUST be included in every ICAP message. For example, the header
每个封装部分的起始位置相对于封装消息正文的起始位置的偏移量使用“封装”标头进行记录。此标头必须包含在每个ICAP消息中。例如，标题
Encapsulated: req-hdr=0, res-hdr=45, res-body=100
Encapsulated: req-hdr=0, res-hdr=45, res-body=100
indicates a message that encapsulates a group of request headers, a group of response headers, and then a response body. Each of these is included at the byte-offsets listed. The byte-offsets are in decimal notation for consistency with HTTP's Content-Length header.
指示封装一组请求标头、一组响应标头和一个响应正文的消息。其中每一个都包含在列出的字节偏移量中。字节偏移量采用十进制表示法，以与HTTP的内容长度头保持一致。
The special entity "null-body" indicates there is no encapsulated body in the ICAP message.
特殊实体“null body”表示ICAP消息中没有封装的body。
The syntax of an Encapsulated header is:
封装标头的语法为：
encapsulated_header: "Encapsulated: " encapsulated_list
encapsulated_list: encapsulated_entity |
encapsulated_entity ", " encapsulated_list
encapsulated_entity: reqhdr | reshdr | reqbody | resbody | optbody
reqhdr = "req-hdr" "=" (decimal integer)
reshdr = "res-hdr" "=" (decimal integer)
reqbody = { "req-body" | "null-body" } "=" (decimal integer)
resbody = { "res-body" | "null-body" } "=" (decimal integer)
optbody = { "opt-body" | "null-body" } "=" (decimal integer)
encapsulated_header: "Encapsulated: " encapsulated_list
encapsulated_list: encapsulated_entity |
encapsulated_entity ", " encapsulated_list
encapsulated_entity: reqhdr | reshdr | reqbody | resbody | optbody
reqhdr = "req-hdr" "=" (decimal integer)
reshdr = "res-hdr" "=" (decimal integer)
reqbody = { "req-body" | "null-body" } "=" (decimal integer)
resbody = { "res-body" | "null-body" } "=" (decimal integer)
optbody = { "opt-body" | "null-body" } "=" (decimal integer)
There are semantic restrictions on Encapsulated headers beyond the syntactic restrictions. The order in which the encapsulated parts appear in the encapsulating message-body MUST be the same as the order in which the parts are named in the Encapsulated header. In other words, the offsets listed in the Encapsulated line MUST be monotonically increasing. In addition, the legal forms of the Encapsulated header depend on the method being used (REQMOD, RESPMOD, or OPTIONS). Specifically:
除了语法限制之外，还有对封装头的语义限制。封装部分在封装消息正文中的显示顺序必须与在封装头中命名部分的顺序相同。换句话说，封装行中列出的偏移量必须单调递增。此外，封装头的合法形式取决于所使用的方法（REQMOD、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 request encapsulated_list: [reqhdr] reqbody
REQMOD response encapsulated_list: {[reqhdr] reqbody} |
{[reshdr] resbody}
RESPMOD request encapsulated_list: [reqhdr] [reshdr] resbody
RESPMOD response encapsulated_list: [reshdr] resbody
OPTIONS response encapsulated_list: optbody
In the above grammar, note that encapsulated headers are always optional. At most one body per encapsulated message is allowed. If no encapsulated body is presented, the "null-body" header is used instead; this is useful because it indicates the length of the header section.
在上面的语法中，请注意，封装的标题始终是可选的。每个封装消息最多允许一个正文。如果未显示封装体，则使用“空体”标题；这很有用，因为它指示标题部分的长度。
Examples of legal Encapsulated headers:
合法封装头的示例：
/* REQMOD request: This encapsulated HTTP request's headers start
* at offset 0; the HTTP request body (e.g., in a POST) starts
* at 412. */
Encapsulated: req-hdr=0, req-body=412
/* REQMOD request: This encapsulated HTTP request's headers start
* at offset 0; the HTTP request body (e.g., in a POST) starts
* at 412. */
Encapsulated: req-hdr=0, req-body=412
/* REQMOD request: Similar to the above, but no request body is
* present (e.g., a GET). We use the null-body directive instead.
* In both this case and the previous one, we can tell from the
* Encapsulated header that the request headers were 412 bytes
* long. */
Encapsulated: req-hdr=0, null-body=412
/* REQMOD request: Similar to the above, but no request body is
* present (e.g., a GET). We use the null-body directive instead.
* In both this case and the previous one, we can tell from the
* Encapsulated header that the request headers were 412 bytes
* long. */
Encapsulated: req-hdr=0, null-body=412
/* REQMOD response: ICAP server returned a modified request,
* with body */
Encapsulated: req-hdr=0, req-body=512
/* REQMOD response: ICAP server returned a modified request,
* with body */
Encapsulated: req-hdr=0, req-body=512
/* RESPMOD request: Request headers at 0, response headers at 822,
* response body at 1655. Note that no request body is allowed in
* RESPMOD requests. */
Encapsulated: req-hdr=0, res-hdr=822, res-body=1655
/* RESPMOD request: Request headers at 0, response headers at 822,
* response body at 1655. Note that no request body is allowed in
* RESPMOD requests. */
Encapsulated: req-hdr=0, res-hdr=822, res-body=1655
/* RESPMOD or REQMOD response: header and body returned */
Encapsulated: res-hdr=0, res-body=749
/* RESPMOD or REQMOD response: header and body returned */
Encapsulated: res-hdr=0, res-body=749
/* OPTIONS response when there IS an options body */
Encapsulated: opt-body=0
/* OPTIONS response when there IS an options body */
Encapsulated: opt-body=0
/* OPTIONS response when there IS NOT an options body */
Encapsulated: null-body=0
/* OPTIONS response when there IS NOT an options body */
Encapsulated: null-body=0
By default, ICAP messages may encapsulate HTTP message headers and entity bodies. HTTP headers MUST start with the request-line or status-line for requests and responses, respectively, followed by interesting HTTP headers.
默认情况下，ICAP消息可以封装HTTP消息头和实体体。HTTP头必须分别以请求和响应的请求行或状态行开头，然后是感兴趣的HTTP头。
The encapsulated headers MUST be terminated by a blank line, in order to make them human readable, and in order to terminate line-by-line HTTP parsers.
封装的头必须以空行终止，以使其可读，并以逐行终止HTTP解析器。
HTTP/1.1 makes a distinction between end-to-end headers and hop-by-hop headers (see Section 13.5.1 of [4]). End-to-end headers are meaningful to the ultimate recipient of a message, whereas hop-by-hop headers are meaningful only for a single transport-layer connection. Hop-by-hop headers include Connection, Keep-Alive, and so forth. All end-to-end HTTP headers SHOULD be encapsulated, and all hop-by-hop headers MUST NOT be encapsulated.
HTTP/1.1对端到端头和逐跳头进行了区分（见[4]第13.5.1节）。端到端头对消息的最终接收者有意义，而逐跳头仅对单个传输层连接有意义。逐跳标头包括连接、保持活动等。应封装所有端到端HTTP头，且不得封装所有逐跳头。
Despite the above restrictions on encapsulation, the hop-by-hop Proxy-Authenticate and Proxy-Authorization headers MUST be forwarded to the ICAP server in the ICAP header section (not the encapsulated message). This allows propagation of client credentials that might have been sent to the ICAP client in cases where the ICAP client is also an HTTP surrogate. Note that this does not contradict HTTP/1.1, which explicitly states "A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request." (Section 14.34).
尽管有上述封装限制，逐跳代理验证和代理授权标头必须转发到ICAP标头部分中的ICAP服务器（而不是封装的消息）。这允许在ICAP客户端也是HTTP代理的情况下传播可能已发送到ICAP客户端的客户端凭据。请注意，这并不与HTTP/1.1相矛盾，HTTP/1.1明确规定“如果代理协同验证给定请求的机制是，代理可以将凭据从客户端请求中继到下一个代理”（第14.34节）。
The Via header of an encapsulated message SHOULD be modified by an ICAP server as if the encapsulated message were traveling through an HTTP surrogate. The Via header added by an ICAP server MUST specify protocol as ICAP/1.0.
ICAP服务器应修改封装消息的Via头，就像封装消息通过HTTP代理进行传输一样。ICAP服务器添加的Via标头必须将协议指定为ICAP/1.0。
ICAP REQMOD or RESPMOD requests sent by the ICAP client to the ICAP server may include a "preview". This feature allows an ICAP server to see the beginning of a transaction, then decide if it wants to
ICAP客户端发送到ICAP服务器的ICAP REQMOD或RESPMOD请求可能包括“预览”。此功能允许ICAP服务器查看事务的开始，然后决定是否需要
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文件类型是不够的）。文件前面的魔法数字可以将文件标识为JPEG或GIF。
- If an ICAP server wants to transcode all GIF87 files into GIF89 files, then the GIF87 files could quickly be detected by looking at the first few body bytes of the file.
- 如果ICAP服务器希望将所有GIF87文件转换为GIF89文件，则可以通过查看文件的前几个正文字节来快速检测GIF87文件。
- If an ICAP server wants to force all cacheable files to expire in 24 hours or less, then this could be implemented by selecting HTTP messages with expiries more than 24 hours in the future.
- 如果ICAP服务器希望强制所有可缓存文件在24小时或更短时间内过期，则可以通过选择在未来过期超过24小时的HTTP消息来实现。
ICAP servers SHOULD use the OPTIONS method (see Section 4.10) to specify how many bytes of preview are needed for a particular ICAP application on a per-resource basis. Clients SHOULD be able to provide Previews of at least 4096 bytes. Clients furthermore SHOULD provide a Preview when using any ICAP resource that has indicated a Preview is useful. (This indication might be provided via the OPTIONS method, or some other "out-of-band" configuration.) Clients SHOULD NOT provide a larger Preview than a server has indicated it is willing to accept.
ICAP服务器应使用选项方法（见第4.10节）指定特定ICAP应用程序在每个资源的基础上需要多少字节的预览。客户端应该能够提供至少4096字节的预览。此外，当使用任何表明预览有用的ICAP资源时，客户端应提供预览。（此指示可能通过选项方法或其他一些“带外”配置提供。）客户端提供的预览不应超过服务器表示愿意接受的范围。
To effect a Preview, an ICAP client MUST add a "Preview:" header to its request headers indicating the length of the preview. The ICAP client then sends:
要实现预览，ICAP客户端必须在其请求头中添加一个“Preview:”头，指示预览的长度。然后，ICAP客户端发送：
- all of the encapsulated header sections, and
- 所有封装的标题部分，以及
- the beginning of the encapsulated body section, if any, up to the number of bytes advertised in the Preview (possibly 0).
- 封装的正文部分的开头（如果有），最多可达预览中公布的字节数（可能为0）。
After the Preview is sent, the client stops and waits for an intermediate response from the ICAP server before continuing. This mechanism is similar to the "100-Continue" feature found in HTTP, except that the stop-and-wait point can be within the message body. In contrast, HTTP requires that the point must be the boundary between the headers and body.
发送预览后，客户端停止并等待来自ICAP服务器的中间响应，然后继续。此机制类似于HTTP中的“100 Continue”特性，只是停止和等待点可以在消息体中。相反，HTTP要求点必须是头和主体之间的边界。
For example, to effect a Preview consisting of only encapsulated HTTP headers, the ICAP client would add the following header to the ICAP request:
例如，为了实现仅包含封装的HTTP头的预览，ICAP客户端将向ICAP请求添加以下头：
Preview: 0
预览：0
This indicates that the ICAP client will send only the encapsulated header sections to the ICAP server, then it will send a zero-length chunk and stop and wait for a "go ahead" to send more encapsulated body bytes to the ICAP server.
这表示ICAP客户端将只向ICAP服务器发送封装的头部分，然后它将发送一个零长度块，并停止并等待“继续”向ICAP服务器发送更多封装的正文字节。
Similarly, the ICAP header:
类似地，ICAP标头：
Preview: 4096
预览：4096
Indicates that the ICAP client will attempt to send 4096 bytes of origin server data in the encapsulated body of the ICAP request to the ICAP server. It is important to note that the actual transfer may be less, because the ICAP client is acting like a surrogate and is not looking ahead to find the total length of the origin server response. The entire ICAP encapsulated header section(s) will be sent, followed by up to 4096 bytes of encapsulated HTTP body. The chunk body terminator "0\r\n\r\n" is always included in these transactions.
指示ICAP客户端将尝试在ICAP请求的封装正文中向ICAP服务器发送4096字节的源服务器数据。重要的是要注意，实际传输可能会更少，因为ICAP客户端的行为就像一个代理，并没有前瞻性地查找源服务器响应的总长度。将发送整个ICAP封装的标头部分，然后发送最多4096字节的封装HTTP正文。区块正文终止符“0\r\n\r\n”始终包含在这些事务中。
After sending the preview, the ICAP client will wait for a response from the ICAP server. The response MUST be one of the following:
发送预览后，ICAP客户端将等待来自ICAP服务器的响应。响应必须是以下内容之一：
- 204 No Content. The ICAP server does not want to (or can not) modify the ICAP client's request. The ICAP client MUST treat this the same as if it had sent the entire message to the ICAP server and an identical message was returned.
- 204没有内容。ICAP服务器不想（或不能）修改ICAP客户端的请求。ICAP客户端必须将其视为已将整个消息发送到ICAP服务器并返回相同消息。
- ICAP reqmod or respmod response, depending what method was the original request. See Section 4.8.2 and 4.9.2 for the format of reqmod and respmod responses.
- ICAP reqmod或respmod响应，取决于原始请求的方法。reqmod和respmod响应的格式见第4.8.2节和第4.9.2节。
- 100 Continue. If the entire encapsulated HTTP body did not fit in the preview, the ICAP client MUST send the remainder of its ICAP message, starting from the first chunk after the preview. If the entire message fit in the preview (detected by the "EOF" symbol explained below), then the ICAP server MUST NOT respond with 100 Continue.
- 100继续。如果整个封装的HTTP正文不适合预览，则ICAP客户端必须从预览后的第一个区块开始发送其ICAP消息的其余部分。如果整个消息适合预览（通过下面解释的“EOF”符号检测），则ICAP服务器不得响应100 Continue。
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为ICAP客户端定义了一种向ICAP服务器指示“EOF”的方法（如果有的话）
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.
我们定义了“ieof”的HTTP块扩展，以指示ICAP块是最后一个块（请参见[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:
例如，考虑刚刚从OrthServer接收到HTTP响应头的ICAP客户端，并将ICAP RESMOD事务启动到ICAP服务器。它还不知道将有多少正文字节从源服务器到达，因为服务器没有使用Content-Length标头。ICAP客户端通知ICAP服务器，它将使用“preview:1024”请求头发送1024字节的预览。如果HTTP源服务器随后在发送任何数据之前关闭其与ICAP客户端的连接（即，它提供零字节正文），则该零字节源响应的相应零字节预览将如下所示：
\r\n 0; ieof\r\n\r\n
\r\n 0；ieof\r\n\r\n
If an ICAP server sees this preview, it knows from the presence of "ieof" that the client will not be sending any more chunk data. In this case, the server MUST respond with the modified response or a 204 No Content message right away. It MUST NOT send a 100-Continue response in this case. (In contrast, if the origin response had been 1 byte or larger, the "ieof" would not have appeared. In that case, an ICAP server MAY reply with 100-Continue, a modified response, or 204 No Content.)
如果ICAP服务器看到此预览，它会从“ieof”的存在中知道客户端将不再发送任何区块数据。在这种情况下，服务器必须立即使用修改后的响应或204无内容消息进行响应。在这种情况下，它不能发送100 Continue响应。（相反，如果原始响应为1字节或更大，则不会出现“ieof”。在这种情况下，ICAP服务器可能会以100 Continue、修改后的响应或204 No 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字节，并且源响应是两个块中的1024字节，则封装将显示如下：
200\r\n <512 bytes of data>\r\n 200\r\n <512 bytes of data>\r\n 0; ieof\r\n\r\n
200\r\n<512字节数据>\r\n 200\r\n<512字节数据>\r\n 0；ieof\r\n\r\n
<204 or modified response> (100 Continue disallowed due to ieof)
<204或修改后的响应>（由于ieof，100继续被禁止）
If the preview is 1024 bytes and the origin response is 1025 bytes (and the ICAP server responds with 100-continue), then these chunks would appear on the wire:
如果预览为1024字节，原始响应为1025字节（ICAP服务器响应为100 continue），则这些块将出现在连线上：
200\r\n <512 bytes of data>\r\n 200\r\n <512 bytes of data>\r\n 0\r\n
200\r\n<512字节数据>\r\n 200\r\n<512字节数据>\r\n 0\r\n
<100 Continue Message>
<100继续消息>
1\r\n <1 byte of data>\r\n 0\r\n\r\n <no ieof because we are no longer in preview mode>
1\r\n<1字节数据>\r\n 0\r\n\r\n<没有ieof，因为我们不再处于预览模式>
Once the ICAP server receives the eof indicator, it finishes reading the current chunk stream.
一旦ICAP服务器接收到eof指示符，它将完成当前区块流的读取。
Note that when offering a Preview, the ICAP client is committing to temporarily buffer the previewed portion of the message so that it can honor a "204 No Content" response. The remainder of the message is not necessarily buffered; it might be pipelined directly from another source to the ICAP server after a 100-Continue.
请注意，在提供预览时，ICAP客户端承诺暂时缓冲消息的预览部分，以便它能够接受“204无内容”响应。消息的其余部分不必缓冲；在100分钟后，它可能直接从另一个源通过管道传输到ICAP服务器。
An ICAP client MAY choose to honor "204 No Content" responses for an entire message. This is the decision of the client because it imposes a burden on the client of buffering the entire message.
ICAP客户端可以选择对整个消息执行“204无内容”响应。这是客户机的决定，因为它给客户机带来了缓冲整个消息的负担。
An ICAP client MAY include "Allow: 204" in its request headers, indicating that the server MAY reply to the message with a "204 No Content" response if the object does not need modification.
ICAP客户端可以在其请求头中包括“Allow:204”，指示如果对象不需要修改，则服务器可以使用“204 No Content”响应来回复消息。
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.
此规则的唯一例外是消息预览，如前一节所述。在这种情况下，即使原始请求没有“Allow:204”标头，ICAP服务器也可以使用204 No Content消息响应消息预览。
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客户端发送表示服务当前状态的特定于服务的“cookie”提供了一种方法。它是一个最大32字节的字母数字数据字符串（不包括空字符）
may, for example, be a representation of the software version or configuration of a service. An ISTag validates that previous ICAP server responses can still be considered fresh by an ICAP client that may be caching them. If a change on the ICAP server invalidates previous responses, the ICAP server can invalidate portions of the ICAP client's cache by changing its ISTag. The ISTag MUST be included in every ICAP response from an ICAP server.
例如，可以是服务的软件版本或配置的表示。ISTag验证以前的ICAP服务器响应是否仍然可以被缓存它们的ICAP客户端视为新响应。如果ICAP服务器上的更改使以前的响应无效，则ICAP服务器可以通过更改其ISTag使ICAP客户端缓存的部分无效。ISTag必须包含在来自ICAP服务器的每个ICAP响应中。
For example, consider a virus-scanning ICAP service. The ISTag might be a combination of the virus scanner's software version and the release number of its virus signature database. When the database is updated, the ISTag can be changed to invalidate all previous responses that had been certified as "clean" and cached with the old ISTag.
例如，考虑病毒扫描ICAP服务。ISTag可能是病毒扫描程序的软件版本及其病毒特征码数据库的发行号的组合。当数据库更新时，可以更改ISTag以使以前所有被证明为“干净”并使用旧ISTag缓存的响应无效。
ISTag is similar, but not identical, to the HTTP ETag. While an ETag is a validator for a particular entity (object), an ISTag validates all entities generated by a particular service (URI). A change in the ISTag invalidates all the other entities provided a service with the old ISTag, not just the entity whose response contained the updated ISTag.
ISTag与HTTP ETag类似，但不完全相同。ETag是特定实体（对象）的验证器，而ISTag则验证特定服务（URI）生成的所有实体。ISTag中的更改将使使用旧ISTag提供服务的所有其他实体失效，而不仅仅是其响应包含更新ISTag的实体。
The syntax of an ISTag is simply: ISTag = "ISTag: " quoted-string
ISTag的语法很简单：ISTag=“ISTag:”带引号的字符串
In this document we use the quoted-string definition defined in section 2.2 of [4].
在本文件中，我们使用[4]第2.2节中定义的引用字符串定义。
For example: ISTag: "874900-1994-1c02798"
例如：ISTag：“874900-1994-1c02798”
In this method, described in Section 3.1, an ICAP client sends an HTTP request to an ICAP server. The ICAP server returns a modified version of the request, an HTTP response, or (if the client indicates it supports 204 responses) an indication that no modification is required.
在第3.1节中描述的这种方法中，ICAP客户端向ICAP服务器发送HTTP请求。ICAP服务器返回请求的修改版本、HTTP响应，或者（如果客户端指示它支持204个响应）指示不需要修改。
In REQMOD mode, the ICAP request MUST contain an encapsulated HTTP request. The headers and body (if any) MUST both be encapsulated, except that hop-by-hop headers are not encapsulated.
在REQMOD模式下，ICAP请求必须包含封装的HTTP请求。标头和正文（如果有）都必须封装，但逐跃标头不封装除外。
The response from the ICAP server back to the ICAP client may take one of four forms:
从ICAP服务器返回ICAP客户端的响应可以采用以下四种形式之一：
- An error indication,
- 错误指示，
- A 204 indicating that the ICAP client's request requires no adaptation (see Section 4.6 for limitations of this response),
- A 204表示ICAP客户的请求不需要修改（该响应的限制见第4.6节），
- An encapsulated, adapted version of the ICAP client's request, or
- ICAP客户请求的封装、改编版本，或
- An encapsulated HTTP error response. Note that Request Modification requests may only be satisfied with HTTP responses in cases when the HTTP response is an error (e.g., 403 Forbidden).
- 封装的HTTP错误响应。请注意，只有在HTTP响应为错误（例如403禁止）的情况下，才能使用HTTP响应满足请求修改请求。
The first line of the response message MUST be a status line as described in Section 4.3.3. If the return code is a 2XX, the ICAP client SHOULD continue its normal execution of the request. If the ICAP client is a surrogate, this may include serving an object from its cache or forwarding the modified request to an origin server. Note it is valid for a 2XX ICAP response to contain an encapsulated HTTP error response, which in turn should be returned to the downstream client by the ICAP client.
响应消息的第一行必须是第4.3.3节所述的状态行。如果返回代码为2XX，则ICAP客户端应继续正常执行请求。如果ICAP客户端是代理，这可能包括从其缓存中为对象提供服务或将修改后的请求转发到源服务器。注意：2XX ICAP响应包含封装的HTTP错误响应是有效的，反过来，ICAP客户端应将该错误响应返回给下游客户端。
For other return codes that indicate an error, the ICAP client MAY (for example) return the error to the downstream client or user, execute the unadapted request as it arrived from the client, or re-try the adaptation again.
对于指示错误的其他返回代码，ICAP客户端可以（例如）将错误返回给下游客户端或用户，在从客户端到达时执行未自适应的请求，或者再次尝试自适应。
The modified request headers, if any, MUST be returned to the ICAP client using appropriate encapsulation as described in Section 4.4.
修改后的请求头（如果有）必须使用第4.4节所述的适当封装返回给ICAP客户端。
Consider the following example, in which a surrogate receives a simple GET request from a client. The surrogate, acting as an ICAP client, then forwards this request to an ICAP server for modification. The ICAP server modifies the request headers and sends them back to the ICAP client. Our hypothetical ICAP server will modify several headers and strip the cookie from the original request.
请考虑下面的示例，其中代理从客户端接收简单的GET请求。代理服务器充当ICAP客户端，然后将此请求转发给ICAP服务器进行修改。ICAP服务器修改请求头并将其发送回ICAP客户端。我们假设的ICAP服务器将修改几个头并从原始请求中删除cookie。
In all of our examples, we include the extra meta-data added to the message due to chunking the encapsulated message body (if any). We assume that end-of-line terminations, and blank lines, are two-byte "CRLF" sequences.
在我们的所有示例中，我们都包括由于对封装的消息体（如果有）进行分块而添加到消息中的额外元数据。我们假设行尾终止和空行是两字节的“CRLF”序列。
ICAP Request Modification Example 1 - ICAP Request
----------------------------------------------------------------
REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0
Host: icap-server.net
Encapsulated: req-hdr=0, null-body=170
ICAP Request Modification Example 1 - ICAP Request
----------------------------------------------------------------
REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0
Host: icap-server.net
Encapsulated: req-hdr=0, null-body=170
GET / HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain
Accept-Encoding: compress
Cookie: ff39fk3jur@4ii0e02i
If-None-Match: "xyzzy", "r2d2xxxx"
GET / HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain
Accept-Encoding: compress
Cookie: ff39fk3jur@4ii0e02i
If-None-Match: "xyzzy", "r2d2xxxx"
----------------------------------------------------------------
ICAP Request Modification Example 1 - ICAP Response
----------------------------------------------------------------
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Server: ICAP-Server-Software/1.0
Connection: close
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: req-hdr=0, null-body=231
----------------------------------------------------------------
ICAP Request Modification Example 1 - ICAP Response
----------------------------------------------------------------
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Server: ICAP-Server-Software/1.0
Connection: close
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: req-hdr=0, null-body=231
GET /modified-path HTTP/1.1
Host: www.origin-server.com
Via: 1.0 icap-server.net (ICAP Example ReqMod Service 1.1)
Accept: text/html, text/plain, image/gif
Accept-Encoding: gzip, compress
If-None-Match: "xyzzy", "r2d2xxxx"
GET /modified-path HTTP/1.1
Host: www.origin-server.com
Via: 1.0 icap-server.net (ICAP Example ReqMod Service 1.1)
Accept: text/html, text/plain, image/gif
Accept-Encoding: gzip, compress
If-None-Match: "xyzzy", "r2d2xxxx"
----------------------------------------------------------------
----------------------------------------------------------------
The second example is similar to the first, except that the request being modified in this case is a POST instead of a GET. Note that the encapsulated Content-Length argument has been modified to reflect the modified body of the POST message. The outer ICAP message does not need a Content-Length header because it uses chunking (not shown).
第二个示例与第一个示例类似，只是本例中修改的请求是POST而不是GET。请注意，封装的Content Length参数已被修改，以反映修改后的POST消息正文。外部ICAP消息不需要内容长度头，因为它使用分块（未显示）。
In this second example, the Encapsulated header shows the division between the forwarded header and forwarded body, for both the request and the response.
在第二个示例中，封装的报头显示了请求和响应的转发报头和转发正文之间的划分。
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 Request Modification Example 2 - ICAP Request
----------------------------------------------------------------
REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0
Host: icap-server.net
Encapsulated: req-hdr=0, req-body=147
POST /origin-resource/form.pl HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain
Accept-Encoding: compress
Pragma: no-cache
POST /origin-resource/form.pl HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain
Accept-Encoding: compress
Pragma: no-cache
1e I am posting this information. 0
1e我正在发布此信息。0
----------------------------------------------------------------
ICAP Request Modification Example 2 - ICAP Response
----------------------------------------------------------------
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Server: ICAP-Server-Software/1.0
Connection: close
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: req-hdr=0, req-body=244
----------------------------------------------------------------
ICAP Request Modification Example 2 - ICAP Response
----------------------------------------------------------------
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Server: ICAP-Server-Software/1.0
Connection: close
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: req-hdr=0, req-body=244
POST /origin-resource/form.pl HTTP/1.1
Host: www.origin-server.com
Via: 1.0 icap-server.net (ICAP Example ReqMod Service 1.1)
Accept: text/html, text/plain, image/gif
Accept-Encoding: gzip, compress
Pragma: no-cache
Content-Length: 45
POST /origin-resource/form.pl HTTP/1.1
Host: www.origin-server.com
Via: 1.0 icap-server.net (ICAP Example ReqMod Service 1.1)
Accept: text/html, text/plain, image/gif
Accept-Encoding: gzip, compress
Pragma: no-cache
Content-Length: 45
2d I am posting this information. ICAP powered! 0
我正在发布此信息。ICAP供电！0
----------------------------------------------------------------
Finally, this third example shows an ICAP server returning an error
response when it receives a Request Modification request.
----------------------------------------------------------------
Finally, this third example shows an ICAP server returning an error
response when it receives a Request Modification request.
ICAP Request Modification Example 3 - ICAP Request
----------------------------------------------------------------
REQMOD icap://icap-server.net/content-filter ICAP/1.0
Host: icap-server.net
Encapsulated: req-hdr=0, null-body=119
ICAP Request Modification Example 3 - ICAP Request
----------------------------------------------------------------
REQMOD icap://icap-server.net/content-filter ICAP/1.0
Host: icap-server.net
Encapsulated: req-hdr=0, null-body=119
GET /naughty-content HTTP/1.1
Host: www.naughty-site.com
Accept: text/html, text/plain
Accept-Encoding: compress
GET /naughty-content HTTP/1.1
Host: www.naughty-site.com
Accept: text/html, text/plain
Accept-Encoding: compress
----------------------------------------------------------------
----------------------------------------------------------------
ICAP Request Modification Example 3 - ICAP Response
----------------------------------------------------------------
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Server: ICAP-Server-Software/1.0
Connection: close
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: res-hdr=0, res-body=213
ICAP Request Modification Example 3 - ICAP Response
----------------------------------------------------------------
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Server: ICAP-Server-Software/1.0
Connection: close
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: res-hdr=0, res-body=213
HTTP/1.1 403 Forbidden
Date: Wed, 08 Nov 2000 16:02:10 GMT
Server: Apache/1.3.12 (Unix)
Last-Modified: Thu, 02 Nov 2000 13:51:37 GMT
ETag: "63600-1989-3a017169"
Content-Length: 58
Content-Type: text/html
HTTP/1.1 403 Forbidden
Date: Wed, 08 Nov 2000 16:02:10 GMT
Server: Apache/1.3.12 (Unix)
Last-Modified: Thu, 02 Nov 2000 13:51:37 GMT
ETag: "63600-1989-3a017169"
Content-Length: 58
Content-Type: text/html
3a Sorry, you are not allowed to access that naughty content. 0
很抱歉，你不允许访问那些调皮的内容。0
----------------------------------------------------------------
----------------------------------------------------------------
In this method, described in Section 3.2, an ICAP client sends an origin server's HTTP response to an ICAP server, and (if available) the original client request that caused that response. Similar to Request Modification method, the response from the ICAP server can be an adapted HTTP response, an error, or a 204 response code indicating that no adaptation is required.
在第3.2节所述的这种方法中，ICAP客户端向ICAP服务器发送源服务器的HTTP响应，以及（如果可用）导致该响应的原始客户端请求。与请求修改方法类似，来自ICAP服务器的响应可以是自适应HTTP响应、错误或指示不需要自适应的204响应代码。
Using encapsulation described in Section 4.4, the header and body of the HTTP response to be modified MUST be included in the ICAP body. If available, the header of the original client request SHOULD also be included. As with the other method, the hop-by-hop headers of the encapsulated messages MUST NOT be forwarded. The Encapsulated header MUST indicate the byte-offsets of the beginning of each of these four parts.
使用第4.4节中描述的封装，要修改的HTTP响应的头和主体必须包含在ICAP主体中。如果可用，还应包括原始客户端请求的标头。与其他方法一样，不得转发封装消息的逐跳标头。封装的标头必须指示这四个部分中每个部分的开头的字节偏移量。
The response from the ICAP server looks just like a reply in the Request Modification method (Section 4.8); that is,
来自ICAP服务器的响应看起来就像请求修改方法中的应答（第4.8节）；就是，
- An error indication,
- 错误指示，
- An encapsulated and potentially modified HTTP response header and response body, or
- 封装并可能修改的HTTP响应头和响应体，或
- An HTTP response 204 indicating that the ICAP client's request requires no adaptation.
- 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客户端应继续正常执行响应。ICAP客户端可以重新检查响应消息头中的头，以便对响应做出进一步的决定（例如，其可访问性）。
For other return codes that indicate an error, the ICAP client SHOULD NOT return these directly to downstream client, since these errors only make sense in the ICAP client/server transaction.
对于指示错误的其他返回代码，ICAP客户端不应将其直接返回给下游客户端，因为这些错误仅在ICAP客户端/服务器事务中有意义。
The modified response headers, if any, MUST be returned to the ICAP client using appropriate encapsulation as described in Section 4.4.
修改后的响应头（如果有）必须使用第4.4节所述的适当封装返回给ICAP客户端。
In Example 4, an ICAP client is requesting modification of an entity that was returned as a result of a client GET. The original client GET was to an origin server at "www.origin-server.com"; the ICAP server is at "icap.example.org".
在示例4中，ICAP客户端请求修改作为客户端GET结果返回的实体。原始的客户端GET被发送到“www.origin-server.com”上的源服务器；ICAP服务器位于“ICAP.example.org”。
ICAP Response Modification Example 4 - ICAP Request
----------------------------------------------------------------
RESPMOD icap://icap.example.org/satisf ICAP/1.0
Host: icap.example.org
Encapsulated: req-hdr=0, res-hdr=137, res-body=296
ICAP Response Modification Example 4 - ICAP Request
----------------------------------------------------------------
RESPMOD icap://icap.example.org/satisf ICAP/1.0
Host: icap.example.org
Encapsulated: req-hdr=0, res-hdr=137, res-body=296
GET /origin-resource HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain, image/gif
Accept-Encoding: gzip, compress
GET /origin-resource HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain, image/gif
Accept-Encoding: gzip, compress
HTTP/1.1 200 OK
Date: Mon, 10 Jan 2000 09:52:22 GMT
Server: Apache/1.3.6 (Unix)
ETag: "63840-1ab7-378d415b"
Content-Type: text/html
Content-Length: 51
HTTP/1.1 200 OK
Date: Mon, 10 Jan 2000 09:52:22 GMT
Server: Apache/1.3.6 (Unix)
ETag: "63840-1ab7-378d415b"
Content-Type: text/html
Content-Length: 51
33 This is data that was returned by an origin server. 0
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 Response Modification Example 4 - ICAP Response
----------------------------------------------------------------
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Server: ICAP-Server-Software/1.0
Connection: close
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: res-hdr=0, res-body=222
HTTP/1.1 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Via: 1.0 icap.example.org (ICAP Example RespMod Service 1.1)
Server: Apache/1.3.6 (Unix)
ETag: "63840-1ab7-378d415b"
Content-Type: text/html
Content-Length: 92
HTTP/1.1 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Via: 1.0 icap.example.org (ICAP Example RespMod Service 1.1)
Server: Apache/1.3.6 (Unix)
ETag: "63840-1ab7-378d415b"
Content-Type: text/html
Content-Length: 92
5c This is data that was returned by an origin server, but with value added by an ICAP server. 0
5c这是源服务器返回的数据，但具有ICAP服务器添加的值。0
----------------------------------------------------------------
----------------------------------------------------------------
The ICAP "OPTIONS" method is used by the ICAP client to retrieve configuration information from the ICAP server. In this method, the ICAP client sends a request addressed to a specific ICAP resource and receives back a response with options that are specific to the service named by the URI. All OPTIONS requests MAY also return options that are global to the server (i.e., apply to all services).
ICAP客户端使用ICAP“选项”方法从ICAP服务器检索配置信息。在该方法中，ICAP客户端发送一个寻址到特定ICAP资源的请求，并接收回一个带有特定于URI命名的服务的选项的响应。所有选项请求还可能返回对服务器全局的选项（即，应用于所有服务）。
The OPTIONS method consists of a request-line, as described in Section 4.3.2, such as the following example:
选项方法由一个请求行组成，如第4.3.2节所述，例如以下示例：
OPTIONS icap://icap.server.net/sample-service ICAP/1.0 User-Agent:
ICAP-client-XYZ/1.001
OPTIONS icap://icap.server.net/sample-service ICAP/1.0 User-Agent:
ICAP-client-XYZ/1.001
Other headers are also allowed as described in Section 4.3.1 and Section 4.3.2 (for example, Host).
如第4.3.1节和第4.3.2节所述，也允许使用其他标题（例如，主机）。
The OPTIONS response consists of a status line as described in section 4.3.3 followed by a series of header field names-value pairs optionally followed by an opt-body. Multiple values in the value field MUST be separated by commas. If an opt-body is present in the OPTIONS response, the Opt-body-type header describes the format of the opt-body.
选项响应包括第4.3.3节所述的状态行，后跟一系列标题字段名称值对（可选）和选项正文。值字段中的多个值必须用逗号分隔。如果OPTIONS响应中存在opt body，opt body type标题将描述opt body的格式。
The OPTIONS headers supported in this version of the protocol are:
此版本的协议支持的选项标题包括：
-- Methods:
--方法：
The method that is supported by this service. This header MUST be included in the OPTIONS response. The OPTIONS method MUST NOT be in the Methods' list since it MUST be supported by all the ICAP server implementations. Each service should have a distinct URI and support only one method in addition to OPTIONS (see Section 6.4).
此服务支持的方法。此标题必须包含在选项响应中。选项方法不能在方法列表中，因为所有ICAP服务器实现都必须支持它。每个服务都应该有一个不同的URI，并且除了选项之外，只支持一个方法（参见第6.4节）。
For example: Methods: RESPMOD
例如：方法：RESPMOD
-- Service:
--服务：
A text description of the vendor and product name. This header MAY be included in the OPTIONS response.
供应商和产品名称的文本说明。此标题可能包含在选项响应中。
For example: Service: XYZ Technology Server 1.0
例如：服务：XYZ技术服务器1.0
-- ISTag:
--ISTag：
See section 4.7 for details. This header MUST be included in the OPTIONS response.
详见第4.7节。此标题必须包含在选项响应中。
For example: ISTag: "5BDEEEA9-12E4-2"
例如：ISTag：“5BDEEA9-12E4-2”
-- Encapsulated:
--封装：
This header MUST be included in the OPTIONS response; see Section 4.4.
此标题必须包含在选项响应中；见第4.4节。
For example: Encapsulated: opt-body=0
例如：封装：opt body=0
-- Opt-body-type:
--可选车身类型：
A token identifying the format of the opt-body. (Valid opt-body types are not defined by ICAP.) This header MUST be included in the OPTIONS response ONLY if an opt-body type is present.
标识opt正文格式的标记。（ICAP未定义有效的选项正文类型。）只有在存在选项正文类型时，此标题才能包含在选项响应中。
For example: Opt-body-type: XML-Policy-Table-1.0
例如：Opt body type:XML-Policy-Table-1.0
-- Max-Connections:
--最大连接数：
The maximum number of ICAP connections the server is able to support. This header MAY be included in the OPTIONS response.
服务器能够支持的最大ICAP连接数。此标题可能包含在选项响应中。
For example: Max-Connections: 1500
例如：最大连接数：1500
-- Options-TTL:
--选项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.
此选项响应有效的时间（秒）。如果未指定任何选项，则选项响应不会过期。此标题可能包含在选项响应中。一旦选项TTL过期，ICAP客户端可以重新发出选项请求。
For example: Options-TTL: 3600
例如：选项TTL:3600
-- Date:
--日期：
The server's clock, specified as an RFC 1123 compliant date/time string. This header MAY be included in the OPTIONS response.
服务器的时钟，指定为符合RFC 1123的日期/时间字符串。此标题可能包含在选项响应中。
For example:
Date: Fri, 15 Jun 2001 04:33:55 GMT
For example:
Date: Fri, 15 Jun 2001 04:33:55 GMT
-- Service-ID:
--服务ID:
A short label identifying the ICAP service. It MAY be used in attribute header names. This header MAY be included in the OPTIONS response.
标识ICAP服务的短标签。它可以用在属性头名称中。此标题可能包含在选项响应中。
For example: Service-ID: xyztech
例如：服务ID:xyztech
-- Allow:
--允许：
A directive declaring a list of optional ICAP features that this server has implemented. This header MAY be included in the OPTIONS response. In this document we define the value "204" to indicate that the ICAP server supports a 204 response.
声明此服务器已实现的可选ICAP功能列表的指令。此标题可能包含在选项响应中。在本文档中，我们定义值“204”以指示ICAP服务器支持204响应。
For example: Allow: 204
例如：Allow:204
-- Preview:
--预览：
The number of bytes to be sent by the ICAP client during a preview. This header MAY be included in the OPTIONS response.
预览期间ICAP客户端发送的字节数。此标题可能包含在选项响应中。
For example: Preview: 1024
例如：预览：1024
-- Transfer-Preview:
--传输预览：
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服务器的文件扩展名列表。此标题可能包含在选项响应中。多个文件扩展名值应以逗号分隔。通配符值“*”指定任何其他传输-*头中未指定的所有文件扩展名的默认行为（见下文）。
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服务器的文件扩展名列表。此标题可能包含在选项响应中。多个文件扩展名应以逗号分隔。
For example: Transfer-Ignore: html
例如：Transfer-Ignore: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服务器的文件扩展名列表。此标题可能包含在选项响应中。多个文件扩展名值应以逗号分隔。
For example: Transfer-Complete: asp, bat, exe, com, ole
例如：传输完成：asp、bat、exe、com、ole
Note: If any of Transfer-* are sent, exactly one of them MUST contain the wildcard value "*" to specify the default. If no Transfer-* are sent, all responses will be sent in their entirety (without Preview).
注意：如果发送了Transfer-*中的任何一个，则其中必须有一个包含通配符值“*”以指定默认值。如果未发送传输-*，所有响应将全部发送（无预览）。
In example 5, an ICAP Client sends an OPTIONS Request to an ICAP Service named icap.server.net/sample-service in order to get configuration information for the service provided.
在示例5中，ICAP客户端向名为ICAP.server.net/sample-Service的ICAP服务发送选项请求，以获取所提供服务的配置信息。
ICAP OPTIONS Example 5 - ICAP OPTIONS Request
----------------------------------------------------------------
OPTIONS icap://icap.server.net/sample-service ICAP/1.0
Host: icap.server.net
User-Agent: BazookaDotCom-ICAP-Client-Library/2.3
ICAP OPTIONS Example 5 - ICAP OPTIONS Request
----------------------------------------------------------------
OPTIONS icap://icap.server.net/sample-service ICAP/1.0
Host: icap.server.net
User-Agent: BazookaDotCom-ICAP-Client-Library/2.3
----------------------------------------------------------------
----------------------------------------------------------------
ICAP OPTIONS Example 5 - ICAP OPTIONS Response
----------------------------------------------------------------
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Methods: RESPMOD
Service: FOO Tech Server 1.0
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: null-body=0
Max-Connections: 1000
Options-TTL: 7200
Allow: 204
Preview: 2048
Transfer-Complete: asp, bat, exe, com
Transfer-Ignore: html
Transfer-Preview: *
ICAP OPTIONS Example 5 - ICAP OPTIONS Response
----------------------------------------------------------------
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Methods: RESPMOD
Service: FOO Tech Server 1.0
ISTag: "W3E4R7U9-L2E4-2"
Encapsulated: null-body=0
Max-Connections: 1000
Options-TTL: 7200
Allow: 204
Preview: 2048
Transfer-Complete: asp, bat, exe, com
Transfer-Ignore: html
Transfer-Preview: *
----------------------------------------------------------------
----------------------------------------------------------------
ICAP servers' responses MAY be cached by ICAP clients, just as any other surrogate might cache HTTP responses. Similar to HTTP, ICAP clients MAY always store a successful response (see sections 4.8.2 and 4.9.2) as a cache entry, and MAY return it without validation if it is fresh. ICAP servers use the caching directives described in HTTP/1.1 [4].
ICAP服务器的响应可以由ICAP客户端缓存，就像任何其他代理可以缓存HTTP响应一样。与HTTP类似，ICAP客户端可能始终将成功响应（请参阅第4.8.2节和第4.9.2节）存储为缓存项，如果响应是新的，则可能会在未经验证的情况下返回该响应。ICAP服务器使用HTTP/1.1[4]中描述的缓存指令。
In Request Modification mode, the ICAP server MAY include caching directives in the ICAP header section of the ICAP response (NOT in the encapsulated HTTP request of the ICAP message body). In Response
在请求修改模式下，ICAP服务器可以在ICAP响应的ICAP头部分（不在ICAP消息体的封装HTTP请求中）包含缓存指令。作为回应
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响应中的HTTP缓存指令（不在ICAP头部分）。因此，对于REQMOD，ICAP客户端应该在ICAP头中查找缓存指令，对于RESPMOD，应该在封装的HTTP响应中查找缓存指令。
In cases where an ICAP server returns a modified version of an object created by an origin server, such as in Response Modification mode, the expiration of the ICAP-modified object MUST NOT be longer than that of the origin object. In other words, ICAP servers MUST NOT extend the lifetime of origin server objects, but MAY shorten it.
在ICAP服务器返回源服务器创建的对象的修改版本的情况下，例如在响应修改模式下，ICAP修改对象的过期时间不得超过源对象的过期时间。换句话说，ICAP服务器不能延长源服务器对象的生存期，但可能会缩短它。
In cases where the ICAP server is the authoritative source of an ICAP response, such as in Request Modification mode, the ICAP server is not restricted in its expiration policy.
在ICAP服务器是ICAP响应的权威源的情况下，例如在请求修改模式下，ICAP服务器的过期策略不受限制。
Note that the ISTag response-header may also be used to providing caching hints to clients; see Section 4.7.
注意，ISTag响应头还可用于向客户端提供缓存提示；见第4.7节。
The definition of the ICAP protocol itself only describes two different adaptation channels: modification (and satisfaction) of requests, and modifications of replies. However, an ICAP client implementation is likely to actually distinguish among four different classes of adaptation:
ICAP协议本身的定义仅描述了两种不同的适应渠道：请求的修改（和满足）和回复的修改。然而，ICAP客户端实现可能实际上区分四种不同的适应类型：
1. Adaptation of client requests. This is adaptation done every time a request arrives from a client. This is adaptation done when a request is "on its way into the cache". Factors such as the state of the objects currently cached will determine whether or not this request actually gets forwarded to an origin server (instead of, say, getting served off the cache's disk). An example of this type of adaptation would be special access control or authentication services that must be performed on a per-client basis.
1. 客户请求的调整。这是每次从客户端收到请求时都要进行的调整。这是在请求“在进入缓存的途中”时完成的。诸如当前缓存对象的状态等因素将决定此请求是否实际转发到源服务器（而不是从缓存的磁盘获得服务）。这种适应的一个例子是必须在每个客户机的基础上执行的特殊访问控制或身份验证服务。
2. Adaptation of requests on their way to an origin server. Although this type of adaptation is also an adaptation of requests similar to (1), it describes requests that are "on their way out of the cache"; i.e., if a request actually requires that an origin server be contacted. These adaptation requests are not necessarily specific to particular clients. An example would be addition of "Accept:" headers for special devices; these adaptations can potentially apply to many clients.
2. 请求在发送到源服务器的过程中进行自适应。尽管这种类型的自适应也是与（1）类似的请求自适应，但它描述了“从缓存中移出”的请求；i、 例如，如果请求实际需要联系源服务器。这些适应请求不一定特定于特定客户机。例如，为特殊设备添加“接受：”标题；这些调整可能适用于许多客户机。
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），是响应的适应，但它是特定于客户端的。客户机应答自适应是每次向客户机提供对象时所需的自适应，即使所有应答都来自磁盘外的同一缓存对象。广告插入是这种适应的一种常见形式；e、 例如，如果一个很少更改的流行（缓存）对象每次从磁盘提供给客户端时都需要插入不同的ad。注意，类型（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客户端实现至关重要，但对于ICAP协议本身来说，这种区别并不重要。从ICAP服务器的角度来看，请求就是一个请求——ICAP服务器不关心是什么策略导致ICAP客户端生成请求。因此，为了简单起见，我们没有在ICAP中明确这四个通道。
Section 4 described "on the wire" protocol errors that MUST be standardized across implementations to ensure interoperability. In this section, we describe errors that are communicated between ICAP software and the clients and servers on which they are implemented. Although such errors are implementation dependent and do not necessarily need to be standardized because they are "within the box", they are presented here as advice to future implementors based on past implementation experience.
第4节描述了“在线”协议错误，这些错误必须跨实现标准化，以确保互操作性。在本节中，我们将描述ICAP软件与实现它们的客户端和服务器之间通信的错误。尽管这些错误依赖于实现，并且不一定需要标准化，因为它们“在盒子里”，但本文根据过去的实现经验将它们作为建议提供给未来的实现者。
Error name Value
====================================================
ICAP_CANT_CONNECT 1000
ICAP_SERVER_RESPONSE_CLOSE 1001
ICAP_SERVER_RESPONSE_RESET 1002
ICAP_SERVER_UNKNOWN_CODE 1003
ICAP_SERVER_UNEXPECTED_CLOSE_204 1004
ICAP_SERVER_UNEXPECTED_CLOSE 1005
Error name Value
====================================================
ICAP_CANT_CONNECT 1000
ICAP_SERVER_RESPONSE_CLOSE 1001
ICAP_SERVER_RESPONSE_RESET 1002
ICAP_SERVER_UNKNOWN_CODE 1003
ICAP_SERVER_UNEXPECTED_CLOSE_204 1004
ICAP_SERVER_UNEXPECTED_CLOSE 1005
1000 ICAP_CANT_CONNECT: "Cannot connect to ICAP server".
1000 ICAP\u无法连接：“无法连接到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服务器在读取响应时关闭连接”。
The ICAP server TCP-shutdowns the connection before the ICAP client can send all the body data.
ICAP服务器TCP在ICAP客户端可以发送所有正文数据之前关闭连接。
1002 ICAP_SERVER_RESPONSE_RESET: "ICAP Server reset connection while reading response".
1002 ICAP_服务器_响应_重置：“读取响应时ICAP服务器重置连接”。
The ICAP server TCP-reset the connection before the ICAP client can send all the body data.
ICAP服务器TCP在ICAP客户端可以发送所有正文数据之前重置连接。
1003 ICAP_SERVER_UNKNOWN_CODE: "ICAP Server sent unknown response code".
1003 ICAP_服务器_未知_代码：“ICAP服务器发送未知响应代码”。
An unknown ICAP response code (see Section 4.x) was received by the ICAP client.
ICAP客户端收到未知的ICAP响应代码（见第4.x节）。
1004 ICAP_SERVER_UNEXPECTED_CLOSE_204: "ICAP Server closed connection on 204 without 'Connection: close' header".
1004 ICAP_服务器_意外_关闭_204:“ICAP服务器在204上关闭了连接，但没有'connection:CLOSE'头”。
An ICAP server MUST send the "Connection: close" header if intends to close after the current transaction.
如果要在当前事务之后关闭，ICAP服务器必须发送“Connection:close”标头。
1005 ICAP_SERVER_UNEXPECTED_CLOSE: "ICAP Server closed connection as ICAP client wrote body preview".
1005 ICAP_服务器\u意外\u关闭：“ICAP客户端写入正文预览时，ICAP服务器关闭了连接”。
For simplicity, ICAP messages MUST use the "chunked" transfer-encoding within the encapsulated body section as defined in HTTP/1.1 [4]. This requires that ICAP client implementations convert incoming objects "on the fly" to chunked from whatever transfer-encoding on which they arrive. However, the transformation is simple:
为简单起见，ICAP消息必须在HTTP/1.1[4]中定义的封装正文部分中使用“分块”传输编码。这要求ICAP客户机实现将传入的对象“动态”转换为来自它们到达的任何传输编码的分块。但是，转换很简单：
- For objects arriving using "Content-Length" headers, one big chunk can be created of the same size as indicated in the Content-Length header.
- 对于使用“Content-Length”标题到达的对象，可以创建一个与Content-Length标题中指示的大小相同的大块。
- For objects arriving using a TCP close to signal the end of the object, each incoming group of bytes read from the OS can be converted into a chunk (by writing the length of the bytes read, followed by the bytes themselves)
- 对于使用TCP接近对象结束信号到达的对象，可以将从操作系统读取的每个传入字节组转换为块（通过写入读取的字节长度，后跟字节本身）
- For objects arriving using chunked encoding, they can be retransmitted as is (without re-chunking).
- 对于使用分块编码到达的对象，它们可以按原样重新传输（无需重新分块）。
ICAP servers SHOULD assign unique URIs to each service they provide, even if such services might theoretically be differentiated based on their method. In other words, a REQMOD and RESPMOD service should never have the same URI, even if they do something that is conceptually the same.
ICAP服务器应为其提供的每个服务分配唯一的URI，即使理论上可能根据其方法对这些服务进行区分。换句话说，REQMOD和RESPMOD服务永远不应该具有相同的URI，即使它们所做的事情在概念上是相同的。
This situation in ICAP is similar to that found in HTTP where it might, in theory, be possible to perform a GET or a POST to the same URI and expect two different results. This kind of overloading of URIs only causes confusion and should be avoided.
ICAP中的这种情况与HTTP中的情况类似，在HTTP中，理论上可能对同一URI执行GET或POST，并期望得到两种不同的结果。URI的这种重载只会引起混乱，应该避免。
Authentication in ICAP is very similar to proxy authentication in HTTP as specified in RFC 2617. Specifically, the following rules apply:
ICAP中的身份验证与RFC 2617中指定的HTTP中的代理身份验证非常相似。具体而言，以下规则适用：
- WWW-Authenticate challenges and responses are for end-to-end authentication between a client (user) and an origin server. As any proxy, ICAP clients and ICAP servers MUST forward these headers without modification.
- WWW身份验证挑战和响应用于客户端（用户）和源服务器之间的端到端身份验证。作为任何代理，ICAP客户端和ICAP服务器必须转发这些头，而不进行修改。
- If authentication is required between an ICAP client and ICAP server, hop-by-hop Proxy Authentication as described in RFC 2617 MUST be used.
- 如果需要在ICAP客户端和ICAP服务器之间进行身份验证，则必须使用RFC 2617中所述的逐跳代理身份验证。
There are potential applications where a user (as opposed to ICAP client) might have rights to access an ICAP service. In this version of the protocol, we assume that ICAP clients and ICAP servers are under the same administrative domain, and contained in a single trust domain. Therefore, in these cases, we assume that it is sufficient for users to authenticate themselves to the ICAP client (which is a surrogate from the point of view from the user). This type of authentication will also be Proxy Authentication as described in RFC 2617.
在某些潜在应用程序中，用户（与ICAP客户端相反）可能有权访问ICAP服务。在此版本的协议中，我们假设ICAP客户端和ICAP服务器位于同一管理域下，并且包含在单个信任域中。因此，在这些情况下，我们假设用户向ICAP客户端（从用户的角度来看，ICAP客户端是代理）进行身份验证就足够了。这种类型的身份验证也将是RFC 2617中描述的代理身份验证。
This standard explicitly excludes any method for a user to authenticate directly to an ICAP server; the ICAP client MUST be involved as described above.
本标准明确排除了用户直接向ICAP服务器进行身份验证的任何方法；ICAP客户必须如上所述参与。
Users of ICAP should note well that ICAP messages are not encrypted for transit by default. In the absence of some other form of encryption at the link or network layers, eavesdroppers may be able to record the unencrypted transactions between ICAP clients and servers. As described in Section 4.3.1, the Upgrade header MAY be used to negotiate transport-layer security for an ICAP connection [5].
ICAP的用户应该注意，默认情况下，ICAP消息不会加密以进行传输。在链路层或网络层没有其他形式的加密的情况下，窃听者可以记录ICAP客户端和服务器之间未加密的事务。如第4.3.1节所述，升级报头可用于协商ICAP连接的传输层安全性[5]。
Note also that end-to-end encryption between a client and origin server is likely to preclude the use of value-added services by intermediaries such as surrogates. An ICAP server that is unable to decrypt a client's messages will, of course, be unable to perform any transformations on it.
还请注意，客户端和源服务器之间的端到端加密可能会阻止代理等中介使用增值服务。当然，无法解密客户端消息的ICAP服务器将无法对其执行任何转换。
Normal HTTP surrogates, when operating correctly, should not affect the end-to-end semantics of messages that pass through them. This forms a well-defined criterion to validate that a surrogate is working correctly: a message should look the same before the surrogate as it does after the surrogate.
正常HTTP代理在正常运行时，不应影响通过它们的消息的端到端语义。这形成了一个定义良好的标准来验证代理是否正常工作：消息在代理前的外观应与在代理后的外观相同。
In contrast, ICAP is meant to cause changes in the semantics of messages on their way from origin servers to users. The criteria for a correctly operating surrogate are no longer as easy to define. This will make validation of ICAP services significantly more difficult. Incorrect adaptations may lead to security vulnerabilities that were not present in the unadapted content.
相比之下，ICAP的目的是在消息从源服务器传递到用户的过程中改变消息的语义。正确操作代理的标准不再那么容易定义。这将大大增加ICAP服务验证的难度。不正确的调整可能会导致未调整内容中不存在的安全漏洞。
This section describes some of our design decisions in more detail, and describes the ideas and motivations behind them. This section does not define protocol requirements, but hopefully sheds light on the requirements defined in previous sections. Nothing in this section carries the "force of law" or is part of the formal protocol specification.
本节更详细地描述了我们的一些设计决策，并描述了它们背后的想法和动机。本节不定义协议需求，但希望能阐明前面章节中定义的需求。本节中的任何内容均不具有“法律效力”，也不属于正式协议规范的一部分。
In general, our guiding principle was to make ICAP the simplest possible protocol that would do the job, and no simpler. Some features were rejected where alternative (non-protocol-based) solutions could be found. In addition, we have intentionally left a number of issues at the discretion of the implementor, where we believe that doing so does not compromise interoperability.
总的来说，我们的指导原则是使ICAP成为完成这项工作的最简单的协议，而不是更简单的协议。在可以找到替代（非基于协议）解决方案的情况下，某些功能被拒绝。此外，我们有意让实现者自行决定一些问题，我们认为这样做不会损害互操作性。
ICAP was initially designed as an application-layer protocol built to run on top of HTTP. This was desirable for a number of reasons. HTTP is well-understood in the community and has enjoyed significant investments in software infrastructure (clients, servers, parsers, etc.). Our initial designs focused on leveraging that existing work; we hoped that it would be possible to implement ICAP services simply, using CGI scripts run by existing web servers.
ICAP最初设计为一个应用层协议，构建为在HTTP之上运行。出于若干原因，这是可取的。HTTP在社区中得到了很好的理解，并在软件基础设施（客户端、服务器、解析器等）方面进行了大量投资。我们最初的设计侧重于利用现有的工作；我们希望可以使用现有web服务器运行的CGI脚本简单地实现ICAP服务。
However, the devil (as always) proved to be in the details. Certain features that we considered important were impossible to implement with HTTP. For example, ICAP clients can stop and wait for a "100 Continue" message in the midst of a message-body; HTTP clients may only wait between the header and body. In addition, certain transformations of HTTP messages by surrogates are legal (and harmless for HTTP), but caused problems with ICAP's "header-in-header" encapsulation and other features.
然而，事实证明，魔鬼（一如既往）存在于细节之中。我们认为重要的某些特性不可能用HTTP实现。例如，ICAP客户端可以在消息正文中停止并等待“100 Continue”消息；HTTP客户端只能在标头和正文之间等待。此外，代理对HTTP消息的某些转换是合法的（对HTTP无害），但会导致ICAP的“header-In-header”封装和其他功能出现问题。
Ultimately, we decided that the tangle of workarounds required to fit ICAP into HTTP was more complex and confusing than moving away from HTTP and defining a new (but similar) protocol.
最终，我们决定将ICAP融入HTTP所需的复杂变通方法比离开HTTP并定义一个新的（但类似的）协议更加复杂和混乱。
Chunking is mandatory in ICAP encapsulated bodies for three reasons. First, efficiency is important, and the chunked encoding allows both the client and server to keep the transport-layer connection open for later reuse. Second, ICAP servers (and their developers) should be encouraged to produce "incremental" responses where possible, to reduce the latency perceived by users. Chunked encoding is the only way to support this type of implementation. Finally, by
在ICAP封装体中，分块是强制性的，原因有三。首先，效率很重要，分块编码允许客户端和服务器保持传输层连接的开放性，以便以后重用。其次，应鼓励ICAP服务器（及其开发人员）尽可能生成“增量”响应，以减少用户感知的延迟。分块编码是支持这种类型实现的唯一方法。最后，通过
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.
虽然必须对封装的实体进行分块，但不会对封装的头进行分块。这一决定有两个原因。首先，在将分块的HTTP消息体封装在ICAP消息中的情况下，ICAP客户端（HTTP服务器）可以直接将其从HTTP客户端复制到ICAP服务器，而无需取消分块，然后重新对其进行分块。其次，许多头解析器实现很难处理来自多个块的头。本文档的早期草稿要求块边界不在头中。为了清楚起见，封装头的分块是不允许的。
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消息的封装头部分，不使用分块传输编码有一个缺点。具体地说，解析器事先不知道有多少报头数据（例如，用于缓冲区分配）。由于第8.2节所述的原因，ICAP不允许在标题部分进行分块。作为补偿，“null body”指令允许确定最终标头的长度，尽管它没有被分块。
[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", RFC 2396, August 1998.
[1] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法和语义”，RFC 2396，1998年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[3] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[4] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，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.
[5] Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 28172000年5月。
ICAP is based on an original idea by John Martin and Peter Danzig. Many individuals and organizations have contributed to the development of ICAP, including the following contributors (past and present):
ICAP基于John Martin和Peter Danzig的原始想法。许多个人和组织为ICAP的发展做出了贡献，包括以下贡献者（过去和现在）：
Lee Duggs Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
Lee Duggs Network Appliance，Inc.东爪哇州森尼维尔495号，美国加利福尼亚州94089
Phone: (408) 822-6000 EMail: lee.duggs@netapp.com
电话：（408）822-6000电子邮件：李。duggs@netapp.com
Paul Eastham Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
Paul Eastham Network Appliance，Inc.美国加利福尼亚州桑尼维尔东爪哇495博士，邮编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
Debbie Futcher Network Appliance，Inc.东爪哇州森尼维尔495号，美国加利福尼亚州94089
Phone: (408) 822-6000 EMail: deborah.futcher@netapp.com
电话：（408）822-6000电子邮件：黛博拉。futcher@netapp.com
Don Gillies Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
Don Gillies Network Appliance，Inc.东爪哇州森尼维尔495号美国加利福尼亚州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
Steven La Network Appliance，Inc.东爪哇州森尼维尔495号美国加利福尼亚州94089
Phone: (408) 822-6000 EMail: steven.la@netapp.com
电话：（408）822-6000电子邮件：史蒂文。la@netapp.com
John Martin Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
John Martin Network Appliance，Inc.东爪哇州森尼维尔495号美国加利福尼亚州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
Jeff Merrick Network Appliance，Inc.东爪哇州森尼维尔495号美国加利福尼亚州94089
Phone: (408) 822-6000 EMail: jeffrey.merrick@netapp.com
电话：（408）822-6000电子邮件：杰弗里。merrick@netapp.com
John Schuster Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
约翰·舒斯特网络设备有限公司，东爪哇州森尼维尔495号，美国加利福尼亚州94089
Phone: (408) 822-6000 EMail: john.schuster@netapp.com
电话：（408）822-6000电子邮件：约翰。schuster@netapp.com
Edward Sharp Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA
Edward Sharp Network Appliance，Inc.东爪哇州森尼维尔495号美国加利福尼亚州94089
Phone: (408) 822-6000 EMail: edward.sharp@netapp.com
电话：（408）822-6000电子邮件：爱德华。sharp@netapp.com
Peter Danzig Akamai Technologies 1400 Fashion Island Blvd San Mateo, CA 94404 USA
Peter Danzig Akamai Technologies美国加利福尼亚州圣马特奥时尚岛大道1400号，邮编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
马克·诺丁汉Akamai Technologies美国加利福尼亚州圣马特奥时尚岛大道1400号，邮编94404
Phone: (650) 372-5757 EMail: mnot@akamai.com
电话：（650）372-5757电子邮件：mnot@akamai.com
Nitin Sharma Akamai Technologies 1400 Fashion Island Blvd San Mateo, CA 94404 USA
美国加利福尼亚州圣马特奥时尚岛大道1400号Nitin Sharma Akamai Technologies邮编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
Hilarie Orman Novell，Inc.美国犹他州南普罗沃1700东122号，邮编84606
Phone: (801) 861-7021 EMail: horman@novell.com
电话：（801）861-7021电子邮件：horman@novell.com
Craig Blitz Novell, Inc. 122 East 1700 South Provo, UT 84606 USA
Craig Blitz Novell，Inc.美国犹他州南普罗沃1700东122号，邮编84606
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东122号，邮编84606
Phone: (801) 861-7021 EMail: garyt@novell.com
电话：（801）861-7021电子邮件：garyt@novell.com
Andre Beck Bell Laboratories / Lucent Technologies 101 Crawfords Corner Road Holmdel, New Jersey 07733-3030
Andre Beck Bell Laboratories/Lucent Technologies新泽西州霍尔德尔市克劳福德角路101号07733-3030
Phone: (732) 332-5983 EMail: abeck@bell-labs.com
电话：（732）332-5983电子邮件：abeck@bell-实验室网站
Markus Hofmann Bell Laboratories / Lucent Technologies 101 Crawfords Corner Road Holmdel, New Jersey 07733-3030
Markus Hofmann Bell Laboratories/Lucent Technologies 101 Crawfords Corner Road Holmdel，新泽西州07733-3030
Phone: (732) 332-5983 EMail: hofmann@bell-labs.com
电话：（732）332-5983电子邮件：hofmann@bell-实验室网站
David Bryant CacheFlow, Inc. 650 Almanor Avenue Sunnyvale, California 94086
David Bryant CacheFlow，Inc.加利福尼亚州桑尼维尔阿尔马诺大道650号，邮编94086
Phone: (888) 462-3568 EMail: david.bryant@cacheflow.com
电话：（888）462-3568电子邮件：大卫。bryant@cacheflow.com
Appendix A BNF Grammar for ICAP Messages
附录A ICAP消息的BNF语法
This grammar is specified in terms of the augmented Backus-Naur Form (BNF) similar to that used by the HTTP/1.1 specification (See Section 2.1 of [4]). Implementors will need to be familiar with the notation in order to understand this specification.
该语法是根据增广巴科斯诺尔形式（BNF）指定的，类似于HTTP/1.1规范所使用的形式（见[4]第2.1节）。为了理解这个规范，实现者需要熟悉这个符号。
Many header values (where noted) have exactly the same grammar and semantics as in HTTP/1.1. We do not reproduce those grammars here.
许多头值（如有说明）的语法和语义与HTTP/1.1中的完全相同。我们这里不复制这些语法。
ICAP-Version = "ICAP/1.0"
ICAP Version=“ICAP/1.0”
ICAP-Message = Request | Response
ICAP消息=请求|响应
Request = Request-Line *(Request-Header CRLF) CRLF [ Request-Body ]
请求=请求行*（请求头CRLF）CRLF[请求正文]
Request-Line = Method SP ICAP_URI SP ICAP-Version CRLF
Request-Line = Method SP ICAP_URI SP ICAP-Version CRLF
Method = "REQMOD" ; Section 4.8
| "RESPMOD" ; Section 4.9
| "OPTIONS" ; Section 4.10
| Extension-Method ; Section 4.3.2
Method = "REQMOD" ; Section 4.8
| "RESPMOD" ; Section 4.9
| "OPTIONS" ; Section 4.10
| Extension-Method ; Section 4.3.2
Extension-Method = token
Extension-Method = token
ICAP_URI = Scheme ":" Net_Path [ "?" Query ] ; Section 4.2
ICAP_URI = Scheme ":" Net_Path [ "?" Query ] ; Section 4.2
Scheme = "icap"
Scheme = "icap"
Net_Path = "//" Authority [ Abs_Path ]
Net_Path = "//" Authority [ Abs_Path ]
Authority = [ userinfo "@" ] host [ ":" port ]
Authority = [ userinfo "@" ] host [ ":" port ]
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
; Header fields specific to requests
Request-Field-Name = "Authorization" ; Section 4.3.2
| "Allow" ; Section 4.3.2
| "From" ; Section 4.3.2
| "Host" ; Section 4.3.2
| "Referer" ; Section 4.3.2
| "User-Agent" ; Section 4.3.2 | "Preview" ; Section 4.5
|“用户代理”；第4.3.2节“预览”；第4.5节
; Header fields common to both requests and responses
Common-Field-Name = "Cache-Control" ; Section 4.3.1
| "Connection" ; Section 4.3.1
| "Date" ; Section 4.3.1
| "Expires" ; Section 4.3.1
| "Pragma" ; Section 4.3.1
| "Trailer" ; Section 4.3.1
| "Upgrade" ; Section 4.3.1
| "Encapsulated" ; Section 4.4
| Extension-Field-Name ; Section 4.3
; Header fields common to both requests and responses
Common-Field-Name = "Cache-Control" ; Section 4.3.1
| "Connection" ; Section 4.3.1
| "Date" ; Section 4.3.1
| "Expires" ; Section 4.3.1
| "Pragma" ; Section 4.3.1
| "Trailer" ; Section 4.3.1
| "Upgrade" ; Section 4.3.1
| "Encapsulated" ; Section 4.4
| Extension-Field-Name ; Section 4.3
Extension-Field-Name = "X-" token
扩展字段Name=“X-”令牌
Generic-Field-Value = *( Generic-Field-Content | LWS )
Generic-Field-Content = <the OCTETs making up the field-value
and consisting of either *TEXT or
combinations of token, separators,
and quoted-string>
Generic-Field-Value = *( Generic-Field-Content | LWS )
Generic-Field-Content = <the OCTETs making up the field-value
and consisting of either *TEXT or
combinations of token, separators,
and quoted-string>
Request-Body = *OCTET ; See Sections 4.4 and 4.5 for semantics
Request-Body = *OCTET ; See Sections 4.4 and 4.5 for semantics
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]
Status-Code = "100" ; Section 4.5
| "101" ; Section 10.1.2 of [4]
| "200" ; Section 10.2.1 of [4]
| "201" ; Section 10.2.2 of [4]
| "202" ; Section 10.2.3 of [4]
| "203" ; Section 10.2.4 of [4]
| "204" ; Section 4.6
| "205" ; Section 10.2.6 of [4]
| "206" ; Section 10.2.7 of [4]
| "300" ; Section 10.3.1 of [4]
| "301" ; Section 10.3.2 of [4]
| "302" ; Section 10.3.3 of [4]
| "303" ; Section 10.3.4 of [4]
| "304" ; Section 10.3.5 of [4]
| "305" ; Section 10.3.6 of [4]
| "306" ; Section 10.3.7 of [4]
| "307" ; Section 10.3.8 of [4]
| "400" ; Section 4.3.3
| "401" ; Section 10.4.2 of [4]
| "402" ; Section 10.4.3 of [4]
| "403" ; Section 10.4.4 of [4]
| "404" ; Section 4.3.3
| "405" ; Section 4.3.3
| "406" ; Section 10.4.7 of [4]
| "407" ; Section 10.4.8 of [4]
| "408" ; Section 4.3.3
| "409" ; Section 10.4.10 of [4]
| "410" ; Section 10.4.11 of [4]
| "411" ; Section 10.4.12 of [4]
| "412" ; Section 10.4.13 of [4]
| "413" ; Section 10.4.14 of [4]
| "414" ; Section 10.4.15 of [4]
| "415" ; Section 10.4.16 of [4]
| "416" ; Section 10.4.17 of [4]
| "417" ; Section 10.4.18 of [4]
| "500" ; Section 4.3.3
| "501" ; Section 4.3.3
| "502" ; Section 4.3.3
| "503" ; Section 4.3.3
| "504" ; Section 10.5.5 of [4]
| "505" ; Section 4.3.3
| Extension-Code
| "400" ; Section 4.3.3
| "401" ; Section 10.4.2 of [4]
| "402" ; Section 10.4.3 of [4]
| "403" ; Section 10.4.4 of [4]
| "404" ; Section 4.3.3
| "405" ; Section 4.3.3
| "406" ; Section 10.4.7 of [4]
| "407" ; Section 10.4.8 of [4]
| "408" ; Section 4.3.3
| "409" ; Section 10.4.10 of [4]
| "410" ; Section 10.4.11 of [4]
| "411" ; Section 10.4.12 of [4]
| "412" ; Section 10.4.13 of [4]
| "413" ; Section 10.4.14 of [4]
| "414" ; Section 10.4.15 of [4]
| "415" ; Section 10.4.16 of [4]
| "416" ; Section 10.4.17 of [4]
| "417" ; Section 10.4.18 of [4]
| "500" ; Section 4.3.3
| "501" ; Section 4.3.3
| "502" ; Section 4.3.3
| "503" ; Section 4.3.3
| "504" ; Section 10.5.5 of [4]
| "505" ; Section 4.3.3
| Extension-Code
Extension-Code = 3DIGIT
Extension-Code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
Reason-Phrase = *<TEXT, excluding CR, LF>
Response-Header = Response-Fields ":" [ Generic-Field-Value ]
响应头=响应字段“：“[通用字段值]
Response-Fields = Response-Field-Name | Common-Field-Name
响应字段=响应字段名|公共字段名
Response-Field-Name = "Server" ; Section 4.3.3 | "ISTag" ; Section 4.7
响应字段名称=“服务器”；第4.3.3节|“ISTag”；第4.7节
Response-Body = *OCTET ; See Sections 4.4 and 4.5 for semantics
Response-Body = *OCTET ; See Sections 4.4 and 4.5 for semantics
Authors' Addresses
作者地址
Jeremy Elson University of California Los Angeles Department of Computer Science 3440 Boelter Hall Los Angeles CA 90095
杰瑞米埃尔森加利福尼亚大学加利福尼亚大学洛杉矶计算机系3440博尔特厅洛杉矶CA 90095
Phone: (310) 206-3925 EMail: jelson@cs.ucla.edu
电话：（310）206-3925电子邮件：jelson@cs.ucla.edu
Alberto Cerpa University of California Los Angeles Department of Computer Science 3440 Boelter Hall Los Angeles CA 90095
阿尔伯托CePa加利福尼亚大学洛杉矶计算机科学系3440博尔特厅洛杉矶CA 90095
Phone: (310) 206-3925 EMail: cerpa@cs.ucla.edu
电话：（310）206-3925电子邮件：cerpa@cs.ucla.edu
ICAP discussion currently takes place at icap-discussions@yahoogroups.com. For more information, see http://groups.yahoo.com/group/icap-discussions/.
ICAP讨论目前在ICAP上进行-discussions@yahoogroups.com. 有关详细信息，请参阅http://groups.yahoo.com/group/icap-discussions/.
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。