RE: [squid-users] dansguardian as a patch for Squid

> -----Original Message-----
> From: Daniel Barron [mailto:squidcache@jadeb.com]
> Sent: Monday, June 25, 2001 9:37 AM
> To: squid-users@squid-cache.org
> Subject: Re: [squid-users] dansguardian as a patch for Squid
>
>
> In message <04f501c0fbd8$a0fb37e0$0200a8c0@lifelesswks> you wrote:
> [snip]
> >
> > hooks I can do... but there is a deep rewrite in progress
> as mentioned
> > above to resolve some critical issues.
> >
>
> So I need to wait a bit then...

For anything serious - yes.
 
> > There are example filters that can be used as templates in the CVS
> > branch that has the filtering code in it. That should help.. :]
>
> But you say it's not stable at the moment, so I should wait?

Yes... I just wanted to answer the question :}
 
> > > So, squid authors, whaddya think? Would you like to discuss an
> > interface
> > > design?
> >
> > Sure. I'm not authoritative for the core authors though :].
> However I
> > _think_ I've done the most code in this area, so I'll ask
> that you have
> > a _brief_ look at the existing hook style and pick up from
> there? Don't
> > look too deep because the interface has changed slightly as
> I prepare
> > the code for mainstream readiness.
>
> Again it looks like I should wait a bit.

This shouldn't wait - getting agreement/consensus on the architecture
for this in squid is quite important. Feedback from folk like you as to
how it works, what you need, what you'd like etc is also very important.
A couple of hours from you looking at this could save a lot of time
alter.
 
>
> I've not heard of iCAP. I've only been developing for linux
> for 7 or 8
> months now. I have a lot of gaps in my knowledge. I'll do as you say
> and look at the archives for information, but some url would be handy.

Well i-CAP isn't linux specific. I do most of my squid hacking on
openBSD|MS Windows :].

http://www.i-cap.org/
http://www.checkpoint.com/cvpopenspec/CVPOpenSpecification.pdf

The archives have a description of what I've done, separate from what
i-CAP is. i-CAP defines a protocol for accessing things like content
filters/virus scanners from a proxy. I've written a set of hooks for
squid, and a hook API that allow direct access to what squid is doing
for in-process content processors - so my doco is the relvant bit :].
(And it's in the archives - but I couldn't dig it up on a quick search
:-/). So I've included a synopsis of what it does/can do at the end of
this email.
 
> > in-process "module" (should be fastest). (modules will have dlopen
> > functionality at some point - no squid recompile needed).
>
> Sounds good. Where can I get info and is this interface 'ready'?

The module registration for compiled in modules is functional, but not
quite ready for HEAD. I.e. stable enough to be hacked on. The dlopen
stuff isn't, because that is at the end of the following chain: automake
integration->libtool integration->dlopen. Automake is written and
complete, just waiting on automake to release 1.5. libtool will be
pretty straight forward, I've tried a couple of sandbox experiments and
it looks fine.

That said, you can code the "module" now and build it compiled-in and
have minimal-if-any code changes to make it a dlopen module - squid will
provide the infrastructure to make that seamless.
 
> > out-of-process, iCAP/CVP. (squid that does iCAP/CVP needed)
>
> Sounds easiest. But I think speed wins. We don't want squid
> slowing down
> to an httpd's pace do we? ;)

:]

Ok, now onto the content processing "framework".

Content processing modules implement a number of functions that allows
squid to insert them into the message path of arbitrary http messages.
i.e. transfer encoding can be implemented as a content processing
filter.

There are 4 points for inserting content processing modules:
* at the client->squid entry (after http parsing and squid ACL's are
complete)
* at the squid->upstream exit (before peer selection takes place)
* at the upstream->squid entry (after http parsing)
* at the squid->client exit (after squid ACL's are complete)

squid uses
* mod_register to load a module
* reply_filter_access, response_filter_access,
client_request_filter_access, server_request_filter_access to decide
when a filter is to be inserted in the message path.
* A dynamically registered conf directive to configure the module. Each
module can be instantiated multiple times - for instance a text search
and replace module might have several different patterns to be used in
different cicrumstances.

When inserted a module into the message path, squid calls into the
module to have it create a state variable, giving the module the
request/response details.

From then on in, the module gets called as data passes through squid,
has the opportunity to replace the data inline - including shrinking or
exanding the data - or even abort the request.

Rob
Received on Mon Jun 25 2001 - 00:48:34 MDT