Summary

  • An ICAP Preview is a bounded sample of encapsulated HTTP headers and initial body bytes; any verdict must remain scoped to what the service actually received under that configuration epoch.
  • 100 Continue, 204 No Content, an adapted message and an ISTag each describe a different protocol event. None alone proves that all content was classified, an origin accepted the request or the recipient achieved a useful result.

The service inspected the opening of the object and found no reason to change it. The client resumed the flow. The byte sequence that should have changed the decision arrived later.

Nothing in that sequence requires a broken parser. It requires only an overbroad claim. The service made a decision over a preview; the incident report described a decision over the whole body.

RFC 3507, published in April 2003 as an Informational specification, gives the preview a precise wire boundary. ICAP was designed as a lightweight remote procedure call for adapting HTTP messages. It was not HTTP, did not run over HTTP, and did not inherit origin authority merely because it carried encapsulated HTTP sections.

The IESG note is equally important. ICAP was documented because it was already used, while the OPES work was chartered for standards-track treatment of similar functions. ICAP also predated RFC 3238's architectural and policy concerns. Historical use is not a current deployment measurement, and the status line is not a governance model.

The stop point can sit inside the body

An ICAP client can send all encapsulated headers and up to a service-advertised number of body bytes. It ends the preview chunk stream and waits. The service can return an adapted result, 204 No Content, or 100 Continue when more body remains.

This differs from HTTP's familiar expectation at the boundary between headers and body. ICAP can stop after body bytes have already crossed. That makes the evidence surface richer: header set, requested preview length, actual preview length, chunk boundaries and origin read state all matter.

RFC 3507 says clients should be capable of at least 4096 preview bytes and should not send a larger preview than the service indicated it would accept. That number is historical protocol guidance, not a universal classification threshold. A format can place its decisive field after byte 4096, before it, or across a boundary.

A statement such as “the service checked the object” needs the exact byte range. Without it, a preview optimization silently becomes an all-content warranty.

100 Continue asks for the remainder

If the full body did not fit in the preview, the service can return 100 Continue. The client must then send the remaining encapsulated body beginning with the first chunk after the preview.

That response says nothing about the final adaptation decision. It is permission to complete the service's input. It does not authenticate the origin, approve the HTTP method, commit an application transaction or even promise that the service will accept the completed content.

There are now two provisional boundaries in one story. The ICAP service may ask for more encapsulated body, and a later HTTP exchange may have its own interim and final responses. Collapsing them into “continued” loses which participant granted which resource.

The receipt should identify the ICAP connection, resource URI, method, interim response and first post-preview byte. A packet stream that shows more body after 100 proves transfer progress to the adaptation service, not progress at the origin.

ieof closes the preview input

An ICAP client acting as a surrogate may not know how many bytes the origin will provide. The origin can end while the client is still assembling the preview. ICAP marks that condition with the ieof chunk extension.

Once ieof appears, the service knows the body ended within the preview. It must not ask for more with 100 Continue; it can return a modified response or 204 as applicable. The service strips the extension before delivering the data to its application logic.

This produces two records: the wire framing that said end-of-input and the adaptation bytes after framing removal. If only the application buffer is retained, a reviewer cannot show why 100 was illegal or why the service believed it had seen the full body.

Absence of ieof proves less. It says the client did not declare end-of-body at that point. It does not promise that more bytes will actually arrive; the origin can still fail or close later.

204 means no adaptation, not “clean”

In a preview transaction, 204 No Content tells the client to proceed as if the entire message had been returned unchanged. The client can do so because it committed to buffer the previewed portion and still owns or relays the rest.

Outside preview, the burden changes. A client can advertise Allow: 204, accepting the responsibility to retain enough of the original to reconstruct it. If the client did not grant that permission, the service must return the complete identical message instead of a bare 204.

The status therefore contains an economic and architectural contract: who keeps the bytes, and who pays the memory and flow-control cost. It does not certify absence of malware, policy compliance, source authenticity or safe execution. The RFC wording allows the service not to want or not to be able to modify the message.

An operations dashboard that renames 204 as “clean” destroys that limitation. A better log says: no adapted representation returned, original reconstruction path chosen, preview range observed, service epoch identified.

Adaptation creates a new provenance branch

In request modification mode, the service can return a modified HTTP request, an HTTP error response, 204 where permitted, or an ICAP error. The modified request may then be sent to an origin or another service.

In response modification mode, the input came from an origin-side response and the output may be changed before reaching the consumer. Neither mode proves that the next hop accepted or displayed the result.

