Re: ICAP vectoring points

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 30 Nov 2012 00:08:57 +1300

On 29/11/2012 10:32 p.m., 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.

Alternative that avoids post-cache alteration:

* REQMOD adds a custom header to the request containing a token to
uniquely identify the privilege level.
* REPMOD adds a Vary: header naming the REQMOD header as criteria for
variant caching.

That way REQMOD has full control over whether the request can HIT on the
URL resource, or HIT on a dummy error page created by REPMOD, or MISS
completely (new unique token) and cause a different copy of the object
to be fetched.

If you face the issue that the REQMOD is not able to determine on its
own whether the request should HIT or MISS then you can assign it a
unique token that will MISS anything already cached, and let REPMOD take
control over what that token points at.

>
> 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.

Was it you that mentioned elsewhere you were trying to avoid TPROXY
because you had internal web servers? cache_peer can point directly at
the internal servers to avoid having an extra proxy hop. The cache_peer
no-tproxy option was added for exactly this scenario. TPROXY spoofing is
only mandatory on DIRECT traffic at present.

Amos
Received on Thu Nov 29 2012 - 11:09:16 MST

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