HTTP
Click on the red underlined text to get to the source
... ICAP, the Internet Content Adaption Protocol, is a protocol aimed at
providing simple object-based content vectoring for HTTP services.
ICAP is, in essence, a lightweight protocol for executing a "remote
procedure call ...
... services.
ICAP is, in essence, a lightweight protocol for executing a "remote
procedure call" on HTTP messages. It allows ICAP clients to pass
HTTP messages ...
... HTTP messages. It allows ICAP clients to pass
HTTP messages to ICAP servers for some sort of transformation or
other processing ("adaptation"). The server executes its
transformation service ...
... client, usually with modified messages. The adapted messages may be
either HTTP requests or HTTP responses. Though transformations may
be possible on other non-HTTP ...
... client, usually with modified messages. The adapted messages may be
either HTTP requests or HTTP responses. Though transformations may
be possible on other non-HTTP content, they are beyond the scope of
...
... HTTP requests or HTTP responses. Though transformations may
be possible on other non-HTTP content, they are beyond the scope of
this document.
...
... transaction semantics. For example,
this document specifies how to send an HTTP message from an ICAP
client to an ICAP server, specify the URI ...
...
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 ...
... 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.
...
...
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 ...
... 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.
...
... 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 ...
... 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,
...
...
ICAP resource:
Similar to an HTTP resource as described above, but the URI refers
to an ICAP service ...
...
ICAP server:
Similar to an HTTP server as described above, except that the
application services ICAP requests.
...
... semantics in detail, we will first give a
general overview of the protocol's major functions and expected uses.
As described earlier, ICAP focuses on modification of HTTP requests
(Section 3.1), and modification of HTTP responses (Section 3.2).
...
... As described earlier, ICAP focuses on modification of HTTP requests
(Section 3.1), and modification of HTTP responses (Section 3.2).
...
...
In "request modification" (reqmod) mode, an ICAP client sends an HTTP
request to an ICAP server. The ICAP server may then:
1) Send back a modified version ...
... further modification.
2) Send back an HTTP response to the request. This is used to
provide information useful to the user in case of an error (e.g.,
"you sent a request to view a page you are not allowed to see").
...
... ICAP clients MUST be able to handle all three types of responses.
However, in line with the guidance provided for HTTP surrogates in
Section 13.8 of [4], ICAP client implementors ...
... In the "response modification" (respmod) mode, an ICAP client sends
an HTTP response to an ICAP server. (The response sent by the ICAP
client typically has been generated by an origin server.) The ICAP
...
... method is intended for post-processing
performed on an HTTP response before it is delivered to a client.
Examples include formatting HTML ...
... request/response protocol similar in semantics and usage to
HTTP/1.1 [4]. Despite the similarity, ICAP is not HTTP, nor is it an
...
... HTTP/1.1 [4]. Despite the similarity, ICAP is not HTTP, nor is it an
application protocol that runs over HTTP ...
... HTTP, nor is it an
application protocol that runs over HTTP. This means, for example,
that ICAP messages can not be forwarded by HTTP surrogates. Our
...
... application protocol that runs over HTTP. This means, for example,
that ICAP messages can not be forwarded by HTTP surrogates. Our
reasons for not building directly on top of HTTP are discussed in
...
... that ICAP messages can not be forwarded by HTTP surrogates. Our
reasons for not building directly on top of HTTP are discussed in
Section 8.1.
...
... message body of an ICAP request contains the
(encapsulated) HTTP messages that are being modified.
As in HTTP/1.1 ...
... HTTP messages that are being modified.
As in HTTP/1.1, a single transport connection MAY (perhaps even
SHOULD) be re-used for multiple request/response ...
... URI, using the standard "?"-encoding of attribute-value pairs
used in HTTP. For example:
icap://icap.net/service ...
... Internet mail format [3] and later
adopted by HTTP [4], all user-defined headers MUST follow the "X-"
...
... The headers of all ICAP messages MAY include the following
directives, defined in ICAP the same as they are in HTTP:
Cache-Control ...
... headers are allowed in ICAP requests,
following the same semantics as the corresponding HTTP request
headers (Section 5.3 of [4 ...
... 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.
...
... status codes in ICAP match the status codes defined
by HTTP (Section 6.1.1 and 10 of [4]), except where otherwise
indicated in this document; n.b. 100 (Section 4.5) and 204 (Section
...
...
ICAP error codes that differ from their HTTP counterparts are:
100 - Continue after ICAP Preview (Section 4.5).
...
... header is allowed in ICAP requests, following the
same semantics as the corresponding HTTP response headers (Section
6.2 of [4 ...
... ICAP-Related Headers in HTTP Messages ...
...
When an ICAP-enabled HTTP surrogate makes an HTTP request to an
origin server, it is often useful to advise the origin server of the
...
...
When an ICAP-enabled HTTP surrogate makes an HTTP request to an
origin server, it is often useful to advise the origin server of the
surrogate's ICAP capabilities. Origin servers can use this
...
... downstream ICAP server can insert the ad instead.
Although this ICAP specification can not mandate how HTTP is used in
communication between HTTP clients and servers, we do suggest a
...
... Although this ICAP specification can not mandate how HTTP is used in
communication between HTTP clients and servers, we do suggest a
convention: such headers (if used) SHOULD start ...
... convention: such headers (if used) SHOULD start with "X-ICAP". HTTP
clients with ICAP services SHOULD minimally include an "X-ICAP-
Version ...
... 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 ...
... is included at the byte-offsets listed. The byte-offsets are in
decimal notation for consistency with HTTP's Content-Length header.
...
... Encapsulated HTTP Headers ...
... headers and
entity bodies. HTTP headers MUST start with the request-line or
status-line for requests and responses, respectively, followed by
...
... start with the request-line or
status-line for requests and responses, respectively, followed by
interesting HTTP headers.
The encapsulated ...
... headers MUST be terminated by a blank line, in order
to make them human readable, and in order to terminate line-by-line
HTTP parsers.
HTTP/1.1 ...
... Keep-Alive, and so forth. All
end-to-end HTTP headers SHOULD be encapsulated, and all hop-by-hop
headers MUST NOT be encapsulated ...
... client in cases where the ICAP client is
also an HTTP surrogate. Note that this does not contradict HTTP/1.1,
which explicitly states "A proxy ...
... client is
also an HTTP surrogate. Note that this does not contradict HTTP/1.1,
which explicitly states "A proxy MAY relay the credentials ...
... ICAP server as if the encapsulated message were traveling through an
HTTP surrogate. The Via header added by an ICAP server MUST specify
protocol as ICAP/1.0.
...
...
- Content filters can use Preview to decide if an HTTP entity needs
to be inspected (the HTTP ...
... HTTP entity needs
to be inspected (the HTTP file type alone is not enough in cases
where "text" actually turns out to be graphics ...
... - If an ICAP server wants to force all cacheable files to expire in
24 hours or less, then this could be implemented by selecting HTTP
messages with expiries more than 24 hours in the future.
ICAP servers SHOULD use the OPTIONS method ...
... client stops and waits for an
intermediate response from the ICAP server before continuing. This
mechanism is similar to the "100-Continue" feature found in HTTP,
except that the stop-and-wait point can be within the message body.
...
... except that the stop-and-wait point can be within the message body.
In contrast, HTTP requires that the point must be the boundary
between the headers and body.
...
...
For example, to effect a Preview consisting of only encapsulated HTTP
headers, the ICAP client would add the following header to the ICAP
...
... header section(s) will be
sent, followed by up to 4096 bytes of encapsulated HTTP body. The
chunk body terminator "0\r\n\r\n" is always included in these
transactions ...
...
- 100 Continue. If the entire encapsulated HTTP body did not fit
in the preview, the ICAP client MUST send the remainder of its
...
... When an ICAP client is performing a preview, it may not yet know how
many bytes will ultimately be available in the arriving HTTP message
that it is relaying to the HTTP server. Therefore, ICAP defines a
...
... many bytes will ultimately be available in the arriving HTTP message
that it is relaying to the HTTP server. Therefore, ICAP defines a
way for ICAP clients to indicate "EOF ...
... unexpectedly arrives during the preview process. This is a
particularly useful optimization if a header-only HTTP response
arrives at the ICAP client (i.e., zero bytes of body); only a single
...
... server response.
We define an HTTP chunk-extension of "ieof" to indicate that an ICAP
chunk is the last chunk (see [4]). The ICAP server MUST strip this
...
...
For example, consider an ICAP client that has just received HTTP
response headers from an origin server and initiates an ICAP RESPMOD
transaction ...
... ICAP server that it will be sending a 1024-byte preview using a
"Preview: 1024" request header. If the HTTP origin server then
closes its connection to the ICAP client ...
... ISTag.
ISTag is similar, but not identical, to the HTTP ETag. While an ETag
is a validator for a particular entity (object), an ISTag validates ...
... method, described in Section 3.1, an ICAP client sends an
HTTP request to an ICAP server. The ICAP server returns a modified
version of the request, an HTTP response ...
... HTTP request to an ICAP server. The ICAP server returns a modified
version of the request, an HTTP response, or (if the client indicates
it supports 204 responses) an indication that no modification is
...
...
In REQMOD mode, the ICAP request MUST contain an encapsulated HTTP
request. The headers and body (if any) MUST both be encapsulated,
...
...
- An encapsulated HTTP error response. Note that Request
Modification requests may only be satisfied with HTTP responses ...
... 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).
...
... 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 ...
... valid for a 2XX ICAP response to contain an encapsulated
HTTP error response, which in turn should be returned to the
downstream ...
... Encapsulated: req-hdr=0, null-body=231
GET /modified-path HTTP/1.1
Host: www.origin-server.com
...
... Encapsulated: req-hdr=0, req-body=147
POST /origin-resource/form.pl HTTP/1.1
Host: www.origin-server.com
...
... Encapsulated: req-hdr=0, req-body=244
POST /origin-resource/form.pl HTTP/1.1
Host: www.origin-server.com
...
... Encapsulated: req-hdr=0, null-body=119
GET /naughty-content HTTP/1.1
Host: www.naughty-site.com
...
... Encapsulated: res-hdr=0, res-body=213
HTTP/1.1 403 Forbidden
Date: Wed, 08 Nov 2000 16:02:10 GMT
...
... 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.
...
... 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 ...
... response body, or
- An HTTP response 204 indicating that the ICAP client's request
requires no adaptation.
...
... Encapsulated: req-hdr=0, res-hdr=137, res-body=296
GET /origin-resource HTTP/1.1
Host: www.origin-server.com
...
... clients, just as any
other surrogate might cache HTTP responses. Similar to HTTP, ICAP
clients ...
... other surrogate might cache HTTP responses. Similar to HTTP, ICAP
clients MAY always store a successful response (see sections 4.8.2
...
... validation if
it is fresh. ICAP servers use the caching directives described in
HTTP/1.1 [4].
...
... header section of the ICAP response (NOT in
the encapsulated HTTP request of the ICAP message body). In Response
...
... message body). In Response
Modification mode, the ICAP server MAY add or modify the HTTP caching
directives located in the encapsulated HTTP response ...
... HTTP caching
directives located in the encapsulated HTTP response (NOT in the ICAP
header section). Consequently, the ICAP client ...
... 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 ...
... encoding within the encapsulated body section as defined in HTTP/1.1
[4]. This requires that ICAP client ...
... 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 ...
... proxy authentication in
HTTP as specified in RFC 2617draft. Specifically, the following rules
apply:
...
...
Normal HTTP surrogates, when operating correctly, should not affect
the end-to-end semantics ...
... 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
...
... 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,
...
... 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 ...
... 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
...
... 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 ...
... transformations of HTTP messages by surrogates are legal (and
harmless for HTTP), but caused problems with ICAP's "header-in-
header ...
...
Ultimately, we decided that the tangle of workarounds required to fit
ICAP into HTTP was more complex and confusing than moving away from
HTTP and defining a new (but similar) protocol.
...
... ICAP into HTTP was more complex and confusing than moving away from
HTTP and defining a new (but similar) protocol.
...
... 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 ...
... encapsulated in an ICAP message, the ICAP client (HTTP server) can
copy it directly from the HTTP client to the ICAP server without un-
...
... 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
...
... Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616draft, June 1999. ...
... augmented Backus-Naur Form
(BNF) similar to that used by the HTTP/1.1 specification (See Section
2.1 of [4]). Implementors ...
... 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 ...