An HTTP error encapsulated by a REQMOD service has adaptation-path provenance. It is not evidence that the origin generated the error. Likewise, a transformed response is not the original representation even when most bytes are unchanged.

The evidence needs a before hash, after hash, transformation trace, method, service identity and next-hop result. A final user-visible outcome stays separate because the recipient can reject, truncate or reinterpret the adapted message.

ISTag names the service epoch

RFC 3507 requires every ICAP response to carry an ISTag. The token can represent the service software or configuration state. When a change invalidates earlier adaptation results, changing the tag lets a client invalidate cached results associated with the old service state.

The scope is broader than an HTTP entity tag. An ETag validates one representation; an ISTag identifies the state of a service URI across the entities it generated. That makes tag generation and rollout a control surface.

The tag is not a cryptographic attestation. It does not reveal which rules or data set it represents, prove that every cluster node has adopted the new epoch, or establish that an old decision was correct. Two nodes can emit the same stale token if their deployment process is wrong.

A useful receipt binds the ISTag to a signed or otherwise authenticated configuration manifest, deployment set, activation time and cache invalidation action. The token is a comparison handle, not the policy itself.

OPTIONS, cache and policy run on different clocks

The OPTIONS method advertises methods, Preview size, transfer treatment, Allow, maximum connections, option lifetime and ISTag. A cached OPTIONS response can expire before the adaptation result does. A service epoch can change before either clock.

In RESPMOD, the expiration of an adapted origin object must not extend beyond the origin object's expiration, though it may be shortened. That protects one freshness boundary. It does not prove the service's rule set remained unchanged or that a recipient's context still matches the cached decision.

The evidence must track at least three clocks: OPTIONS capability freshness, adapted-result freshness and service-epoch validity. “Cache hit” is not a timeless verdict; it is reuse under recorded keys and dates.

When a new ISTag appears, the client needs a measurable invalidation action. Merely logging the new token while serving entries attached to the old one leaves the control plane green and the data plane stale.

Encapsulation offsets are not semantic validation

The ICAP Encapsulated header gives offsets for request headers, request body, response headers, response body, options body or a null body. These offsets make the compound message parseable. They do not prove that the embedded HTTP sections obey every semantic rule or that the transformation preserved end-to-end intent.

Hop-by-hop headers are treated differently from end-to-end sections. Chunk framing, preview terminator, ieof, ICAP final status and embedded HTTP status each belong to their own layer.

A robust trace retains the compound wire message and the separated sections. Re-serializing only the embedded HTTP object can erase the boundary that explains which service saw which bytes.

Policy and consent live beyond a status code

RFC 3238 raised architectural and policy concerns for OPES-style content modification, including consent, notification, non-blocking behavior, URI resolution, reference validity and privacy. Later RFCs described dispatchers, rules, trust domains, tracing and callout security.

Those documents do not make every ICAP deployment an OPES deployment, nor do they retroactively add policy receipts to one ICAP status. They show why a transformation protocol needs an authority record around it.

The adaptation dispatcher must be able to say whose rule selected the service, which trust domain authorized access to the content, what trace was attached, and how a party can distinguish the transformed representation. The status line alone cannot answer those questions.

Sixteen receipts for one “passed” object

Begin with original HTTP bytes, role and observation point. Name the ICAP URI, method and authenticated peers where available. Preserve OPTIONS capabilities, expiry, Preview size and current ISTag provenance.

Validate encapsulation offsets. Record requested and actual preview bytes, ieof, origin read state and client buffer. Save the interim or final status and any remaining transfer. Identify exactly which input bytes the service observed.

For modification, retain before and after objects plus the transformation trace. For caching, retain key, directives, expiry and tag comparison. For 204, prove how the original stream was reconstructed.

Then follow the next HTTP hop, origin provenance, recipient delivery, authorization and authenticated application outcome. A rollback or alternate-service replay should reproduce the claimed mechanism.

Evidence boundary

This article does not identify a current proxy, vendor, scanner, incident or content result. It does not claim that previews are unsafe or that 204 is an error. It preserves the boundary each optimization requires.

It also does not repeat the existing HTTP 100 Continue history. That article owns permission to spend a request body at the HTTP header/body boundary. RFC 3507 owns delegated adaptation, a stop inside encapsulated content, service-side transformation, reconstruction and service-wide cache epochs.

Heng Lu's minimum-initial-specification and running-code principles are disclosed editorial lenses. They favour a thin common wire contract and evidence from actual byte ranges, epochs and outcomes. They are not measurements of ICAP adoption.

The narrow conclusion is enough: an adaptation service can make a correct decision about the preview it received while an organization makes a false claim about the object it did not.

Sources