icap协议rfd3507

Network Working Group J. Elson

Request for Comments: 3507 A. Cerpa

Category: Informational UCLA

April 2003

Internet Content Adaptation Protocol (ICAP)

Status of this Memo

This memo provides information for the Internet community. It does

not specify an Internet standard of any kind. Distribution of this

memo is unlimited.

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.

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

RFC 3507 ICAP April 2003

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

Messages.................................15

Messages.........................................16

4.4.2 Encapsulated HTTP Headers................18

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.1 Request..................................27

4.9.3 Examples.................................28

4.10 OPTIONS Method...................................29

4.10.1 OPTIONS request..........................29

4.10.2 OPTIONS response.........................30

7.2 Encryption.......................................38

7.3 Service Validation...............................38

8. Motivations and Design Alternatives....................39

Elson & Cerpa Informational [Page 2]

RFC 3507 ICAP April 2003

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

1. Introduction

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

responsible for all aspects of every client’s request seems to be

move towards architectures that scale better through the use of

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

deployment and the proximity of a given surrogate to the end-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

this document.

Elson & Cerpa Informational [Page 3]

RFC 3507 ICAP April 2003

This type of Remote Procedure Call (RPC) is useful in a number of

ways. For example:

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.

with cooperation from the content provider (as in a content

client’s network provider (as in a surrogate). Examples of these

human languages or to different formats that are appropriate for

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

for viruses before accepting it into its cache.

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

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.

Elson & Cerpa Informational [Page 4]

RFC 3507 ICAP April 2003

There are two major components in our architecture:

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

2. Control of policy -- "When am I supposed to ask for adaptation,

what kind of adaptation do I ask for, and from where?"

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.

Although a necessary building-block, this wire-protocol defined by

ICAP is of limited use without the second part: an accompanying

policy issue is beyond the scope of the current ICAP protocol, but is

manual configuration will be used to define policy. This includes

not be consistent across implementations, as long as the policy

itself is consistent.

IMPORTANT:

Note that at this time, in the absence of a policy-framework, it

performed on messages with the explicit consent of either the

transformation services without the consent of either leads to, at

best, unpredictable results. For more discussion of these issues,

see Section 7.

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].

Elson & Cerpa Informational [Page 5]