Found 2 records.

Status: Verified (1)

RFC 3507, "Internet Content Adaptation Protocol (ICAP)", April 2003

Errata ID: 258

Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alex Rousskov
Date Reported: 2005-07-18
Report Text:

Errata for this document can be found at:
http://www.measurement-factory.com/std/icap/

Status: Reported (1)

RFC 3507, "Internet Content Adaptation Protocol (ICAP)", April 2003

Errata ID: 5893
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Hill
Date Reported: 2019-11-04

Section 4.5 says:

100 Continue.  If the entire encapsulated HTTP body did not fit in the preview, the ICAP client MUST send the remainder of its ICAP message, starting from the first chunk after the preview.  If the entire message fit in the preview (detected by the "EOF" symbol explained below), then the ICAP server MUST NOT respond with 100 Continue.

It should say:

100 Continue.  If the entire encapsulated HTTP body did not fit in the preview, the ICAP client MUST send the remainder of its ICAP message, starting from the first chunk after the preview.  If the entire message fit in the preview (detected by the "EOF" symbol explained below), then the ICAP client MUST ignore a 100 Continue response.

Notes:

Originally, the ICAP server was prohibited from sending a 100 Continue if the entire HTTP body fits in the preview. However, the ICAP server cannot know if the entire body fits in the preview until the whole preview has been received. An ICAP server cannot begin loop-back streaming of the HTTP transaction until the whole preview has been received, because it cannot know whether or not it is appropriate to send a "100 Continue" first. This severely impacts situations where an HTTP server is producing a very slow data stream and therefore causes the preview to take a long time.

The corrected text makes it permissible for an ICAP server to blindly send a "100 Continue" before it knows whether or not it is appropriate, and requires the ICAP client to ignore the "100 Continue" in the event that it turned out to not be appropriate.

A server that sends a "100 Continue" response before receiving the final preview chunk will be able to note the presence or absence of the ieof chunk extension when the final preview chunk later arrives, and therefore determine whether that marks the end of the ICAP request or whether to expect the client to immediately begin streaming the non-preview data.

Report New Errata