I can see and agree that the "preview" mechanism is quite useful
in several secnarios. However, it requires that the preview size
is statically agreed on a-priori. I could imagine that there are
services that can deliver a final response before receiving the
entire message, but without knowing how many bytes (i.e. preview
size) they need to see before being able to do so.
An ICAP server is allowed by the ICAP internet draft to reply to an
ICAP client before the ICAP server has received the entire encapsulated
body. In fact, ICAP servers are encouraged to produce such "incremental"
responses in order to reduce latency, which is important when a request
has to be processed by multiple ICAP servers. These are some of the
reasons the ICAP internet draft gives in section 8.2 for mandating the
use of chunked encoding for ICAP encapsulated bodies.
Consequently, ICAP clients should be written to check for an ICAP server's
response while the ICAP client is sending out the encapsulated body.
Unfortunately, I don't think this point about ICAP clients is mentioned
explicitly in the internet draft.
Jeff