Problem

In certain cases, when a large file is uploaded and transmitted to an ICAP server, if the request exceeds the configured read timeout, the client (SecureTransport) may send a duplicate EOF marker. This results in a deviation from the expected RFC standard.

According to the RFC 3507 specifications, when a file is sent to an AV/DLP ICAP server, the client must signal the end of the payload by sending CR, LF and a trailing 0.

If the ICAP server does not respond in time and the connection close operation times out, the channel may not be properly marked as closed. As a result, the client (SecureTransport) might execute a second iteration and send another CR, LF and a trailing 0, creating a double EOF marker.

Resolution

In high-load SecureTransport environments using AV/DLP servers, ensure that the ICAP server has adequate hardware resources. Since SecureTransport can send a large number of concurrent requests, proper resource allocation helps avoid timeouts and ensures timely ICAP responsiveness, preventing misleading or timing-out connections.

If the ICAP server must handle a large volume of requests and reducing response time is not feasible, the situation can be mitigated by adjusting the read timeout setting for ICAP connections (the default is 60 seconds). Consider increasing this value to match operational needs, but keep it small enough to still detect when the ICAP server is truly unresponsive.