eCAP

Block content/file after data-trickling started

Asked by Christof Gerber

Hi

I plan to add data trickling to my eCAP adapter which attaches to squid to block certain content/requests.

Before adapter can trickle it has to call useAdapted(). Because I know that blockVirgin() is not available anymore after useAdapted() was called by the adapter, I am looking for an alternative way to display an error page to the user in case of blocking. At the moment I have two vague approaches in mind:

1. Add a custom HTTP header which then triggers an error page within the host (squid). This would require the adapter to modify/add headers after useAdapted() was called. Is this possible?

2. Reply the error page as "adapted content" from the adapter instead of the file to be blocked. I know this is possible in case the adapter has not replied any content yet. But I guess this won't work when some bytes of the (real) file were replied already by data trickling because this would result in some sort of file mixture.

Do you have other ideas how to solve that? The well known CLAMAV adapter, which implements configurable data-trickling, the adapter aborts the adaptation in case useAdapted() was called before the block-decision is made. Used with squid 3.5 this leads to a connection close without error page upon a file to be blocked being downloaded. Which I think is not a desirable behaviour but I wonder if there is a better way!?

Question information

Language:
English Edit question
Status:
Answered
For:
eCAP Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Alex Rousskov (rousskov) said : 		#1

> 1. Add [an] HTTP header [...] after useAdapted() was called. Is this possible?

No, it is not. The host application can send the adapted headers to the client at the time of the useAdapted() call.

> 2. [Sending] "adapted content" [after] some bytes of the (real) file were replied already by data trickling [...] wont' work

Correct. You should not mix two different "pages" in one HTTP response. The client will be very confused.

> CLAMAV adapter aborts the adaptation in case useAdapted() was called before the block-decision is made

Correct.

> Which I think is not a desirable behaviour

Correct.

> but I wonder if there is a better way!?

We are dealing with HTTP limitations here. The protocol is not designed for traffic adaptation or even filtering. One could use HTTP trailers to relay the blocking decision to various automated agents (including the host application), but trailers cannot be used to inform a typical human user of what has happened -- there is no support for that in the browsers.

I know of only one human-focused alternative. It is often called a "patience page": Instead of trickling the virgin response to the client, the proxy redirects the client to a special page that says something like "Please wait while your download is being scanned. We are X% done...". The patience page (including the value of X) can be updated via various Javascript tricks (with or without trickling). When the scan is over, that patience page either tells the user that the content was blocked or redirects the user again to receive the scanned content. All that interaction can be done via an eCAP or ICAP adapter without proxy modification, but it requires serious development and does not work well for scanning embedded resources (or dealing with most non-browser clients).

Pick your poison.

Can you help with this problem?

Provide an answer of your own, or ask Christof Gerber for more information if necessary.

To post a message you must log in.