ICAP is a lightweight protocol, specified in RFC 3507, that lets a proxy hand an HTTP request or response to a separate server for inspection or modification before passing it on. In file security it is the standard way a network gateway sends a file to an external scanner and receives a verdict.
The problem it was designed to solve
RFC 3507, published in 2003, describes ICAP as a way for clients to pass HTTP messages to ICAP servers for transformation or other processing. The motivation was practical: proxies and caches sit in the path of enormous amounts of traffic, and organisations kept wanting to do things to that traffic which had nothing to do with proxying.
Rather than building every capability into the proxy, ICAP lets the proxy hand a message to a specialist server and act on what comes back. The RFC lists virus scanning of downloadable files, content filtering, advertisement insertion and format conversion for particular devices as typical uses. Virus scanning is the one that kept it relevant.
Two decades on, ICAP survives because that separation still makes sense. A secure web gateway does not want to implement malware detection, and a scanning vendor does not want to implement a proxy. ICAP is the contract between them.
Two modes, and one confusing label
ICAP has two modes of operation, and the difference is simply which direction the traffic is going.
- REQMOD (request modification) sends an outbound HTTP request to the ICAP server before it reaches its destination. This is the path an upload takes, and it is where a file leaving a user's machine gets inspected
- RESPMOD (response modification) sends a response coming back from an origin server for inspection before it reaches the user. This is the path a download takes
The ICAP server can return the message unchanged, return a modified version, or return an error that the proxy turns into a block page. That third option is why a blocked download shows you a corporate warning page rather than a broken connection.
Now the label that trips people up. In RFC 3507's terminology, the ICAP client is the proxy, and the ICAP server is the thing doing the scanning. Most people arrive expecting the opposite, because the scanner feels like the thing being called. Vendor documentation follows the RFC, so when a datasheet says "ICAP client support" it means the product can sit in the gateway position and call out to a scanner.
The IANA service registry records 1344 as the default port, though deployments vary it freely and TLS-wrapped variants are common.
Why it appears on every file security datasheet
If you have been comparing file sanitisation or malware scanning products, ICAP support will have appeared prominently on nearly all of them. That is because the traditional buyer for these products is deploying them into a network path: a secure web gateway, a mail gateway, a reverse proxy in front of an application, or a kiosk that scans removable media at the boundary of an air-gapped network.
In all of those cases the inspecting device has traffic passing through it and no idea what to do with a file. ICAP gives it a standard way to ask. The alternative would be a bespoke integration per vendor pair, which is exactly the situation the protocol was written to end.
So ICAP support is a genuine signal about a product, but it is a signal about deployment model rather than quality. It tells you the product expects to live in the network path.
Do you need it?
If you are building the application yourself, usually not, and it is worth understanding why so that a datasheet does not talk you into a deployment you do not want.
ICAP exists so infrastructure can inspect traffic it does not understand. Your application is in the opposite position. At the moment you want a file checked you already have it in your own code, you know which user sent it, you know what it is for and you know what should happen to it next. Handing it to an HTTPS API and acting on the response is fewer moving parts, easier to test and easier to reason about when something fails.
You also get better control of the decision. In the network path a file is essentially allowed or blocked. In your application you can quarantine it, ask the user for a different format, accept a rebuilt copy, or route it for review, because you have the context to choose.
ICAP earns its place when inspection genuinely has to happen in the network rather than in an application: covering traffic to systems you cannot modify, enforcing a control across an entire estate, or scanning removable media at a physical boundary. Those are real requirements, and they are infrastructure requirements. For an application accepting uploads, a direct API call is the more natural fit, and it is why API-first services increasingly do not offer ICAP at all. If you are weighing up the options, our guide to how the file sanitisation market splits covers which products sit where.
If the file is already in your code, an API call is the shorter path. The Red Eagle Tech CDR API takes a document over HTTPS with OAuth2, rebuilds it from its safe components and hands it straight back, so you keep the decision about what happens next. Published per-document pricing, and you can be running in minutes.
