RE: redirectors

Andrew

There seems to be a fundamental problem with your understanding of what a
redirector can do, and what it can't do. The FAQ is always a good place to
start (see http://www.squid-cache.org/Doc/FAQ/FAQ-15.html) as well as the
contrib directory which has some sample redirectors there (in Perl and C)

The redirector *NEVER* gets the actual *CONTENT* of the requested URL, it
only gets the request information (one line in face). The idea of a
redirector is to allow the proxy to optionally re-write or re-direct the
client browser to some other URL altogether. This is then passed back to
squid and THEN the request actually takes place. The redirector is then
effectively "out of the picture" as far as that request goes - it is handled
between the squid and the originating site (to fetch the content for that
URL and store it to the cache directory(s)), and then between squid and the
client (to actually pass the file along, which happens as fast as squid can
pass it along - the old smallest pipe affecting flow rate analogy applies)

So, the client says it wants http://www.badurl.com/ but because you have
written the redirector to filter any badurl.com URLs and return a local page
such as http://my.company.com/no_badurl_message.html instead.

Similarly, if you had a local mirror of certain software e.g. Netscape,
RealPlayer, IE5, etc, and you wanted to stop people from using your incoming
bandwidth to fetch the same file e.g. xyzsetup.exe from 50 different mirror
sites around the world (thus taking up 50 * filesize in your proxy, assuming
they don't get bumped out by cache object expiry policies), and instead
fetch it always from your local mirror, then a redirector could do that
effectively too. You would just need to keep your local mirror, and the
list of filenames the redirector looks for, fairly current.

Now, down to the implementation issues. The redirector reads a line on
STDIN with the information pertinent to the request, makes some sort of
decisions, and writes a line back to STDOUT. The FAQ give the specifics.
The simplest possible redirector would just read a line from STDIN and then
write the same line straight back to STDOUT (which is precisely what the FAQ
redirector template example shows)

The concept of getting Squid to do virus scanning is fatally flawed, because
it does not fit the paradigm which Squid is based on. Ditto for getting a
redirector to do virus scanning (as explained previously). Customers would
be upset if they had to wait until the proxy downloaded the whole file, then
scanned it, and finally started downloading it to them. Thinking back to
the "smallest pipe" phenomenon, this might double the time it takes to
download a URL to a dial-up client - not a great way of winning friends and
customers ! Locating the virus scanner on the Squid machine won't work
because the client will already have the infected file before it can be
scanned on the proxy - if the maximum size of a Squid cache object is
smaller than the file being requested, then it will NEVER get written to
disk and will be passed from in memory storage to the client directly,
bypassing the traditional virus scanning paradigm too. As I understand it
there is no mechanism presently in place to externally force Squid to drop a
connection with a particular client mid-stream (i.e. when a virus is found
by some external scanning mechanism) - a fairly significant design change
would be required.

Better to do what my company has done and come up with a really good,
simple, and effective way of using a login script to force an update of the
client's McAfee VirusScan DAT files if there is a newer version (with
dial-up the biggest problem is the ever-increasing size of the DAT files, so
maybe once-a-week is a sufficient update rate except when something like
"Love Bug" is around, but on a LAN the updates can be daily without too much
drama). If every client PC is kept up to date, then that greatly enhances
the protection afforded - just like the "herd immunity" talked about for
childhood vaccinations to be effective. And, as always, it never hurts to
try and instil some common sense into your user base when it comes to e-mail
borne virii. One look at the headache of the "love bug" only serves as a
sad reminder that common sense is not really that common ...

Cheers

Jason

-----Original Message-----
From: alowe@hislora.com.au [mailto:alowe@hislora.com.au]
Sent: Sunday, 7 May 2000 22:43
To: Ahsan Khan
Cc: Squid Mail List
Subject: Re: redirectors

On Sun, 7 May 2000, Ahsan Khan wrote:

> The Best way is the Perl as redirector in squid is concept .
>
>
> request ---> squid ----> redirector ----> squid -----> backto client
>

i understand the concept of the redirector... but am having trouble with
what is passed to and what should be passed from the redirector... the
format of the input/output for the redirector...

> What a redirector can do in this case is applying some filter and
a
> applying the filter is the most easy thing in Perl. SO better use the Perl
> not C as it will cause more load on the system.
>

i know c very well, but do not know perl at all... so would probably do
better in c... and system load is not a huge problem, as i am wanting to
do the following:

request ---> squid ----> redirector ----> squid -----> backto client

but what the redirector does is such:

get file ---> save file local ---> virus scan file local ---> re-write url
to local file if passed virus scan, else rewrite url error --> and pass
the new url on to client...

i will be scaning only .com, .exe, .zip, .tgz, .doc, and other virus
containing possibilities...

i am actually having trouble just getting the redirector to do the
following in c:

get url --> give url...
with no changes... or:
get url ---> if url = x then url = y, else url = url --> give url..

thanks if anyone can give me a c example of either/both
i dont want to start a prog. language war... just would like to do it in c
cause i know it...

Andrew Lowe
andrew @ pccentre. com . au
Received on Sun May 07 2000 - 21:27:24 MDT