Re: [squid-users] what are the Pros and cons filtering urls using squid.conf?

On 6/11/2013 8:42 PM, Marcus Kool wrote:
>
>
> On 06/11/2013 11:57 AM, Jose-Marcio Martins wrote:
<SNIP>
>> You should use "degraded service" instead of "interruption of service".
>
> In the first part of this thread the discussion was about interruption
> of service of the web proxy.
> With ufdbGuard as URL filter solution there is no interruption of the
> service of Squid.
> And of course, when ufdbGuard reloads, the URL filtering service
> temporarily degrades.
>
> FYI: version 1.31 of ufdbGuard - soon to be released - makes the first
> step towards no degradation during reload by supporting dynamic URL
> categories.
> The dynamics URL categories are loaded while the old ones are still
> being used and in a split-second the new table is made active without
> any service interruption whatsoever.
>
> Marcus
Great!!

I am not pointing at the cons at the existing filtering solutions as a
"go fix it" but to show what are the pros and cons at each and one of them.
These are already known and also the ICAP vs URL_rewrite is pretty known
but admins don't see in their eyes the main issues which comes with each
reload or down time.
My main point was for the admins and not for developers.

I once wrote about that admins are using very bad acls and can cause the
client a very bad situation!!

In the case of hospitals the problem is even worse!
Let say a doctor is using some specific site to be updated about
something and what he sees is a 20 days(or more) old cached page which
was updated and now he(doctor) doesn't know about a problem in a product
or a solution for pains etc.

I only gave two examples for admins that are learning about proxy.
They should think about these pros and cons and other pros and cons when
they are doing their work on the service.

Since the thread got so much attention I am sure that admins will see it
later and understand that I was saying "don't do lousy job while thinking".

Here,
Eliezer
Received on Tue Jun 11 2013 - 18:05:36 MDT