Network Prevent for Web: ICAP Response Behavior for "Block HTTP/S" Response Rule

Products

• Data Loss Prevention Core Package
• Data Loss Prevention
• Data Loss Prevention Cloud Detection Service for ICAP
• Data Loss Prevention Network Web
• Data Loss Prevention Network Monitor and Prevent for Email and Web
• Data Loss Prevention Enterprise Suite

Issue/Introduction

You have implemented Symantec Data Loss Prevention Network Prevent for Web with a web proxy. However, you notice that the Web Prevent server returns an ICAP response with status code 200 OK to the Web Proxy after analyzing traffic that should be blocked based on a DLP policy with a "Block HTTP/S" response rule. This article explains why this occurs and how it aligns with the ICAP protocol (RFC 3507).

 

Cause

Symantec DLP adheres to the ICAP protocol (RFC 3507), which specifies that an ICAP server must return a 200 OK response when it successfully processes an ICAP request, even if the content is modified or blocked due to policy enforcement. 

The approach followed by Symantec DLP is not unique. Other ICAP-based security solutions also return 200 OK when processing is successful, even if they modify or block HTTP/S traffic. This is because RFC 3507 dictates how ICAP servers should handle and report content inspection results.

 

Resolution

When Symantec DLP applies the "Block HTTP/S" response rule, it replaces the HTTP response body with the blocking message configured in your response rule (e.g., "Content blocked due to policy violation") and removes the original destination from the response. This can be easily confirmed capturing a .pcap trace.

This behavior is consistent with RFC 3507, which mandates that ICAP responses indicate whether processing was successful, irrespective of content modifications or blocking actions.

According to RFC 3507, ICAP servers return different status codes based on request processing outcomes:

• 200 OK – The request was successfully processed. If a DLP policy violation occurs, the response is modified accordingly (e.g., blocking message is inserted).

• 204 No Content – No modifications were necessary; the content passes through without changes.

• 4xx/5xx Errors – If there are processing issues (e.g., server errors or timeouts), the DLP server returns appropriate error codes such as 404 Bad Request or 500 Internal Server Error.

For more details, refer to:

https://datatracker.ietf.org/doc/html/rfc3507   

ICAP Status Codes