INTERNET-DRAFT The ICAP Protocol Group
Expires: May 2001
J. Elson et al.
ICAP the Internet Content Adaptation Protocol
draft-elson-opes-icap-00.txt
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this document is unlimited.
Abstract
ICAP, the Internet Content Adaptation Protocol, is part of an
evolving architecture that facilitates better distribution and
caching for the web. ICAP is, in essence, a lightweight protocol for
executing a "remote procedure call" on HTTP messages. That is, it
allows ICAP clients to pass HTTP messages to ICAP servers for
"adaptation" -- some sort of transformation or other processing. 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.
ICAP is often used in a situation where either a separate HTTP proxy
server or a programmable network device could serve as an alternative
solution. Therefore, ICAP should evolve in a direction of
simplicity, allowing pipelined transfers and reduced communications
costs, compared to a proxy server. ICAP should also evolve in an
open, scalable direction, so that ICAP services can be invoked from
many types of proxied protocols, such as HTTP, FTP, NNTP, and SMTP.
ICAP Protocol Group Expiration: May 2001 [Page 1]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
TABLE OF CONTENTS
1 Introduction
2 Terminology
3 Architecture Overview and Future Work
4 ICAP Overall Operation
4.1 Request Modification
4.2 Response Modification
5 Protocol Semantics
5.1 General Operation
5.2 ICAP URIs
5.3 ICAP Headers
5.3.1 Headers Common to Requests and Responses
5.3.2 Request Headers
5.3.3 Response Headers
5.4 ICAP Bodies: Encapsulation of HTTP Messages
5.4.1 Expected Encapsulated Sections
5.4.2 Encapsulated HTTP Headers
5.5 Message Preview
5.6 "204 No Content" Responses outside of Previews
5.7 Request Modification Mode
5.7.1 Request
5.7.2 Response
5.7.3 Examples
5.8 Response Modification Mode
5.8.1 Request
5.8.2 Response
5.8.3 Examples
5.9 OPTIONS Method
6 Caching
7 Implementation Notes
7.1 Vectoring Points
7.2 Application Level Errors
7.3 Use of Chunked Transfer-Encoding
7.4 Distinct URIs for Distinct Services
8 Security Considerations
8.1 Authentication
8.2 Encryption
8.3 Service Validation
9 References
10 Contact Information and Authors' Addresses
ICAP Protocol Group Expiration: May 2001 [Page 2]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
1 Introduction
As the Internet has grown larger, so has the need for scalable Internet
services. Popular web servers are asked to deliver content to 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.
The old school has become a victim of its own overwhelming success.
To keep pace 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 farm of servers. Content providers
have also begun to employ geographically diverse content distribution
networks that bring servers closer to the "edge" of the network where
clients are attached. On the other side of the coin, client network
providers often employ caches so that local copies of popular objects
can be served instead of repeatedly making the same request of an origin
server.
ICAP, the Internet Content Adaptation Protocol, is part of an evolving
architecture that facilitates better distribution and caching for the
web. ICAP is, in essence, a lightweight protocol for executing a
"remote procedure call" on HTTP messages. That is, it allows ICAP
clients to pass HTTP messages to ICAP servers for "adaptation" -- some
sort of transformation or other processing. 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.
2 Terminology
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 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.
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.
request:
An HTTP request message, as defined in section 5 of HTTP/1.1 [4].
ICAP Protocol Group Expiration: May 2001 [Page 3]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
response:
An HTTP response message, as defined in section 6 of HTTP/1.1 [4].
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.
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, proxy, 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
cacheable 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.
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 Protocol Group Expiration: May 2001 [Page 4]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
ICAP server:
Similar to an HTTP server as described above, except that the
application services ICAP requests.
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 proxy-cache acting on behalf of a user.
3 Architecture Overview and Future Work
This protocol is one piece of a larger architecture we envision that
will enhance scalability of web services by facilitating better
distribution and caching. The key to this architecture is a lightweight
"remote procedure call" that operates on HTTP messages. That is, we
define a method for ICAP clients to pass HTTP messages to ICAP servers
for transformation or other processing. The adapted messages may be
HTTP requests or HTTP responses.
This type of RPC is useful in a number of ways. For example, it might
be used to help scale Internet services, as described below. Second, it
creates a standard interface for adaptation of HTTP messages, allowing
interoperability. The examples we will describe are representative, but
by no means comprehensive.
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. 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.
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 proxy cache). 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).
o Proxy caches 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, if a
user attempts to download an executable program, a proxy cache, acting
as an ICAP client, can ask an external server to check it for viruses
before accepting the object into its cache.
ICAP Protocol Group Expiration: May 2001 [Page 5]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
o Firewalls or proxy caches 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.
In all of these examples, ICAP is helping to reduce the load on the
network, origin servers, or both. 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 proxy caches 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 proxy caches.
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, the 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.
In initial implementations, we expect that implementation-specific
manual configuration will be used to define policy. This includes the
trust relationships between ICAP clients and servers, 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.
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 will allow a standard policy definition
interface complementary to the ICAP transaction interface defined here.
4 ICAP Overall Operation
ICAP Protocol Group Expiration: May 2001 [Page 6]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
ICAP facilitates adaptation of HTTP messages. An adapted message may
either be an HTTP request or an HTTP response. These two methods will
be described below.
4.1 Request Modification
In "request modification" (reqmod) method, an ICAP client sends an HTTP
request to an ICAP server. In general, the ICAP server may either:
1) Send back a modified version of the request. (The ICAP client may
then pipeline the modified request to another ICAP server for
further modification, or perform the modified request by
contacting an origin server.)
2) If there is an error, the ICAP server may choose to send back an
HTTP response to this request. This is often information useful
to the user (i.e. "you are not allowed to view that page").
ICAP clients MUST be able to handle both types of responses. In case
(2), no further processing should be done on the request; e.g., if a
chain of reqmod servers is being used to perform successive
modifications on the request, the request MUST NOT not be further
propagated after an error response is received.
We will illustrate this method with a example: content filtering. A
proxy cache receives a request from a client for a web page from an
origin server. The proxy cache, acting as an ICAP client, sends the
client's request to an ICAP server that performs URI-based content
filtering. If access to the requested URI is allowed, the request is
returned to the ICAP client unmodified. However, if the ICAP server
chooses to disallow access to the requested resources, it may either
1) Modify the request so that it points to a page containing an error
message instead of the original URI.
2) Return an encapsulated HTTP response that indicates an HTTP error.
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.
ICAP Protocol Group Expiration: May 2001 [Page 7]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
Typical data flow:
origin-server
| /|\
| |
5 | | 4
| |
\|/ | 2
ICAP-client --------------> ICAP-resource
(proxy-cache) <-------------- on ICAP-server
| /|\ 3
| |
6 | | 1
| |
\|/ |
client
1. A client makes a request to a ICAP-capable proxy cache (ICAP client)
for an object on an origin server.
2. The proxy cache sends the request to the ICAP server.
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.
If Step 3 returned a request:
4. The Proxy cache sends the request, possibly different from
original client request, to the origin server.
5. The origin server responds to request.
6. The proxy cache sends the reply (from either the ICAP server or the
origin server) to the client.
4.2 Response Modification
Using the "response modification" method, an ICAP client sends an HTTP
response to an ICAP server. The ICAP server modifies this response and
sends it back to the ICAP client. Note that unlike in the previous
method, which sends HTTP requests, this method sends an HTTP *response*
for modification. That response often comes from an origin server.
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.
Typical data flow:
origin-server
ICAP Protocol Group Expiration: May 2001 [Page 8]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
| /|\
| |
3 | | 2
| |
\|/ | 4
ICAP-client --------------> ICAP-resource
(proxy-cache) <-------------- on ICAP-server
| /|\ 5
| |
6 | | 1
| |
\|/ |
client
1. A client makes a request to a ICAP-capable proxy cache (ICAP client)
for an object on an origin server.
2. The proxy cache sends the request to the origin server.
3. The origin server responds to request.
4. The ICAP-capable proxy cache sends the origin server's reply to the
ICAP server.
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.
6. The proxy cache sends the reply, possibly modified from the original
origin server's reply, to the client.
5 Protocol Semantics
5.1 General Operation
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 proxies.
ICAP communication usually takes place over TCP/IP connections. The
default port is PORT-TBD, but other ports may be used. The TCP flow is
initiated by the ICAP client to a passively listening ICAP server.
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 822 [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.
The header lines of an ICAP message specify the ICAP resource being
requested as well as other meta-data such as cache control information.
ICAP Protocol Group Expiration: May 2001 [Page 9]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
The message body of an ICAP request contains the (encapsulated) HTTP
messages that are being modified.
All ICAP messages MUST be transmitted using the "chunked"
transfer-coding described in Section 3.6.1 of [4]. The
"Transfer-encoding: chunked" header MUST NOT appear in ICAP headers; it
is assumed.
Chunking is mandatory 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,
developers of ICAP servers should be rewarded for producing
"incremental" responses, because low latency is critical to the success
of ICAP. Chunked encoding is the only way to support this type of
efficient implementation. And thirdly, by standardizing on a single
encapsulation mechanism, we avoid the complexity that would be required
in client and server software to support multiple mechanisms. This
simplifies ICAP, and it especially simplifies the "body preview" feature
that is described in Section 5.5
5.2 ICAP URIs
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_URI = scheme ":" net_path [ "?" query ]
scheme = "icap"
net_path = "//" authority [ abs_path ]
authority = [ userinfo @ ] <host> [ ":" <port> ]
ICAP adds the new scheme "icap" to the ones defined in RFC 2396. If the
port is empty or not given, port PORT-TBD is assumed. There is no such
thing as an "abs_path" in an ICAP URI. An example ICAP URI line might
look like this:
icap://icap.example.net:2000/services/icap-service-1
An ICAP server MUST be able to recognize all of its server names,
including any aliases, local variations, and numeric IP addresses of its
interfaces.
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 Protocol Group Expiration: May 2001 [Page 10]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
icap://icap.net/service?mode=translate&lang=french
5.3 ICAP Headers
5.3.1 Headers Common to Requests and Responses
The headers of all ICAP messages MAY include the following directives,
defined in ICAP the same as they are in HTTP:
Cache-Control
Connection
Date
Pragma
Trailer
Upgrade
Via
Note in particular that the "Transfer-Encoding" option is not allowed.
All ICAP messages MUST use the "chunked" transfer-encoding.
The Via header MUST be treated the same as in standard HTTP. ICAP
clients and servers should modify Via as an HTTP proxy would, with
respect to the HTTP message being encapsulated. The Via header added by
an ICAP server should specify protocol as ICAP/1.0.
The Upgrade header MAY be used to negotiate Transport-Layer Security on
an ICAP connection, exactly as described for HTTP/1.1 in [4].
The ICAP-specific headers defined are:
Encapsulated (See Section 5.4)
Note that, in most applications, it is useful for ICAP clients acting in
their HTTP client roles to add ICAP headers to HTTP requests. This
notifies the HTTP origin server that it is speaking with a client that
is ICAP-enabled. Origin servers can use this header to determine that
the client is ICAP-enabled, and 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.
The additional headers in an HTTP (not ICAP) connection to an origin
server that are needed to support this type of decision are application
specific and beyond the scope of this document. However, such headers
(if used) SHOULD start with "X-ICAP". Applications SHOULD include an
"X-ICAP-Version: 1.0" header along with their application-specific
headers.
5.3.2 Request Headers
Similar to HTTP, ICAP requests MUST start with a request line that
contains a method, the complete URI of the ICAP resource being
ICAP Protocol Group Expiration: May 2001 [Page 11]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
requested, and an ICAP version string.
This version of ICAP defines three methods:
REQMOD - for Request Modification (Section 5.7)
RESPMOD - for Response Modification (Section 5.8)
OPTIONS - to learn about configuration (Section 5.9)
The current version number of ICAP is 1.0. A well-formed ICAP request
line therefore will look similar to the following example:
REQMOD icap://icap.example.net/icap?mode=foo 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:
Authorization
Allow (see Section 5.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
In addition to HTTP-like headers, there are also request headers unique
to ICAP defined:
Preview (see Section 5.5)
5.3.3 Response Headers
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/1.0 200 OK
Semantics of ICAP status codes in ICAP match the status codes defined by
HTTP (Section 6.1.1 and 10 of [4]), except where otherwise indicated in
this document; n.b. 100 (Section 5.5) and 204 (Section 5.6).
ICAP error codes that differ from their HTTP counterparts are:
100 - Continue after ICAP Preview (Section 5.5).
204 - No modifications needed (Section 5.6).
400 - Bad request; malformed REQMOD, or RESPMOD or OPTIONS.
404 - ICAP Service not found.
405 - Method not allowed for service (e.g. RESPMOD requested for service
that supports only REQMOD).
ICAP Protocol Group Expiration: May 2001 [Page 12]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
408 - Request timeout; if server detects a dead ICAP client.
500 - Server error. Error on the ICAP server, such as "out of disk
space".
501 - Not implemented. REQMOD, or RESPMOD or OPTIONS is not implemented.
502 - Bad Gateway. This is an ICAP proxy and proxying produced an
error.
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.
505 - ICAP version not supported by server.
550 - Configuration stale; client should refetch OPTIONS.
As in HTTP, the 4xx class of error codes indicate client errors, and the
5xx class indicate server errors.
5.4 ICAP Bodies: Encapsulation of HTTP Messages
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.
This is accomplished by concatenating interesting message parts
(encapsulated sections) into a single ICAP message-body (the
encapsulating message), and noting the offset of each section's start
(relative to the start of the encapsulating message's body) in the
encapsulating message's headers.
The Encapsulated header takes the following form:
reqmod_encapsulated = "Encapsulated" ":"
[ "req-hdr" = (integer)] [ "req-body" = (integer)]
respmod_encapsulated = "Encapsulated" ":"
[ "req-hdr" = (integer)] [ "res-hdr" = (integer) ]
[ "res-body" = (integer)]
If an encapsulated section is not included, it is simply omitted from
the Encapsulated header.
The order in which the encapsulated parts appear in the message 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. The grammar ensures that all
encapsulated headers will come before encapsulated bodies. It also
explicitly defines a certain ordering for the different components of
ICAP Protocol Group Expiration: May 2001 [Page 13]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
the message.
Encapsulated MUST be included in every encapsulating message. For
example,
Encapsulated: req-hdr=0 res-hdr=45 res-body=100
indicates that this message 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 encapsulated headers SHOULD be terminated by a blank line, in order
to make them human readable, and in order to terminate line-by-line HTTP
parsers.
5.4.1 Expected Encapsulated Sections
The chart below summarizes the Encapsulated header formats which SHOULD
be used with each ICAP method's request and response encapsulating
messages.
Request Modification
request: req-hdr=n req-body=n
response: req-hdr=n req-body=n [ For modifying the request ]
response: res-hdr=n res-body=n [ For returning an error ]
Response Modification
request: req-hdr=n res-hdr=n req-body=n res-body=n
response: res-hdr=n res-body=n
5.4.2 Encapsulated HTTP Headers
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.
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.
Despite the above restrictions on encapsulation, the hop-by-hop
Proxy-Authenticate and Proxy-Authorization headers that 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 proxy. 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
ICAP Protocol Group Expiration: May 2001 [Page 14]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
which the proxies cooperatively authenticate a given request." (Section
14.34).
5.5 Message Preview
ICAP requests may include a "preview", allowing the ICAP server to
opt-out of a transaction early, before the entire request has been
transmitted. This general mechanism can be used to build complex
filters, as described in the following examples.
- When a file is checked for viruses, a large fraction of all files
can be certified as "clean" just by looking at the file type, file
name extension, and the first 2K bytes of the file.
- In a content filtering system, it is not enough to just look at the
HTTP file type in order to determine if a text file should be
filtered. The magic numbers (at the front of the file) MUST also
be inspected, to determine if the text is actually a JPEG or GIF
file.
- If an ICAP server wanted 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.
- If an ICAP server wanted 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.
An ICAP client MAY choose to send the beginning of its request, then
stop and wait 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 HTTP, that point must be the boundary between the
headers and body.) To effect a message preview, the ICAP client MUST
add a "Preview:" header to its request headers indicating the length
of the preview. For example:
Preview: 0
This indicates that the ICAP client will send only the 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 body bytes to the ICAP server.
Similarly, the ICAP header:
Preview: 4096
Indicates that the ICAP client will attempt to send 4096 bytes of origin
server data, but the actual transfer may be less, because the ICAP
client is acting like a proxy and is not looking ahead to find the total
length of the origin server response. The entire ICAP header section
will be sent, followed by up to 4096 bytes of encapsulated HTTP body.
The chunk terminator "0\r\n" is always included in these transactions.
ICAP Protocol Group Expiration: May 2001 [Page 15]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
After sending the preview, the ICAP client will wait for a response from
the ICAP server. The response MUST be one of:
- 100 Continue. The ICAP client MUST send the remainder of its ICAP
message, starting from the first chunk after the preview. Note
that, even if the entire message is sent across during the preview
phase, the ICAP server MUST still send "100 Continue" before it
responds with a modified result.
- 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.
A design goal of ICAP preview is to allow an "EOF" indication to "stick"
to the N previewed bytes, and for the EOF to be known by the ICAP
server. Thus, if an origin server responds with zero bytes, an "EOF"
indicator will appear at the ICAP server during preview. If the preview
is 1024 bytes, and exactly 1024 bytes are available, then an EOF
indication will also be sent. It is especially important for EOF to
appear in a zero-length preview, because then only a single round trip
is needed to modify header-only HTTP responses.
In general, this problem is solved by always "marking" the terminal
chunk as containing "EOF". We define an HTTP "chunk-extension" of
"ieof" to indicate that an icap chunk is the last chunk (see rfc2616).
The ICAP server MUST strip this chunk extension before passing the chunk
data to an ICAP application process. Thus, a zero-byte preview for a
zero-byte origin response would appear as follows:
\r\n
0; ieof\r\n
If the ICAP server sees this preview, then it can respond with "100
Continue" and the modified response right away. The ICAP client will
not send any more chunk data, because the eof has been sent. If the
origin response is 1 byte or larger the "ieof" would not appear. If the
preview is 1024 bytes and the origin response is 1024 bytes in two
chunks, then the encapsulation would appear as follows:
100\r\n
<512 bytes of data>\r\n
100\r\n
<512 bytes of data>\r\n
0; ieof\r\n
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.
100\r\n
<512 bytes of data>\r\n
100\r\n
<512 bytes of data>\r\n
ICAP Protocol Group Expiration: May 2001 [Page 16]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
0\r\n
100 Continue
1\r\n
<1 byte of data>\r\n
0; ieof\r\n
Once the ICAP server receives the eof indicator, it finishes reading the
current chunk stream, and both sides send no more data after a 100
Continue response.
For preview to be useful, all ICAP clients MUST implement a minimum
level of preview. Therefore, each ICAP client MUST support a preview of
at least 4096 bytes. The size of a preview is a configurable item
associated with a particular ICAP application.
When offering a Preview, the ICAP client is committed to cache the
portion of the message that was previewed so that it can honor a "204 No
Content" response. (The remainder of the message is not necessarily
cached; it might be pipelined from another source.)
5.6 "204 No Content" Responses outside of Previews
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.
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.
If an ICAP server receives a request that does not have "Allow: 204", it
MUST NOT reply with a 204 (except in the case of a message preview, as
described in the previous section.) 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.
5.7 Request Modification Mode
In this method, described in Section 4.1, an ICAP client sends an HTTP
request to an ICAP server. The ICAP server either sends a modified
version of the request back to the ICAP client, a valid HTTP response,
or (if the client indicates it supports 204 responses) an indication
that no modification is required.
5.7.1 Request
For Request Modification, the ICAP request encapsulates an HTTP request
that MUST be identical to the HTTP request for which the ICAP client is
requesting modification, except that hop-by-hop headers are not
encapsulated.
ICAP Protocol Group Expiration: May 2001 [Page 17]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
5.7.2 Response
The response from the ICAP server back to the ICAP client may take one
of four forms:
-- An error indication,
-- A 204 indicating that the ICAP client's request requires no
adaptation (if and only if the client indicates that it supports 204
responses as described in Section 5.6).
-- An encapsulated, adapted version of the ICAP client's request
-- 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).
The first line of the response message MUST be a status line as
described in Section 5.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 proxy cache, this may include serving an object from its
cache or forwarding the modified request to an origin server. For other
return codes that indicate an error, the proxy SHOULD return these
directly to downstream client.
The modified request headers, if any, MUST be returned to the ICAP
client using appropriate encapsulation as described in Section 5.4.
5.7.3 Examples
Consider the following example, in which a proxy cache receives a simple
GET request from a client. The proxy cache, 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.
In all of our examples, we include the extra meta-data added to the
message due to chunking. We assume that each line is terminated by a
single control-character. (Note we are using rather stupid chunk sizes
just for the sake of exemplifying chunking.)
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
49
GET / HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain
ICAP Protocol Group Expiration: May 2001 [Page 18]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
59
Accept-Encoding: compress
Cookie: ff39fk3jur@4ii0e02i
If-None-Match: "xyzzy", "r2d2xxxx"
0
----------------------------------------------------------------
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
Encapsulated: req-hdr=0
61
GET /modified-path HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain, image/gif
43
Accept-Encoding: gzip, compress"
If-None-Match: "xyzzy", r2d2xxxx"
0
----------------------------------------------------------------
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).
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=160
61
POST /origin-resource/form.pl HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain
2c
Accept-Encoding: compress
Pragma: no-cache
1f
I am posting this information.
0
----------------------------------------------------------------
ICAP Protocol Group Expiration: May 2001 [Page 19]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
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
Encapsulated: req-hdr=0, req-body=177
6c
POST /origin-resource/form.pl HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain, image/gif
44
Accept-Encoding: gzip, compress
Pragma: no-cache
Content-Length: 45
2f
I am posting this information. ICAP powered!
0
----------------------------------------------------------------
Finally, this third example shows an ICAP server returning an error
response when it receives a Request Modification request.
ICAP Request Modification Example 3 - ICAP Request
----------------------------------------------------------------
REQMOD icap://icap-server.net/content-filter ICAP/1.0
Host: icap-server.net
Encapsulated: req-hdr=0
57
GET /naughty-content HTTP/1.1
Host: www.naughty-site.com
Accept: text/html, text/plain
1a
Accept-Encoding: compress
0
----------------------------------------------------------------
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
Encapsulated: res-hdr=0, res-body=198
58
HTTP/1.1 403 Forbidden
Date: Wed, 08 Nov 2000 16:02:10 GMT
Server: Apache/1.3.12 (Unix)
5c
Last-Modified: Thu, 02 Nov 2000 13:51:37 GMT
ICAP Protocol Group Expiration: May 2001 [Page 20]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
ETag: "63600-1989-3a017169"
Content-Length: 62
54
Content-Type: text/html
Sorry, you are not allowed to access that naughty content.
0
----------------------------------------------------------------
5.8 Response Modification Mode
In this method, described in Section 4.3, 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.
The adapted message or error indication returned by the ICAP server
SHOULD be forwarded to the client or otherwise passed to the next
downstream entity (e.g. another ICAP server).
5.8.1 Request
Using encapsulation described in Section 5.4, the header and body of the
HTTP response to be modified MUST be included in the ICAP body. If
available, the header and body 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.
5.8.2 Response
The response from the ICAP server looks just like a reply in the Request
Modification method (Section 5.7); that is,
-- An error indication,
-- An encapsulated and potentially modified HTTP response header and
response body, or
-- An HTTP response 204 indicating that the ICAP client's request
requires no adaptation.
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).
5.8.3 Examples
In Example 4, an ICAP client is requesting modification of an entity
ICAP Protocol Group Expiration: May 2001 [Page 21]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
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".
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=132, res-body=284
63
GET /origin-resource HTTP/1.1
Host: www.origin-server.com
Accept: text/html, text/plain, image/gif
31
Accept-Encoding: gzip, compress
HTTP/1.1 200 OK
5c
Date: Mon, 10 Jan 2000 09:52:22 GMT
Server: Apache/1.3.6 (Unix)
ETag: "63840-1ab7-378d415b"
2c
Content-Type: text/html
Content-Length: 52
34
This is data that was returned by an origin server.
0
----------------------------------------------------------------
ICAP Response Modification Example 4 - ICAP Response
----------------------------------------------------------------
ICAP/1.0 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Server: ICAP-Server-Software/1.0
Connection: close
Encapsulated: res-hdr=0, res-body=153
51
HTTP/1.1 200 OK
Date: Mon, 10 Jan 2000 09:55:21 GMT
Server: Apache/1.3.6 (Unix)
47
ETag: "63840-1ab7-378d415b"
Content-Type: text/html
Content-Length: 91
5d
This is data that was returned by an origin server, but with
value added by an ICAP server.
0
----------------------------------------------------------------
ICAP Protocol Group Expiration: May 2001 [Page 22]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
5.9 OPTIONS Method
The ICAP "OPTIONS" method may be used to retrieve configuration
information from the ICAP server. The exact semantics and syntax of
this information are beyond the scope of this document and will be
filled in by later specifications. Applications may define their own
uses for this method until such use is standardized.
An OPTIONS request for any other URI MUST return options that are
specific to the service named by the URI. All OPTIONS request MAY also
return options that are global to the server (i.e., apply to all
services).
In this example, the root URI of the ICAP server has been configured to
return an OPTIONS response that describes the services that are
available on the server:
[request]
OPTIONS icap://icap.server.net/ ICAP/1.0
[response]
ICAP-Version-Supported: 1.0
Server: ICAP-BazookaServer
Server-Revision: 4.1
Server-Maintainer: admin@icap.server.net
Service-URIs-available: sample-service, another-service
Expires: Mon, 23 Nov 2000 08:29:50 GMT
A different service-specific OPTIONS field might, for example, describe
what content-types a modification service is willing to accept:
[request]
OPTIONS icap://icap.server.net/sample-service ICAP/1.0
[response]
ICAP-Version-Supported: 1.0
Server: ICAP-BazookaServer
Server-Revision: 4.1
Service-URI: icap://icap.server.net/sample-service
Date: Mon, 13 Nov 2000 08:30:32 GMT
Allow: RESPMOD
Service-Name: French translator
Service-Info: http://www.server.net/our-french-translator
Desired-Preview-Length: 1500
Desired-Content-Types: text/plain, text/html
Expires: Mon, 13 Nov 2000 08:29:50 GMT
The problem of defining a policy language is a difficult one and was not
specified by this document. The examples above are just that --
examples.
6 Caching
ICAP Protocol Group Expiration: May 2001 [Page 23]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
ICAP server replies MAY be cached by ICAP clients, just as any other
proxy might cache HTTP responses. Unlike HTTP, ICAP mandates the use of
the caching directives described in HTTP/1.1 [4] by ICAP servers to
explicitly define the cachability of objects to ICAP clients.
In cases where an ICAP server returns a modified version of an object
created by an origin server, 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.
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.
7 Implementation Notes
7.1 Vectoring Points
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:
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.
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.
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 proxy 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 proxy 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.
4. Adaptation of responses coming from the proxy, heading back to the
ICAP Protocol Group Expiration: May 2001 [Page 24]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
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; i.e., 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).
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.
7.2 Application Level Errors
Section 5 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.
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".
The ICAP server is not connected on the socket. Maybe the ICAP
server is dead or it is not connected on the socket.
1001 ICAP_SERVER_RESPONSE_CLOSE:
"ICAP Server closed connection while reading response".
The ICAP server TCP-shutdowns the connection before the ICAP client
can send all the body data.
1002 ICAP_SERVER_RESPONSE_RESET:
"ICAP Server reset connection while reading response".
ICAP Protocol Group Expiration: May 2001 [Page 25]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
The ICAP server TCP-reset the connection before the ICAP client can
send all the body data.
1003 ICAP_SERVER_UNKNOWN_CODE:
"ICAP Server sent unknown response code".
An unknown ICAP response code (see section 5.x) was received by the
ICAP client.
1004 ICAP_SERVER_UNEXPECTED_CLOSE_204:
"ICAP Server closed connection on 204 without 'Connection: close'
header".
An ICAP server MUST send the "Connection: close" header if intends to
close after the current transaction.
1005 ICAP_SERVER_UNEXPECTED_CLOSE:
"ICAP Server closed connection as ICAP client wrote body preview".
7.3 Use of Chunked Transfer-Encoding
For simplicity, ICAP messages MUST use the "chunked" transfer-encoding
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:
-- For objects arriving using "Content-Length" headers, one big chunk
can be created of the same size as indicated in the Content-Length
header.
-- 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)
-- For objects arriving using chunked encoding, they can be
retransmitted as is (without re-chunking).
7.4 Distinct URIs for Distinct Services
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.
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 Protocol Group Expiration: May 2001 [Page 26]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
8 Security Considerations
8.1 Authentication
Authentication in ICAP is very similar to proxy authentication in HTTP
as specified in RFC 2617. Specifically, the following rules apply:
-- 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.
-- If authentication is required between an ICAP client and ICAP server,
hop-by-hop Proxy Authentication as described in RFC 2617 MUST be
used.
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 proxy from the
point of view from the user). This type of authentication will also be
Proxy Authentication as described in RFC 2617.
This standard explicitly excludes any method for a user authenticate
directly to an ICAP server; the ICAP client MUST be involved as
described above.
8.2 Encryption
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 5.3.1, the Upgrade header MAY be used to negotiate
transport-layer security for an ICAP connection.
Note also that end-to-end encryption between a a client and origin
server is likely to preclude the use of value-added services by
intermediaries such as proxy caches. An ICAP server that is unable to
decrypt a client's messages will, of course, be unable to perform any
transformations on it.
8.3 Service Validation
Normal HTTP proxies, 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 proxy is working correctly: a
message should look the same before the proxy as it does after the
proxy.
In contrast, ICAP is meant to cause changes in the semantics of messages
ICAP Protocol Group Expiration: May 2001 [Page 27]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
on their way from origin servers to users. The criteria for a correctly
operating proxy 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.
9 References
[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax and Semantics", Request for
Comments 2396, August 1998.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", Request for Comments 2119, Harvard University, March
1997.
[3] Crocker, D., "Standard for the format of ARPA Internet text
messages", Request for Comments 822, August 1982.
[4] Fielding, R., et. al., "Hypertext Transfer Protocol -- HTTP/1.1",
Request for Comments 2616, June 1999.
[5] Khare, R., et. al., "Upgrading to TLS Within HTTP/1.1", Request
for Comments 2817, May 2000.
10 Contact Information and Authors' Addresses
ICAP discussion currently takes place on the IETF Open Proxies mailing
list at ietf-openproxy@imc.org.
ICAP is a product of the ICAP Protocol Group, an informal partnership
of interested parties that includes the following participants (past
and present):
Lee Duggs lee.duggs@netapp.com
Jeremy Elson jelson@isi.edu
Debbie Futcher deborah.futcher@netapp.com
Don Gillies gillies@netapp.com
John Martin jmartin@netapp.com
Jeff Merrick jeffrey.merrick@netapp.com
John Schuster john.schuster@netapp.com
Edward Sharp edward.sharp@netapp.com
Network Appliance, Inc.
495 East Java Dr.
Sunnyvale, CA 94089 USA
Phone: (408) 822-6000
Alberto Cerpa cerpa@isi.edu
Peter Danzig danzig@akamai.com
Mark Nottingham mnot@akamai.com
Nitin Sharma nitin@akamai.com
ICAP Protocol Group Expiration: May 2001 [Page 28]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
Akamai Technologies
1400 Fashion Island Blvd
San Mateo, CA 94404 USA
Phone: (650) 372-5757
Craig Blitz cblitz@novell.com
Hilarie Orman horman@novell.com
Gary Tomlinson garyt@novell.com
Novell, Inc.
122 East 1700 South
Provo, UT 84606 USA
Phone: (801) 861-7021
Andre Beck abeck@bell-labs.com
Markus Hofmann hofmann@bell-labs.com
Bell Laboratories
Networking Software Research Department
101 Crawfords Corner Road
Holmdel, New Jersey 07733-3030
Phone: (732) 888-7000
David Bryant david.bryant@cacheflow.com
650 Almanor Avenue
Sunnyvale, California 94086
Phone: (888) 462-3568
$Id: icap.txt,v 1.43 2000/11/17 20:57:20 jelson Exp $
ICAP Protocol Group Expiration: May 2001 [Page 29]