Re: ICAP vectoring points

From: Eliezer Croitoru <eliezer_at_ngtech.co.il>
Date: Thu, 29 Nov 2012 13:14:18 +0200

On 11/29/2012 11:32 AM, Steve Hill wrote:
> On 29.11.12 04:16, Eliezer Croitoru wrote:
>
>> I was just wondering what exactly you need to do?
>> What is the goal\task of the ICAP server.
>
> The ICAP server does on-the-fly content filtering - it analyses the
> request headers (in reqmod), the response headers and streaming content
> (in respmod) to categorise the page and decide whether to block it. The
> filtering criteria are done on a per-user basis, so filtering it before
> it enters the cache doesn't make sense, since in the event that an
> allowed user requests the object, it will then go into the cache and
> will be retrievable by a disallowed user.

> It would be possible to do all the possible analysis that could be
> needed, insert their results as http headers and allow the object to go
> into the cache, then check those headers using ACLs when it is retrieved
> from the cache, but this would result in a large overhead of unnecessary
> analysis since for most users those criteria are not needed.
>
>> The only missing thing is that you cant pass yet to the ICAP server
>> special custom headers by your choose.
>
> This is something I've thought about doing for various reasons in the
> past, but never actually tried. However, is this not what
> adaptation_meta does?
Seems like if it's from a list of small specific groups it's possible
but it will need smart ACL system.

>> If you have specific ICAP solution maybe it's not design to even do what
>> you need.
>
> The ICAP server was designed by me, so it is designed to do exactly what
> we need. :) However, I could never see a sensible alternative to using
> a respmod_postcache vectoring point, so in the end we settled on
> stacking 2 squids together to achieve that.
>
> It would, however, be nice to be able to ditch the second squid at some
> point. Although a secondary purpose the second squid is performing at
> the moment is to prevent tproxy from spoofing the client's IP address,
> since there appears to be no other way to do this (?). That said,
> disabling spoofing on a global basis appears to be reasonably trivial to
> hack into the squid code.
And why you dont want to spoof th client IP?

If you do ask me such filtering solution is better left as a self
maintained service on different server then the cache on a RealWorld
scenario.
Filtering is nice but in any case there is in the Real world the worst
choice to do such filtering is on the same machine of the cache service.

Cache is a very high load and duty from CPU and Disk access by itself to
allow in most cases a dedicated server.

I wasn't talking about a small office which holds 5 computers that in
this scenario even an android device with linux on it will be more then
you will need.

Actually the very basics of RESPMOD ICAP is to not be in front of a
cache but rather after it.
The other option is to use the no-store header for modified request
which in almost any case shouldn't be cached and will fix any problem.
(i'm a bit off today so next week I will have a second look at it)

Regards,
Eliezer

-- 
Eliezer Croitoru
https://www1.ngtech.co.il
sip:ngtech_at_sip2sip.info
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il
Received on Thu Nov 29 2012 - 11:14:34 MST

This archive was generated by hypermail 2.2.0 : Thu Nov 29 2012 - 12:00:09 MST