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"
----------------------------------------------------------------
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"
----------------------------------------------------------------
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=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
1e
I am posting this information.
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
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
----------------------------------------------------------------
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
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
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
----------------------------------------------------------------
4.9 Response Modification Mode
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.
4.9.1 Request
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.9.2 Response
The response from the ICAP server looks just like a reply in the
Request Modification method (Section 4.8); 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 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).
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.
The modified response headers, if any, MUST be returned to the ICAP
client using appropriate encapsulation as described in Section 4.4.
4.9.3 Examples
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".
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
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
----------------------------------------------------------------
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
5c
This is data that was returned by an origin server, but with
value added by an ICAP server.
0
----------------------------------------------------------------
4.10 OPTIONS Method
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).
4.10.1 OPTIONS Request
The OPTIONS method consists of a request-line, as described in
Section 4.3.2, such as the following example:
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.10.2 OPTIONS Response
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.
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).
For example:
Methods: 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
-- ISTag:
See section 4.7 for details. This header MUST be included in the
OPTIONS response.
For example:
ISTag: "5BDEEEA9-12E4-2"
-- Encapsulated:
This header MUST be included in the OPTIONS response; see Section
4.4.
For example:
Encapsulated: 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.
For example:
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.
For example:
Max-Connections: 1500
-- Options-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.
For example:
Options-TTL: 3600
-- Date:
The server's clock, specified as an RFC1123 compliant date/time
string. This header MAY be included in the OPTIONS response.
For example:
Date: Fri, 15 Jun 2001 04:33:55 GMT
-- Service-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.
For example:
Service-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.
For example:
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.
For example:
Preview: 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).
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.
For example:
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.
For example:
Transfer-Complete: 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).
4.10.3 OPTIONS Examples
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.
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: *
----------------------------------------------------------------
5. Caching
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].
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
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.
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.
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.
Note that the ISTag response-header may also be used to providing
caching hints to clients; see Section 4.7.
6. Implementation Notes
6.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 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.
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).
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.
6.2 Application Level Errors
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.
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".
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 4.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".
6.3 Use of Chunked Transfer-Encoding
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:
- 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).
6.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.
7. Security Considerations
7.1 Authentication
Authentication in ICAP is very similar to proxy authentication in
HTTP as specified in RFC2617. 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 RFC2617
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
surrogate 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 to
authenticate directly to an ICAP server; the ICAP client MUST be
involved as described above.
7.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 4.3.1, the Upgrade header MAY be
used to negotiate transport-layer security for an ICAP connection
[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.
7.3 Service Validation
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.
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.
8. Motivations and Design Alternatives
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.
8.1 To Be HTTP, or Not To Be
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.
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.
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.
8.2 Mandatory Use of Chunking
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
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.
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.
8.3 Use of the null-body directive in the Encapsulated header
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.
9. References
[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax and Semantics", RFC2396,
August 1998.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[3] Resnick, P., "Internet Message Format", RFC2822, April 2001.
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC2616, June 1999.
[5] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
RFC2817, May 2000.
10. Contributors
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):
Lee Duggs
Network Appliance, Inc.
495 East Java Dr.
Sunnyvale, CA 94089 USA
Phone: (408) 822-6000
EMail: lee.duggs@netapp.com
Paul Eastham
Network Appliance, Inc.
495 East Java Dr.
Sunnyvale, CA 94089 USA
Phone: (408) 822-6000
EMail: eastham@netapp.com
Debbie Futcher
Network Appliance, Inc.
495 East Java Dr.
Sunnyvale, CA 94089 USA
Phone: (408) 822-6000
EMail: deborah.futcher@netapp.com
Don Gillies
Network Appliance, Inc.
495 East Java Dr.
Sunnyvale, CA 94089 USA
Phone: (408) 822-6000
EMail: gillies@netapp.com
Steven La
Network Appliance, Inc.
495 East Java Dr.
Sunnyvale, CA 94089 USA
Phone: (408) 822-6000
EMail: steven.la@netapp.com
John Martin
Network Appliance, Inc.
495 East Java Dr.
Sunnyvale, CA 94089 USA
Phone: (408) 822-6000
EMail: jmartin@netapp.com
Jeff Merrick
Network Appliance, Inc.
495 East Java Dr.
Sunnyvale, CA 94089 USA
Phone: (408) 822-6000
EMail: jeffrey.merrick@netapp.com
John Schuster
Network Appliance, Inc.
495 East Java Dr.
Sunnyvale, CA 94089 USA
Phone: (408) 822-6000
EMail: john.schuster@netapp.com
Edward Sharp
Network Appliance, Inc.
495 East Java Dr.
Sunnyvale, CA 94089 USA
Phone: (408) 822-6000
EMail: edward.sharp@netapp.com
Peter Danzig
Akamai Technologies
1400 Fashion Island Blvd
San Mateo, CA 94404 USA
Phone: (650) 372-5757
EMail: danzig@akamai.com
Mark Nottingham
Akamai Technologies
1400 Fashion Island Blvd
San Mateo, CA 94404 USA
Phone: (650) 372-5757
EMail: mnot@akamai.com
Nitin Sharma
Akamai Technologies
1400 Fashion Island Blvd
San Mateo, CA 94404 USA
Phone: (650) 372-5757
EMail: nitin@akamai.com
Hilarie Orman
Novell, Inc.
122 East 1700 South
Provo, UT 84606 USA
Phone: (801) 861-7021
EMail: horman@novell.com
Craig Blitz
Novell, Inc.
122 East 1700 South
Provo, UT 84606 USA
Phone: (801) 861-7021
EMail: cblitz@novell.com
Gary Tomlinson
Novell, Inc.
122 East 1700 South
Provo, UT 84606 USA
Phone: (801) 861-7021
EMail: garyt@novell.com
Andre Beck
Bell Laboratories / Lucent Technologies
101 Crawfords Corner Road
Holmdel, New Jersey 07733-3030
Phone: (732) 332-5983
EMail: abeck@bell-labs.com
Markus Hofmann
Bell Laboratories / Lucent Technologies
101 Crawfords Corner Road
Holmdel, New Jersey 07733-3030
Phone: (732) 332-5983
EMail: hofmann@bell-labs.com
David Bryant
CacheFlow, Inc.
650 Almanor Avenue
Sunnyvale, California 94086
Phone: (888) 462-3568
EMail: david.bryant@cacheflow.com
Appendix A BNF Grammar for ICAP Messages
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.
Many header values (where noted) have exactly the same grammar and
semantics as in HTTP/1.1. We do not reproduce those grammars here.
ICAP-Version = "ICAP/1.0"
ICAP-Message = Request | Response
Request = Request-Line
*(Request-Header CRLF)
CRLF
[ Request-Body ]
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
Extension-Method = token
ICAP_URI = Scheme ":" Net_Path [ "?" Query ] ; Section 4.2
Scheme = "icap"
Net_Path = "//" Authority [ Abs_Path ]
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
| "User-Agent" ; Section 4.3.2
| "Preview" ; Section 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
Extension-Field-Name = "X-" token
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
Response = Status-Line
*(Response-Header CRLF)
CRLF
[ Response-Body ]
Status-Line = ICAP-Version SP Status-Code SP Reason-Phrase 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]
| "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
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
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
Phone: (310) 206-3925
EMail: jelson@cs.ucla.edu
Alberto Cerpa
University of California Los Angeles
Department of Computer Science
3440 Boelter Hall
Los Angeles CA 90095
Phone: (310) 206-3925
EMail: 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/.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
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 RFCEditor function is currently provided by the
Internet Society.