Internet Content Adaptation Protocol (ICAP)
RFC 3507
Document | Type |
RFC - Informational
(April 2003; Errata)
Was draft-elson-icap (app)
|
|
---|---|---|---|
Authors | Alberto Cerpa , Jeremy Elson | ||
Last updated | 2020-01-21 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 3507 (Informational) | |
Action Holders |
(None)
|
||
Telechat date | |||
Responsible AD | Ned Freed | ||
IESG note | IESG note written; document approved and announcement to be sent | ||
Send notices to | (None) |
Network Working Group J. Elson Request for Comments: 3507 A. Cerpa Category: Informational UCLA April 2003 Internet Content Adaptation Protocol (ICAP) Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. IESG Note The Open Pluggable Services (OPES) working group has been chartered to produce a standards track protocol specification for a protocol intended to perform the same of functions as ICAP. However, since ICAP is already in widespread use the IESG believes it is appropriate to document existing usage by publishing the ICAP specification as an informational document. The IESG also notes that ICAP was developed before the publication of RFC 3238 and therefore does not address the architectural and policy issues described in that document. Abstract ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services. ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. It allows ICAP clients to pass HTTP messages to ICAP servers for some sort of transformation or other processing ("adaptation"). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. Typically, the adapted messages are either HTTP requests or HTTP responses. Elson & Cerpa Informational [Page 1] RFC 3507 ICAP April 2003 Table of Contents 1. Introduction............................................3 2. Terminology.............................................5 3. ICAP Overall Operation..................................8 3.1 Request Modification..............................8 3.2 Response Modification............................10 4. Protocol Semantics.....................................11 4.1 General Operation................................11 4.2 ICAP URIs........................................11 4.3 ICAP Headers.....................................12 4.3.1 Headers Common to Requests and Responses................................12 4.3.2 Request Headers..........................13 4.3.3 Response Headers.........................14 4.3.4 ICAP-Related Headers in HTTP Messages.................................15 4.4 ICAP Bodies: Encapsulation of HTTP Messages.........................................16 4.4.1 Expected Encapsulated Sections...........16 4.4.2 Encapsulated HTTP Headers................18 4.5 Message Preview..................................18 4.6 "204 No Content" Responses outside of Previews.........................................22 4.7 ISTag Response Header............................22 4.8 Request Modification Mode........................23 4.8.1 Request..................................23 4.8.2 Response.................................24 4.8.3 Examples.................................24 4.9 Response Modification Mode.......................27 4.9.1 Request..................................27 4.9.2 Response.................................27 4.9.3 Examples.................................28 4.10 OPTIONS Method...................................29 4.10.1 OPTIONS request..........................29 4.10.2 OPTIONS response.........................30 4.10.3 OPTIONS examples.........................33 5. Caching................................................33 6. Implementation Notes...................................34 6.1 Vectoring Points.................................34 6.2 Application Level Errors.........................35 6.3 Use of Chunked Transfer-Encoding.................37 6.4 Distinct URIs for Distinct Services..............37 7. Security Considerations................................37 7.1 Authentication...................................37 7.2 Encryption.......................................38 7.3 Service Validation...............................38 8. Motivations and Design Alternatives....................39 Elson & Cerpa Informational [Page 2]Show full document text